From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: arthur miller Newsgroups: gmane.emacs.devel Subject: Sv: Sv: Sv: Sv: Sv: Christmas wish: Literate Elisp Date: Wed, 18 Dec 2019 23:53:08 +0000 Message-ID: References: <87r213qkhm.fsf@alphapapa.net> <878sn9qxk3.fsf@alphapapa.net> , <87zhfpp6is.fsf@alphapapa.net> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="_000_VI1P194MB0429F28DDEB9ABE778893DBF96530VI1P194MB0429EURP_" Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="229479"; mail-complaints-to="usenet@blaine.gmane.org" To: Adam Porter , "emacs-devel@gnu.org" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Dec 19 00:54:53 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 1ihj9Y-000xaO-Uq for ged-emacs-devel@m.gmane.org; Thu, 19 Dec 2019 00:54:53 +0100 Original-Received: from localhost ([::1]:34122 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ihj9X-0006rB-QT for ged-emacs-devel@m.gmane.org; Wed, 18 Dec 2019 18:54:51 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:35687) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ihj80-0004oU-W7 for emacs-devel@gnu.org; Wed, 18 Dec 2019 18:53:19 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ihj7w-0003Uw-ET for emacs-devel@gnu.org; Wed, 18 Dec 2019 18:53:15 -0500 Original-Received: from mail-am6eur05olkn2086.outbound.protection.outlook.com ([40.92.91.86]:49344 helo=EUR05-AM6-obe.outbound.protection.outlook.com) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1ihj7v-0003Td-NN for emacs-devel@gnu.org; Wed, 18 Dec 2019 18:53:12 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=AxQVjMIsULlyK34i1IfMWv5rpQiMSvqaUhVsnXfgefrjvm5uLDHCto20uugrMm5AOx5bnZCjSWoCdyC779eImNQnsBbk3PKXud3W9bQqKSUrKoelf7KhtnwH7HtDCPL+TZqN+fTtHNcDAIha38qUKILX0p5Sg6EPuk6b+PZuor+JVcR3qY5D9ZRSI822ZS3f+lI4crqM51rQYj5aOxvsKC3H5M6hDMbbqkw09lIxmAqTLwuZ8EqbVo0hlMNKPchJazuRW/q4finiXX3zg7tc2aIweAWuFLJn3r0CtEaiIbSH/FAVF2XZfOaTF9wksfeTKe9E0BYlJ7I5zMWFGZbXYA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=8hzO6zuckFIbznksxvIjWpBUSwuJFKqC6aGBEZ5DIVs=; b=G5q3kMN1EBlvovOVjEzs9q+OsxtHn8XRp0k+DMSHob/NEr15nb9LpKqugy6cex4KiAJggg6koMhEBCN2KqhP7q0RLKooCdOFCzRIpEveTHRnVZk6YHv5ZealOaeg4BF0I8El+GgqaYStA3MyMj1ZTqTG42PQcbQfHJj9hIR+4TH4uEQY6lAQ+8QtWXdDR3RJV4ug12FPQczZwJG0koHu8d9mpQmsWG2NhPCQ7T5pW/Un9uCYURL73WquOT/ChMyqlujfnX8Dp/yEDSj5lXBMcG0zINwdKtTbDN7w5Lf0JevD83fedX9pQkk5ZWo4dd6F7f0Ga+bu8cH5ewgxFQhJNQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none; dkim=none; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=live.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=8hzO6zuckFIbznksxvIjWpBUSwuJFKqC6aGBEZ5DIVs=; b=oVw8sm0LhKH+facotqJKL/NAmosIX+yE8BgZD9AHbYwYg2u7E0iUSZwsFVZWWLrWGmUi/5YQkNZnNSp6+WLQgiPYoO9ojqzln+fhu95l3IDR6GAZaRrN7Wq6uxaX1iORlfqGYORtcy8oJlL1uQcn/ykC6/RuhviRVb+K2mjOxBgvTGbJjtcoOiYqLHjt7jMi6PWJhEd/W25BAdVR/YPnFqWdtyR4OygGe0YnZi9Vd6cbXEQTEe4LBb9OqWhkm3V8OYIgRDUffspqfite6KR39cqUz7EQR+a09798DVmFlHO99QroojWZfWNkbXgQegXMAM4lexHSfET5NACUBIkKAw== Original-Received: from AM6EUR05FT049.eop-eur05.prod.protection.outlook.com (10.233.240.57) by AM6EUR05HT231.eop-eur05.prod.protection.outlook.com (10.233.241.82) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2559.14; Wed, 18 Dec 2019 23:53:08 +0000 Original-Received: from VI1P194MB0429.EURP194.PROD.OUTLOOK.COM (10.233.240.57) by AM6EUR05FT049.mail.protection.outlook.com (10.233.241.157) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2559.14 via Frontend Transport; Wed, 18 Dec 2019 23:53:08 +0000 Original-Received: from VI1P194MB0429.EURP194.PROD.OUTLOOK.COM ([fe80::35f2:9ea2:efd6:1d46]) by VI1P194MB0429.EURP194.PROD.OUTLOOK.COM ([fe80::35f2:9ea2:efd6:1d46%5]) with mapi id 15.20.2559.015; Wed, 18 Dec 2019 23:53:08 +0000 Thread-Topic: Sv: Sv: Sv: Sv: Christmas wish: Literate Elisp Thread-Index: AQHVsQLpbIcz5UxgfkCAm3tN+LzJEqe2wVZzgAJDFqiAAKl6MoAC8pPxgAAqfC+AAAV3ZoAAI1MAgACoIPyAAJZsXoAB5Il6gAAvTFqAAA1aroAAPYvxgAAAShM= In-Reply-To: <87zhfpp6is.fsf@alphapapa.net> Accept-Language: sv-SE, en-US Content-Language: sv-SE x-incomingtopheadermarker: OriginalChecksum:D3ABFBF3FC636F8A8EC0C18D1D61B4C0996B51C8BD45D227FB215C7D3B758684; UpperCasedChecksum:3F3D7F4B538067C5D3F752522C03BD2AC2D961A857225AC033F69E83E05C59B1; SizeAsReceived:7807; Count:45 x-ms-exchange-messagesentrepresentingtype: 1 x-tmn: [naAb6XuI5uBM7Ndf7Ad94YPr+/nf4Ctu] x-ms-publictraffictype: Email x-incomingheadercount: 45 x-eopattributedmessage: 0 x-ms-office365-filtering-correlation-id: e938cf34-365f-49fd-939f-08d784156ee4 x-ms-traffictypediagnostic: AM6EUR05HT231: x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: LLhybPAfzzdTdTELQLS5fXxdlltEcNaEI38IE6cbh6xw0VGI89ATyofq6h1Ik2WWCFy/ryY/t63XqwIN0jtAzMkRNYmJzlUeGq9K4WV76ZJ77jmY3ElKqfbBVo5+t3gjibJjUZtVHV0pkv6BkNp5YHD673xQ+voEAgz+Lxfk+gS3O+Xh7L8MAljdXDulsQPQ x-ms-exchange-transport-forked: True X-OriginatorOrg: live.com X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000 X-MS-Exchange-CrossTenant-Network-Message-Id: e938cf34-365f-49fd-939f-08d784156ee4 X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: 00000000-0000-0000-0000-000000000000 X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Dec 2019 23:53:08.5198 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Internet X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM6EUR05HT231 X-detected-operating-system: by eggs.gnu.org: Windows 7 or 8 [fuzzy] X-Received-From: 40.92.91.86 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:243463 Archived-At: --_000_VI1P194MB0429F28DDEB9ABE778893DBF96530VI1P194MB0429EURP_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable I didn=92t 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=92t want to repeat myself, but I am sure that as long as one don=92t use the new feature all your external tools will continue to work as they do now. If you don=92t 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=92t deal with =94literal syntax=94, than don=92t 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=92t 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=92t 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=E5n: Adam Porter Skickat: den 19 december 2019 00:18 Till: emacs-devel@gnu.org =C4mne: Re: Sv: Sv: Sv: Sv: Christmas wish: Literate Elisp arthur miller 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=92t starting =92(=92 and =92)=92 + 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=92t wish to write literal code, then > just don=92t. Prefix your comment lines with =92;=92 as currently and don= =92t > care about it, Everything will work as it does now. I don=92t 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=92t see how org makes it any different? In org you still have to > use both =92;=92 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=92s 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 =92;=92 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. --_000_VI1P194MB0429F28DDEB9ABE778893DBF96530VI1P194MB0429EURP_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

I didn=92t say you are a cave dweller. I am sorry if= you perceive my

illustration that way. That was just a very first im= age 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 litera= lly anything.

One has to compare cons and pros, and see if pros ou= tweigh the cons.

 

I don=92t want to repeat myself, but I am sure that = as long as one don=92t

use the new feature all your external tools will con= tinue to work as

they do now. If you don=92t 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 exist= ing tool. I might

be wrong of course, but please give me technical rea= sons.

Tools need to be updated just if they will be used w= ith new syntax. So

in general, if you have a tool that can=92t deal wit= h =94literal syntax=94,

than don=92t 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 ea= sy to understand

the difference between text (prose for humans) and c= ode (prose for

computers). I don't think humans need explicit marke= rs as comments

or similar. Comments are written for computers to di= stinguish between

code and things they should ignore so that we humans= can communicate

with each other in our code. I don=92t know, somethi= ng like that. I can

totally understand if this proposal is not implement= able due to

technical reasons, or that this really does not give= that much of a

value to be worth enabling. But I don=92t buy the ar= gument that humans

need some special markers to understand the differen= ce between code

and text. The whole Idea with literal programming is= to minimize that

difference.

 

Fr=E5n: Adam Porter
Skickat: den 19 december 2019 00:18
Till: emacs-devel@gnu.org=
=C4mne: Re: Sv: Sv: Sv: Sv: Christmas wish: Literate Elisp

 

arthur miller <art= hur.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=92t starting =92(=92 and =92)=92 + 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 wou= ld
>> no onger be sufficient to look at comment prefixes to know whether= a
>> line s code or comment.  Such a change would be very expensiv= e in
>> terms of the necessary human work that would ripple outward. = And
>> your proposed variable would not obviate the need to account for b= oth
>> states in my code.
>
> In which way? Can you alaborate more please? You would not need to
> write anything special. If you don=92t wish to write literal code, the= n
> just don=92t. Prefix your comment lines with =92;=92 as currently and = don=92t
> care about it, Everything will work as it does now. I don=92t see a > problem there. If I am wrong please explain.

You don't seem to understand.  I am talking about existing code outsid= e
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 appea= r 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 undef= ined
> 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=92t see how org makes it any different? In org you still have to=
> use both =92;=92 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<= br> > 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=92s 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 =92;=92 just continue to use it. But if a change like th= is
> does not seem to cost lots in development terms, then why opposing if<= br> > 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.

 

--_000_VI1P194MB0429F28DDEB9ABE778893DBF96530VI1P194MB0429EURP_--