From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: chad Newsgroups: gmane.emacs.devel Subject: Re: Sv: Sv: Sv: Sv: Christmas wish: Literate Elisp Date: Wed, 18 Dec 2019 16:42:25 -0800 Message-ID: References: <87r213qkhm.fsf@alphapapa.net> <878sn9qxk3.fsf@alphapapa.net> <874kxxqlxz.fsf@alphapapa.net> <87v9qdp4x8.fsf@alphapapa.net> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="0000000000007438fd059a03d61a" Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="150159"; mail-complaints-to="usenet@blaine.gmane.org" Cc: Adam Porter , "emacs-devel@gnu.org" To: arthur miller Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Dec 19 01:43:36 2019 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1ihjui-000cus-7w for ged-emacs-devel@m.gmane.org; Thu, 19 Dec 2019 01:43:36 +0100 Original-Received: from localhost ([::1]:34472 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ihjuh-0002Uv-3T for ged-emacs-devel@m.gmane.org; Wed, 18 Dec 2019 19:43:35 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:57278) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ihjto-0001Zr-OR for emacs-devel@gnu.org; Wed, 18 Dec 2019 19:42:42 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ihjtm-0007YS-S7 for emacs-devel@gnu.org; Wed, 18 Dec 2019 19:42:40 -0500 Original-Received: from mail-yw1-xc2f.google.com ([2607:f8b0:4864:20::c2f]:38474) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1ihjtm-0007XA-KV for emacs-devel@gnu.org; Wed, 18 Dec 2019 19:42:38 -0500 Original-Received: by mail-yw1-xc2f.google.com with SMTP id 10so1543566ywv.5 for ; Wed, 18 Dec 2019 16:42:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=3sGmq3/2Lz1ctCd6eEeFHnJbdT4b+FyVO5iibXMi9To=; b=RLVLNXDeuQl6dPyuGcDj+uuY/YADSpB9VBF4zmdhTBEcDGDW+jJGB24HonadvZywQJ Y1xvYtQF7CaO4CpN2aMxQmAXIpFXgd5vpViY0/nuSmJbDzVuCo2r+xgq469xk5VlFLHL Uf6zV5L3qlxYpLc9l+asJZQfPEblPsK5t7on7W8QQXY/FfuPmRsOhCFwmAW+/yl/x5/F jComDJ1wO9v7+K56FIwXidVXu4DH/pU18VdqMJnQu0k9eNzzO8GB5wDubbbh/BIoWkIL OrDIaZXugJldkw9KKo1oHaPqJRXF7jL/wSTAuk7RXKc6MuxW6DRF3kA7d5ir2Ygg0Po2 0VkQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=3sGmq3/2Lz1ctCd6eEeFHnJbdT4b+FyVO5iibXMi9To=; b=ovTTZ0+NAS+Pjxh7awJ+YioHWs1HMqmN7cBMk5nDfxe/0F1ddM2seArow0o0IPh9El Pj9vXa3YyuivC8Ai1LUFmuA6tNa/rc8h2Ps98L6xxBZEs9C3x4557QBMYXrDFBf4nU39 xaN2gS3WibcWh8CW+Gm37orDerfWglJahOxm2ixwUh2HGYvvW8eZv8IfpuCxyXeCpR2A w6stQcc/hcBN9HmMQFWShWnGsEfGBlG3/lJgjQJXhG99oqlM/5QxPdbUk0KwRAX80Szg 4eqiImS/FbJzN29q7jI34vGtdV3kVBIrwVDJUWa8Hd/ajC3v3do/ulR8JWJjWGVF/Bzm nCng== X-Gm-Message-State: APjAAAVtqcrDQKrz/ogmiDgAuriQL4S4QBhQeF3+4MeJ7Jc600tOHoI8 XKBkX1aydJYaVCEe9DRSP0VG01iZsRnD70YX3Qo= X-Google-Smtp-Source: APXvYqx5IJ/F1tOiZGZCw9YOBGSWcKUL4NYIcMSUM1UmCufHQTgibNaS7L9A59WyhXREECJUwwqx/A7NjUoXp2ZIN5w= X-Received: by 2002:a81:2b03:: with SMTP id r3mr4431503ywr.72.1576716157072; Wed, 18 Dec 2019 16:42:37 -0800 (PST) In-Reply-To: X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2607:f8b0:4864:20::c2f X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:243466 Archived-At: --0000000000007438fd059a03d61a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 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 =F0=9F=98= =8A. By > > the way those 4 lines will be literally invisible (not entered) if one pu= ts > > 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 =E2=80=9Dliteral code=E2=80=9D = your existings > > tools would still be broken. I don=E2=80=99t see how the implementation c= hoice > > would change that matter nor do I see why is it so big matter for you? > > > > *Fr=C3=A5n: *Adam Porter > *Skickat: *den 19 december 2019 00:53 > *Till: *emacs-devel@gnu.org > *=C3=84mne: *Re: Sv: Sv: Sv: Sv: Christmas wish: Literate Elisp > > > > arthur miller 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=E2=80=99t need to use if you don=E2= =80=99t like it. > It > > > > is trivial to make it by default =E2=80=9Doff=E2=80=9D by introducing n= ew 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? > > > > --0000000000007438fd059a03d61a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
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 res= olve it.

The place where you are adding 4 lines of C cod= e 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 b= ody of existing software which will be totally unaware of your changes. Tha= t body is large enough that it is doubtful that it can, as a practical matt= er, be reasonably changed to not break on the syntax changes that you are p= roposing.

On the other hand, there are ways to acc= omplish 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, th= at 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:0= 3 PM arthur miller <arthur.mil= ler@live.com> wrote:

I actually answered in my previous mail. You are wro= ng 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 curr= ently fighting with

byte compiler which is mostly elisp and it does not = go so well =F0=9F=98= =8A. By

the way those 4 lines will be literally invisible (n= ot entered) if one puts

a variable around them as I suggested.

=C2=A0

For the record, even if I wrote an elisp package tha= t implements this in

pure elisp, and somebody decides to write =E2=80=9Dl= iteral code=E2=80=9D your existings

tools would still be broken. I don=E2=80=99t see how= the implementation choice

would change that matter nor do I see why is it so b= ig matter for you?

=C2=A0

Fr=C3=A5n: = Adam Porter
Skickat: den 19 december 2019 00:53
Till: emacs= -devel@gnu.org
=C3=84mne: Re: Sv: Sv: Sv: Sv: Christmas wish: Literate Elisp

=C2=A0

arthur miller <arthur.miller@live.c= om> 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 sim= ply
>
> add an extra feature, which you don=E2=80=99t need to use if you don= =E2=80=99t like it. It
>
> is trivial to make it by default =E2=80=9Doff=E2=80=9D 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.=C2=A0 I will ask on= ce
more: Do you understand that Elisp code written in the way you propose
would not be compatible with existing tools which parse Elisp?=C2=A0 And th= at
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.=C2=A0 That is a great idea.=C2=A0 Why don't you want = to do that?


=C2=A0

--0000000000007438fd059a03d61a--