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

[Adam Porter <adam@alphapapa.net>]

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.