I didn’t say you are a cave dweller. I am sorry if you perceive my
illustration that way. That was just a very first image that came
into my mind. Sorry if you find it somehow offending. I was just
trying to say that a case can be made against literally anything.
One has to compare cons and pros, and see if pros outweigh the cons.
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?
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.
Från: Adam Porter
Skickat: den 19 december 2019 00:18
Till: address@hidden
Ämne: Re: Sv: Sv: Sv: Sv: Christmas wish: Literate Elisp
arthur miller <address@hidden> 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.