Re: Christmas wish: Literate Elisp

[Unknown <unknown@unknown.invalid>]

arthur miller <arthur.miller@live.com> 작성:

> I don’t want to repeat myself, but I am sure that as long as one don’t
> use the new feature all your external tools will continue to work as
> they do now. If you don’t write literal code then your code would look
> like just as it does now, so no confusion there. If it is disabled by
> default then I see no way it could confuse any existing tool. I might
> be wrong of course, but please give me technical reasons.
> Tools need to be updated just if they will be used with new syntax. So
> in general, if you have a tool that can’t deal with ”literal syntax”,
> than don’t use the literal syntax or the tool. Is that a problem?

Yeah, it is, mostly because code written be people who believes that  
writing prose interleaved with Elisp without any explicit markers (like  
you) will break the existing tools.

If one decided to push their prose-with-elisp code to GitHub, GitHub’s  
Elisp highlighter would be confused. That’s just one example with the  
problem. You might totally be fine with that: you know that it’s not the  
usual syntax… but other people would find out & be upset about that.

I bet there will be elisp-mundging code in Emacs that aren’t hooked onto  
the reader… which means that those code will be also broken.

> About literal programs without special markers being confusing:
> honestly I believe that most humans find it quite easy to understand
> the difference between text (prose for humans) and code (prose for
> computers). I don't think humans need explicit markers as comments
> or similar. Comments are written for computers to distinguish between
> code and things they should ignore so that we humans can communicate
> with each other in our code. I don’t know, something like that. I can
> totally understand if this proposal is not implementable due to
> technical reasons, or that this really does not give that much of a
> value to be worth enabling. But I don’t buy the argument that humans
> need some special markers to understand the difference between code
> and text. The whole Idea with literal programming is to minimize that
> difference.

Well, maybe the whole idea of literal programming is to minimize the  
difference, but elisp isn’t for literal programming right?

If you really want this, I would nudge you to make a Elisp dialect  
optimized for literal programming implemented by a preprocessor in the  
front of the Elisp reader.
I really can’t see why this is beneficial to anyone (except maybe for you).

> Från: Adam Porter
> Skickat: den 19 december 2019 00:18
> Till: emacs-devel@gnu.org
> Ämne: Re: Sv: Sv: Sv: Sv: Christmas wish: Literate Elisp
>
> arthur miller <arthur.miller@live.com> writes:
>
> >> 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?
>
> I explained in the message you quoted why they are not enough.  Please
> read it carefully.
>
> >> 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.
>
> You don't seem to understand.  I am talking about existing code outside
> of emacs.git which parses Elisp, which would not be compatible with your
> proposed changes to Elisp syntax.
>
> >> 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?
>
> Your own message showed how it happens in prose.  In fact, it's common
> enough and ambiguous enough that Elisp already forbids open-parens at
> column 0 in strings and requires them to be escaped.  How is this a
> minor obscurity?
>
> Don't you realize how important it is that syntax in a file format be
> unambiguous?
>
> > 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.
>
> It is also a step toward ambiguity, churn, and bugs in other people's
> code, which you would not have to fix.
>
> > I don’t see how org makes it any different? In org you still have to
> > use both ’;’ and #+BEGIN_SRC - #+END_SRC markers.
>
> Have you used Org mode?  Have you looked at a literate program written
> in an Org file?  The point is that top-level comments are written
> between code blocks, without comment prefixes.
>
> > So it is even more clutter to eye.
>
> As I said in the message you're replying to:
>
>   You can even choose a face for org-meta-line that makes #+BEGIN_SRC
>   lines virtually (or literally!) disappear.
>
> > 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,
>
> I have said nothing about old ways.  I explained exactly what the
> problems with the proposal are.  Please read my message carefully.
>
> > 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.
>
> It's not cool to imply that citing technical problems with your proposal
> is like being a cave-dweller.