all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
* Christmas wish: Literate Elisp
@ 2019-12-12 15:45 arthur miller
  2019-12-12 17:29 ` Stefan Monnier
  2019-12-14  4:16 ` Richard Stallman
  0 siblings, 2 replies; 45+ messages in thread
From: arthur miller @ 2019-12-12 15:45 UTC (permalink / raw)
  To: emacs-devel

[-- Attachment #1: Type: text/plain, Size: 7643 bytes --]

Hello,

I have a question/proposal about Elisp and literate programming.
Well, more of a proposal then a question, but here it is:

From Wikipedia: "Literate programming is a programming paradigm
introduced by Donald Knuth in which a computer program is given
an explanation of its logic in a natural language, such as English,
interspersed with snippets of macros and traditional source code,
from which compilable source code can be generated."

Emacs already supports a form of literal programming in form of
org mode and babel where we can insert code for programming
languages in-between #+BEGIN_SRC and #+END_SRC markers,
which is super nice and cool feature.

However I got a thought that LISPs (lisp-like languages), have natural
code markers, since all code is enclosed with parenthesis. Thus one
could see '(' and ')' as code markers in literate-programming style,
more of as Knuth proposed. In other words, LISP (or at least Elisp)
does not need special markers to denote start and end of code. Unlike
Haskell, there is no need to use '\begin_code' or '>' to differentiate
code from text (comments).

My proposal is to slightly change Elisp parser to treat lines that start
with any other printable character but '(' as a start of comment and to
simply ignore the line, just as it treats ';' as a comment. Code blocks
would still be parsed as they are now, and ';' would still mean a comment,
wherever it is encountered, it is just that anything that does not
belong in a code-block (lists) is a comment. For example consider this mail,
if this would be thrown into parser all lines to this point would be simply
ignored since they don't start with '(' or are white spaces.

(my-elisp-fun
        (progn
                (while (very-cool)
                       (do-something-very-literate-here))))

Then I could have Elisp code in between and continue to write this mail
and later on just use this as a source code. Wouldn't that be a step
toward true and more cool literate programming language? Below is another
snippet of imaginary Elisp. If we could do this, then this email would be
a working literate Elisp, where those two snippets are code and text of
this mail is just ignored.

(my-other-fun
        (progn
                ; this-is-some-other-fun
                (to-hopefully-demonstrate-the-idea)))

What would this achieve

More then highly increased coolness factor, it would be a small quality
of life improvement. For example this would actually make it slightly
easier to use org-mode for Elisp programming. For example for us that
use org-mode to structure Emacs init file, we could just throw in our org
file directly, instead of using babel to entangle it into Elisp file first.
If every printable character but '(' starts a comment line, then everything
in org-file but Elisp code would be simply ignored, and only Elisp executed.

If we think other way around, it would also let us use pure Elisp for literate
programming without org-mode whatsoever, albeit it would be a cool feature to
use org-headings and similar to structure the code. It might make code more
structured and thus more readable. When I think in terms of Elisp as a starting
point rather then in terms of org-mode as a starting point, that could result in
adding org-mode organizational features directly to Elisp. One could even mark
say not-implemented functions as todo items, use calendar etc.

We could also entangle other languages within pure Elisp code without using org
mode whatsoever. Either within some code markers for processing them out to
separate files, or without code markers just as documentation or whatever. I
don't have some better example of use-case at the moment.

I don't mean that it is incredibly slow to entangle files, but it would be
slightly more efficient to process Elisp entangled in org mode. I also don't
think it is hard to type ';' at the beginning of a line to start a comment line.
But it is a small convenience and thus quality of life improvement that probably
does not need much changes to a parser but has quite a dramatic effect on how
source code looks in human eye (at least mine, if you don't mind that I count
myself as a part of the species :-)). It would let us use org-mode as a standard
Elisp source code format, which might be just a perceived convenience rather
then some real extra useful thing that does not exist yet.

Some thoughts about implementation

I think that in terms of cost effectiveness with implementation in mind, it
probably isn't that much work to implement this, but honestly I have no idea.
I believe it can't be much work, but I am not sure so I should really put an
exclamation mark to word probably in paragraph above. Feel free to educate me
about cost of making it work. I was looking myself in C source to see if I could
test this myself before I post here, but I couldn't find where you have implemented
parser. I am sorry, but I am that bad :-(.

Essentially when parsing literate Elisp, if I may call it so, what
parser has to do is to simply not flag random printable characters, on lines
that does not belong to code-blocks, as errors in source code. Instead just treat
them as if it has seen a ';'.

It means there are just two classes of printable characters: '(' that opens
a code block, and everything else that opens a comment block. Well almost.
Parsing code blocks would not need to be changed at all, and ';' in code blocks
would still mean that rest of line is a comment, and all code with comments
would still continue to work as it does now. It would only affect new code that
is written in this style. However new Elisp code wouldn't be backward
compatible with old versions of Emacs.

As extra, one could keep current Elisp parser and make new one and use as
in Haskell, en extra 'l' in suffix to denote a literate program, '.lel'. Though
it kind-a looks fun, I don't think it wouldn't be needed, I don't think this
change would need different parser, to ensure backward compatibility. I don't
think that is very important since if we would write Elisp that needs to run on
older versions, we can just let be to write it in literal form.

Drawbacks

As I can think of, it would maybe make spotting errors slightly harder, for
example I could type a random character before an opening parenthesis and
comment out entire line, but those kind of errors are easily spotted on first code
run. Another drawback would be probably syntax highlighting. It could probably
become much harder to detect comments in code since there is no ';' to mark a
comment-line. Maybe I am wrong about this one, it is just a fast thought.

Final thought

I have no idea if somebody else has already thought about this and found that it
can't work. It seems like a very straight-forward and simple thing so I am
probably not the first one to think the thought, and there is probably some
reason why it is not done that I am not aware of. In that case just ignore this
email. It was just a thought I got yesterday. There might be something I am not
aware of that makes this impossible, I am not that familiar with Emacs source to
try to implement this myself unfortunately. It is just an idea, a thought for
discussion, but it would be cool if it can work.

I am sorry for very long email, I hope you have at least somewhat enjoyed my
rather ramblings and Christmas wishes, and please ask Santa to excuse my
English, I am not native English speaker, it is just my 3rd language if it is in
any defense or my horrible writing.


[-- Attachment #2: Type: text/html, Size: 11030 bytes --]

^ permalink raw reply	[flat|nested] 45+ messages in thread

end of thread, other threads:[~2019-12-22  7:01 UTC | newest]

Thread overview: 45+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2019-12-12 15:45 Christmas wish: Literate Elisp arthur miller
2019-12-12 17:29 ` Stefan Monnier
2019-12-14  4:40   ` Sv: " arthur miller
2019-12-14 14:08     ` Stefan Monnier
2019-12-15  8:37       ` arthur miller
2019-12-16 12:01       ` Sv: " arthur miller
2019-12-16 13:41         ` Stefan Monnier
2019-12-16 14:02           ` Sv: " arthur miller
2019-12-16 16:07             ` Jonathan Leech-Pepin
2019-12-17  2:09               ` arthur miller
2019-12-17 11:06                 ` Adam Porter
2019-12-18 16:29                   ` Sv: " arthur miller
2019-12-18 18:49                     ` Adam Porter
2019-12-18 20:04                       ` Sv: " arthur miller
2019-12-18 23:18                         ` Adam Porter
2019-12-18 23:53                           ` Sv: " arthur miller
2019-12-20 15:58                             ` Unknown
2019-12-18 21:18                       ` Sv: Sv: Sv: " Stefan Monnier
2019-12-18 22:43                         ` Christmas wish: Literate Elisp (Intro) VanL
2019-12-19  0:05                           ` Sv: " arthur miller
2019-12-18 22:59                         ` Sv: Sv: Sv: Christmas wish: Literate Elisp Adam Porter
2019-12-18 23:18                           ` Sv: " arthur miller
2019-12-18 23:52                             ` Adam Porter
2019-12-19  0:02                               ` Sv: " arthur miller
2019-12-19  0:42                                 ` chad
2019-12-19  1:50                                   ` Jean-Christophe Helary
2019-12-20  0:55                                     ` Sv: " arthur miller
2019-12-20 15:00                                       ` Stefan Monnier
2019-12-20 15:50                                         ` Stefan Monnier
2019-12-20 15:50                                         ` Sv: " arthur miller
2019-12-20 16:17                                           ` Stefan Monnier
2019-12-20 16:34                                             ` Eduardo Ochs
2019-12-21  1:18                                               ` Sv: " arthur miller
2019-12-21  5:24                                                 ` Eduardo Ochs
2019-12-21  5:52                                                   ` Sv: " arthur miller
     [not found]                                                   ` <VI1P194MB042965777086C4466B7FF5EC962C0@VI1P194MB0429.EURP194.PROD.OUTLOOK.COM>
2019-12-21 15:29                                                     ` arthur miller
     [not found]                                             ` <VI1P194MB0429A123183C15AF8EC3956B962C0@VI1P194MB0429.EURP194.PROD.OUTLOOK.COM>
     [not found]                                               ` <jwv7e2pln3s.fsf-monnier+emacs@gnu.org>
     [not found]                                                 ` <VI1P194MB0429F37A29A2720037CAD9F9962C0@VI1P194MB0429.EURP194.PROD.OUTLOOK.COM>
2019-12-22  7:01                                                   ` Sv: " arthur miller
2019-12-20 16:51   ` Phillip Lord
2019-12-21  1:16     ` Tim Cross
2019-12-21  4:24       ` Sv: " arthur miller
2019-12-21  6:41         ` Tim Cross
2019-12-21  9:39           ` VanL
2019-12-21 14:17             ` Sv: " arthur miller
2019-12-14  4:16 ` Richard Stallman
2019-12-14  5:05   ` Sv: " arthur miller

Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.