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

[chad]

It seems that there is a communications breakdown here. At the risk of poking the bear, I'm going to try to see if I can help resolve it.

The place where you are adding 4 lines of C code does not change the syntax of elisp as a whole; it merely changes the way that particular version of emacs parses the new format. There is a large body of existing software which will be totally unaware of your changes. That body is large enough that it is doubtful that it can, as a practical matter, be reasonably changed to not break on the syntax changes that you are proposing.

On the other hand, there are ways to accomplish what seems (at least to some of us) to be your stated goals without requiring a change to the syntax of elisp. Using that approach instead, that large body of existing software would continue to work, and, over time, might eventually be expanded to add extra value to the additions.

(This principle is often described as "be conservative in what you send, and liberal in what you accept".)

I hope that helps.

~Chad

On Wed, Dec 18, 2019 at 4:03 PM arthur miller <address@hidden> wrote:

I actually answered in my previous mail. You are wrong about

that this proposal would broke your tools.

Those 4 lines of C, would cost me many more lines of elisp, as least

as much as I can elisp (rather as little). I am currently fighting with

byte compiler which is mostly elisp and it does not go so well 😊. By

the way those 4 lines will be literally invisible (not entered) if one puts

a variable around them as I suggested.

 

For the record, even if I wrote an elisp package that implements this in

pure elisp, and somebody decides to write ”literal code” your existings

tools would still be broken. I don’t see how the implementation choice

would change that matter nor do I see why is it so big matter for you?

 

Från: Adam Porter
Skickat: den 19 december 2019 00:53
Till: address@hidden
Ämne: Re: Sv: Sv: Sv: Sv: Christmas wish: Literate Elisp

 

arthur miller <address@hidden> writes:

> Yes Adam you are correct, but altering parser does not necessary mean
>
> that elisp will change in a way that will force you to change your
>
> existing code or coding practice. I proposed it in a way that will simply
>
> add an extra feature, which you don’t need to use if you don’t like it. It
>
> is trivial to make it by default ”off” by introducing new variable one can
>
> set in init file to enable it (or disable it, whichever is better for default).
>
> Hope it makes it a bit more clear what I suggested.

(Please do not double-space your messages.)

I have tried to explain this issue as clearly as I can.  I will ask once
more: Do you understand that Elisp code written in the way you propose
would not be compatible with existing tools which parse Elisp?  And that
such tools would require modification to parse such code correctly?

Stefan suggested ways to implement your idea as an alternative, literate
syntax, in a separate file format, by writing it in Elisp, using advice
and/or configuration variables, so that modification of the parser in C
would not be required, and the existing Elisp syntax and parser would
remain unchanged.  That is a great idea.  Why don't you want to do that?