Sv: Sv: Sv: Sv: Christmas wish: Literate Elisp

[arthur miller <arthur.miller@live.com>]

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

> On the contrary, the semicolon prefix (and fontification according to my
> preferences in Elisp buffers) makes it easy for me to see what is code
> and what is prose.

Aren’t starting ’(’ and ’)’ + identation enough?

> No, in fact, some of my Elisp would have to change, because it would no
> onger be sufficient to look at comment prefixes to know whether a line
> s code or comment.  Such a change would be very expensive in terms of
> the necessary human work that would ripple outward.  And your proposed
> variable would not obviate the need to account for both states in my
> code.

In which way? Can you alaborate more please? You would not need to write
anything special. If you don’t wish to write literal code, then just don’t. Prefix
your comment lines with ’;’ as currently and don’t care about it, Everything will
work as it does now. I don’t see a problem there. If I am wrong please explain.

> This is the problem: as you have shown, parentheses commonly appear in
> prose, even at the beginning of lines.  Punctuation, such as semicolons,
> do not
> ; or, at least, should not

Yes, and it is always possible to construct some obscure case where things break.
Look for example at C or C++ and all undefined behaviours in the standard. I mean,
sure, there are always soem obscurities, but do they matter? If one writes an
article or a book or some prosa and uses literal programming, and there is one
explicit case not allowed to use, how important is than to use exactly that
constrcut? I mean considering cons and pros, should one abandon the entire
idea because of one minor obscurity?

> Until we can write programs in human language, we must write both.  For
> humans' sake, the two need to be clearly separated.  If you don't like
> comment prefix syntax, you can use Org files and their source blocks, so
> your prose and your code can both start at column 0.  You can even
> choose a face for org-meta-line that makes #+BEGIN_SRC lines virtually
> (or literally!) disappear.

Well as I see literal programming it is to make it easier for humans to mix code and
prosa. What I proposedis just one small step further in that direction. I don’t see how
org makes it any different? In org you still have to use both ’;’ and #+BEGIN_SRC  -
#+END_SRC markers. So it is even more clutter to eye. It is not about starting at column 0,
It is about being able to simple write and mix code and text. If it is good or bad idea is up
to individual preference. I personally find it a cool thing, you seem to think it violates old
ways, so obviously we wont agree on that one. But thank you for the discussion, I surely
appreciate the input, even if I don’t agree on the main conclusion. I gladly read more!

As a small reflection about us humans being slentrians, I have an illustration.
Caves are still as good for living as they were 20 000 years ago. We can for sure
make many cases against living in houses such as not being natural, can crash on it’s
inhabitants, cost resources to construct etc etc. But yet, pros of liiving in houses outweigh
far the cons, and not many people today prefer to live in a cave. Sorry maybe ti is a too
contrived illustration. Anyway, if you are good with ’;’ just continue to use it. But if a
change like this does not seem to cost lots in development terms, then why opposing if
somebody else find it cool. It is just that is more elegant and in a sense cool thing to be
able to do it without special tools as some markers.

Från: Adam Porter<mailto:adam@alphapapa.net>
Skickat: den 18 december 2019 19:50
Till: emacs-devel@gnu.org<mailto:emacs-devel@gnu.org>
Ämne: Re: Sv: Sv: Sv: Christmas wish: Literate Elisp

arthur miller <arthur.miller@live.com> writes:

> As you mention yourself from,Wikipedia, literate programming is about moving
> away from programming for computers to programming for humans. Using comments
> to comment-away text ment for humans or to mark lines between comments and
> code is indeed writing for the computer, not the human. Humans tend to be
> distracted by unnecessary clutter, and managing stuff just for the sake of
> machine does take a little more effort then not doing it.

; I am not more distracted while reading this line of text
than I am while reading this one.

On the contrary, the semicolon prefix (and fontification according to my
preferences in Elisp buffers) makes it easy for me to see what is code
and what is prose.

> I can also imagine case where Elisp is impossible to distinguish from text,
> (for example this line is valid text but would fail in parser), or whatever
> we would put into a parenthesis on a separate line that does not
> belong to code.

That line beginning with a paren parses as valid Elisp.  Whether it
evaluates depends on the context.

> Anyway, due to elisp looks, we have those "natural markers", ( and ) which
> we can use as delimiters between code and text.

This is the problem: as you have shown, parentheses commonly appear in
prose, even at the beginning of lines.  Punctuation, such as semicolons,
do not
; or, at least, should not.

> For the question of being concerned about omitting ';' to change the parser.
> Well yes :-). Small syntactic sugar change but it reduces that visual
> clutter.

You call it clutter; I call it clearly delineating code and prose.  What
would look cluttered to me would be prose (which may include commented-out
code) interspersed with
(insert "code, which may include or generate prose.")

> It is one step in that direction of writing code for humans and not for the
> computer.

Until we can write programs in human language, we must write both.  For
humans' sake, the two need to be clearly separated.  If you don't like
comment prefix syntax, you can use Org files and their source blocks, so
your prose and your code can both start at column 0.  You can even
choose a face for org-meta-line that makes #+BEGIN_SRC lines virtually
(or literally!) disappear.

> See it as experiment. I thought it would be a cool thing to have. It
> is just an idea. The change is not in an intrusive way. All your elisp
> is still very same.  It just adds an extra feature pretty much for
> free. If it would be an intrusive change that requires your old elisp
> to change, than I wouldn't suggest it. By the way, one could also add
> a variable to turn off that feature.

No, in fact, some of my Elisp would have to change, because it would no
longer be sufficient to look at comment prefixes to know whether a line
is code or comment.  Such a change would be very expensive in terms of
the necessary human work that would ripple outward.  And your proposed
variable would not obviate the need to account for both states in my
code.

And since parens can appear at the start of lines in prose, how would
anyone but a human know whether a line is code or prose?

> As for the tools, since old elisp code does not change, all your tools
> would still continue to work on all your ordinary elisp, and you could
> still use ';' just as you do now. What would change is that you would
> be able to write some elisp as you can't now, and only on that code
> the tools would probably get confused. I have no idea how hard would
> it be to change font-locking and indentation checkers, maybe hard,
> maybe not at all. I can't answer that since I am not acquianted with
> how those tools are implemented (lots of regex as I have heard).

> But in worst case, you can always fall back on writing ordinary elisp.

My tools which handle Elisp would have no such luxury, because they must
handle all valid Elisp.

> I have no idea how hard would it be to change font-locking and
> indentation checkers, maybe hard, maybe not at all.

Please, if you won't take my word for it, try it and see.



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