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: Christmas wish: Literate Elisp Date: Wed, 18 Dec 2019 16:29:49 +0000 Message-ID: References: , <87r213qkhm.fsf@alphapapa.net> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="_000_VI1P194MB0429EDCC0D522D6BAD1B205496530VI1P194MB0429EURP_" Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="242770"; 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 Wed Dec 18 17:30:10 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 1ihcDB-0010zh-L7 for ged-emacs-devel@m.gmane.org; Wed, 18 Dec 2019 17:30:09 +0100 Original-Received: from localhost ([::1]:56832 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ihcD9-0008Mp-W2 for ged-emacs-devel@m.gmane.org; Wed, 18 Dec 2019 11:30:08 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:52620) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ihcD0-0008MP-Ug for emacs-devel@gnu.org; Wed, 18 Dec 2019 11:30:01 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ihcCx-0007bk-SM for emacs-devel@gnu.org; Wed, 18 Dec 2019 11:29:58 -0500 Original-Received: from mail-db8eur05olkn2105.outbound.protection.outlook.com ([40.92.89.105]:13568 helo=EUR05-DB8-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 1ihcCv-0007S9-MX for emacs-devel@gnu.org; Wed, 18 Dec 2019 11:29:54 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=WJxBfhlaWqdXXRztSWE3kqD0gAMPqvEsmFmPKa9gRxBU5cWbcmxSRb9zPMDNR/57fkh7zO0/CazcgoMTnww/3X7bFy0BZXeuD6vMjF0ywIZR/r+vB8QqZHe8296M+2N0/TC0nYJB+psC0/v/6fNtVPG3Hbr4fzyOQzy2Dn5c0k0+Jw9jjcoEJtcI1tJ9FWkpwxHrrN5D7fj6RMMWYvjKS3Gyw+9cmiHhqRSn4WgqlxaZgmc6K5k1pc82r/AwSDsaxrwsL9Jsdv+titjt4cMZlJqCW6/XP+On3JDsE81GZnuuE8fBCkdADp5ChAp9AWo61MhZsF4/WdsiAHW7gpdQ6A== 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=roA4nb3+QxI+AOGl2PDHV24Zj0x31Zt3eNjHB5uQPtk=; b=QZT//ISIf5lDV/ArGVtbk9Yd+TneLlT1KiWmH2tCzLtD1DNOszYdECGQq8zv+G06c2cgLsYEJTe74qydbIjO1QJdYbMxZ1YsrgcRi1XMTVA4Q3z62arrHgQRUtBskp4KuxZBNVPenzzSzfmSKWnMhTxgIN2uWg6tYGL6glqoxclUpDBir0c6VuCDZAc/nWJMp0Hr+0LJj/Vmb4Cuorg9GlcWUj13tnfmTBEfJpOb6XoxksD6CjbNUVE3NynGiWYoZ5ZUouph2FviGD2qHnt5wcizxIBdiGkHzy7iAnCCjkJfnMXw3qC9Zrs90OYU0cS2ixDfI103fXWLMgACuXfz+g== 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=roA4nb3+QxI+AOGl2PDHV24Zj0x31Zt3eNjHB5uQPtk=; b=Lkz+SnI4FQJwQruSNiS4DQCPtQS3Wowp9vMJsd5b8FpE65e/968cVnFcHRkjS45Ccg2igX7Viw704CzsHau4u/J8J9FShOM+C2LsghAuvDzGbSfawH9t3hBG8svNj7r3FCHl/OWwXyZAwIo97clRqUOJ6dPgBCKxeeK69iBea7OWu+jp0heYoLIL614x6ZJQ0bTTUaYdRHjwbxe9u1BXZi7aLbNzalvHWdGaHKhvVdhtDQN4AJd3IjZ03vlle+eZ4ugUOuoWE5Ynx3u+31EnbAsqaOwrWi9XJlvoRTVkM8jw3RqpKS7FyDLns0GGkkgnj+jzJJd1RQc29FuqwILWig== Original-Received: from AM6EUR05FT016.eop-eur05.prod.protection.outlook.com (10.233.240.58) by AM6EUR05HT158.eop-eur05.prod.protection.outlook.com (10.233.241.43) 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 16:29:49 +0000 Original-Received: from VI1P194MB0429.EURP194.PROD.OUTLOOK.COM (10.233.240.58) by AM6EUR05FT016.mail.protection.outlook.com (10.233.240.243) 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 16:29:49 +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.2538.019; Wed, 18 Dec 2019 16:29:49 +0000 Thread-Topic: Sv: Sv: Christmas wish: Literate Elisp Thread-Index: AQHVsQLpbIcz5UxgfkCAm3tN+LzJEqe2wVZzgAJDFqiAAKl6MoAC8pPxgAAqfC+AAAV3ZoAAI1MAgACoIPyAAJZsXoAB5Il6 In-Reply-To: <87r213qkhm.fsf@alphapapa.net> Accept-Language: sv-SE, en-US Content-Language: sv-SE x-incomingtopheadermarker: OriginalChecksum:7B91B5756E57CDE6B671726D1635F13136E62584AFE0E1073A2E9F92011A7C74; UpperCasedChecksum:50F16F7047958C681967FED51C472FC655471463B0555CF4AB8C57CEB58E20FE; SizeAsReceived:7520; Count:45 x-ms-exchange-messagesentrepresentingtype: 1 x-tmn: [nhem+A938ZMcordNPMLFb79ValJeyEHM] x-ms-publictraffictype: Email x-incomingheadercount: 45 x-eopattributedmessage: 0 x-ms-office365-filtering-correlation-id: a268c769-ea27-43fd-d05f-08d783d780da x-ms-traffictypediagnostic: AM6EUR05HT158: x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: kNHRJQa7F0bfeUbRRsdrzrTPwj9Iehf3Uyet0YrXGn1sa9E5vG5M+8tzo2rXFFzJwynRcCrcHDsjQddj7VgvzaPHpYJwiDvk0/Ln172AUtq9DR5xod1Y6XXAzqyOLU4FAxaYIC8lfrr1d2maCRO2C1Lv2mqDSXD0A3Me4d+QoUV8LexBT8/yirrlUiZnlMQI 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: a268c769-ea27-43fd-d05f-08d783d780da X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: 00000000-0000-0000-0000-000000000000 X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Dec 2019 16:29:49.8745 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Internet X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM6EUR05HT158 X-detected-operating-system: by eggs.gnu.org: Windows 7 or 8 [fuzzy] X-Received-From: 40.92.89.105 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:243448 Archived-At: --_000_VI1P194MB0429EDCC0D522D6BAD1B205496530VI1P194MB0429EURP_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello, sorry for a bit late answer, but I was very busy Monday/Tuesday. To make this more readable I will try to summerize here as one-piece text for easier reading. As you mention yourself from,Wikipedia, literate programming is about movin= g away from programming for computers to programming for humans. Using commen= ts to comment-away text ment for humans or to mark lines between comments and code is indeed writing for the computer, not the human. Humans tend to be distracted by unnecessary clutter, and managing stuff just for the sake of machine does take a little more effort then not doing it. Being programming-language agnostic though is probably not possible without having some kind of special tool, or special syntax due to some languages being probably very hard to distinguish from ordinary text. For example I believe that C/C++ or even Bash or Makefiles are very hard if not impossible to process that way without some very complicated parser. I can also imagine case where Elisp is impossible to distinguish from text, (for example this line is valid text but would fail in parser), or whatever we would put into a parenthesis on a separate line that does not belong to = code. Anyway, due to elisp looks, we have those "natural markers", ( and ) which we can use as delimiters between code and text. For the question of being concerned about omitting ';' to change the parser= . Well yes :-). Small syntactic sugar change but it reduces that visual clutt= er. It is one step in that direction of writing code for humans and not for the computer. See it as experiment. I thought it would be a cool thing to have.= It is just an idea. The change is not in an intrusive way. All your elisp is still very same. It just adds an extra feature pretty much for free. If it = would be an intrusive change that requires your old elisp to change, than I would= n't suggest it. By the way, one could also add a variable to turn off that feat= ure. As for the tools, since old elisp code does not change, all your tools woul= d still continue to work on all your ordinary elisp, and you could still use = ';' just as you do now. What would change is that you would be able to write so= me elisp as you can't now, and only on that code the tools would probably get confused. I have no idea how hard would it be to change font-locking and indentation checkers, maybe hard, maybe not at all. I can't answer that sin= ce I am not acquianted with how those tools are implemented (lots of regex as I = have heard). But in worst case, you can always fall back on writing ordinary eli= sp. As a note, one will still have to use ';' in directives, like ;;;###autoloa= d or ;;; -*- lexical-binding: t; -*- . Otherwise it would need lots more work to get it to work, which I am not sure is worth. Fr=E5n: Adam Porter Skickat: den 17 december 2019 12:07 Till: emacs-devel@gnu.org =C4mne: Re: Sv: Sv: Christmas wish: Literate Elisp arthur miller writes: > It is true, that keeping directives in comments does not break the > existing parser, but then it is not so much of literate programming, > is it? Literate programming is not a matter of syntax. For example, this summary in the Wikipedia article seems to describe it well: Literate programming is a programming paradigm introduced by Donald Knuth in which a computer program is given an explanation of its logic in a natural language, such as English, interspersed with snippets of macros and traditional source code, from which compilable source code can be generated. The literate programming paradigm, as conceived by Knuth, represents a move away from writing computer programs in the manner and order imposed by the computer, and instead enables programmers to develop programs in the order demanded by the logic and flow of their thoughts. Literate programs are written as an uninterrupted exposition of logic in an ordinary human language, much like the text of an essay, in which macros are included to hide abstractions and traditional source code. Literate programming (LP) tools are used to obtain two representations from a literate source file: one suitable for further compilation or execution by a computer, the "tangled" code, and another for viewing as formatted documentation, which is said to be "woven" from the literate source. While the first generation of literate programming tools were computer language-specific, the later ones are language-agnostic and exist above the programming languages. None of that requires un-prefixed comment syntax. Consider examples of actual, full-scale literate programming projects, which are written in a variety of languages and source code formats. > If we would just use directives in comments then we already have org + > babel. But I think 4 extra lines of C code to enable this feature in > eval-loop was a trivial price to pay :-). Changing the canonical parser of a widely used language would have effects reaching far beyond the parser's native software. Consider all other software which parses Elisp, e.g. syntax highlighting tools outside of Emacs, which would not correctly highlight these un-prefixed comments you propose. As well, consider other implementations, like Guile's, which would also have to be adjusted. Then consider all the code linting tools which would likely need fixing. It's not merely a matter of 4 lines of code in an Emacs source file. As has been mentioned, benefits such as outlining are easily achieved with existing tools, some of which are even built-in to Emacs (e.g. outline-minor-mode for simple outlining in Elisp files, and org-mode for prose-first, noweb-style source files). Are you really so concerned about omitting a semicolon at the beginning of top-level comment lines that you want to change the Elisp parser? --_000_VI1P194MB0429EDCC0D522D6BAD1B205496530VI1P194MB0429EURP_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hello, sorry for a bit late answer, but I was very b= usy Monday/Tuesday.

 

To make this more readable I will try to summerize h= ere as one-piece text

for easier reading.

 

As you mention yourself from,Wikipedia, literate pro= gramming is about moving

away from programming for computers to programming f= or humans. Using comments

to comment-away text ment for humans or to mark line= s between comments and

code is indeed writing for the computer, not the hum= an. Humans tend to be

distracted by unnecessary clutter, and managing stuf= f just for the sake of

machine does take a little more effort then not doin= g it.

 

Being programming-language agnostic though is probab= ly not possible

without having some kind of special tool, or special= syntax due to some

languages being probably very hard to distinguish fr= om ordinary text. For

example I believe that C/C++ or even Bash or= Makefiles are very hard if

not impossible to process that way without some very= complicated parser. I

can also imagine case where Elisp is impossible to d= istinguish from text,

(for example this line is valid text but would fail = in parser), or whatever

we would put into a parenthesis on a separate line t= hat does not belong to code.

 

Anyway, due to elisp looks, we have those "natu= ral markers", ( and ) which

we can use as delimiters between code and text.

 

For the question of being concerned about omitting '= ;' to change the parser.

Well yes :-). Small syntactic sugar change but it re= duces that visual clutter.

It is one step in that direction of writing code for= humans and not for the

computer. See it as experiment. I thought it would b= e a cool thing to have. It

is just an idea. The change is not in an intrusive w= ay. All your elisp is

still very same. It just adds an extra feature prett= y much for free. If it would

be an intrusive change that requires your old elisp = to change, than I wouldn't

suggest it. By the way, one could also add a variabl= e to turn off that feature.

 

As for the tools, since old elisp code does not chan= ge, all your tools would

still continue to work on all your ordinary elisp, a= nd you could still use ';'

just as you do now. What would change is that you wo= uld be able to write some

elisp as you can't now, and only on that code the to= ols would probably get

confused. I have no idea how hard would it be to cha= nge font-locking and

indentation checkers, maybe hard, maybe not at all. = I can't answer that since I

am not acquianted with how those tools are implement= ed (lots of regex as I have

heard). But in worst case, you can always fall back = on writing ordinary elisp.

 

As a note, one will still have to use ';' in directi= ves, like ;;;###autoload

or ;;; -*- lexical-binding: t; -*- . Otherwise it wo= uld need lots more work
to get it to work, which I am not sure is worth.

 

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

 

arthur miller <art= hur.miller@live.com> writes:

> It is true, that keeping directives in comments does not break the
> existing parser, but then it is not so much of literate programming, > is it?

Literate programming is not a matter of syntax.  For example, this
summary in the Wikipedia article seems to describe it well:

  Literate programming is a programming paradigm introduced by Donald<= br>   Knuth in which a computer program is given an explanation of its log= ic
  in a natural language, such as English, interspersed with snippets o= f
  macros and traditional source code, from which compilable source cod= e
  can be generated.

  The literate programming paradigm, as conceived by Knuth, represents= a
  move away from writing computer programs in the manner and order
  imposed by the computer, and instead enables programmers to develop<= br>   programs in the order demanded by the logic and flow of their
  thoughts. Literate programs are written as an uninterrupted expositi= on
  of logic in an ordinary human language, much like the text of an
  essay, in which macros are included to hide abstractions and
  traditional source code.

  Literate programming (LP) tools are used to obtain two representatio= ns
  from a literate source file: one suitable for further compilation or=
  execution by a computer, the "tangled" code, and another f= or viewing
  as formatted documentation, which is said to be "woven" fr= om the
  literate source. While the first generation of literate programming<= br>   tools were computer language-specific, the later ones are
  language-agnostic and exist above the programming languages.

None of that requires un-prefixed comment syntax.  Consider examples o= f
actual, full-scale literate programming projects, which are written in a variety of languages and source code formats.

> If we would just use directives in comments then we already have org &= #43;
> babel. But I think 4 extra lines of C code to enable this feature in > eval-loop was a trivial price to pay :-).

Changing the canonical parser of a widely used language would have
effects reaching far beyond the parser's native software.  Consider al= l
other software which parses Elisp, e.g. syntax highlighting tools
outside of Emacs, which would not correctly highlight these un-prefixed
comments you propose.  As well, consider other implementations, like Guile's, which would also have to be adjusted.  Then consider all the<= br> code linting tools which would likely need fixing.  It's not merely a<= br> matter of 4 lines of code in an Emacs source file.

As has been mentioned, benefits such as outlining are easily achieved
with existing tools, some of which are even built-in to Emacs
(e.g. outline-minor-mode for simple outlining in Elisp files, and
org-mode for prose-first, noweb-style source files).

Are you really so concerned about omitting a semicolon at the beginning
of top-level comment lines that you want to change the Elisp parser?

 

--_000_VI1P194MB0429EDCC0D522D6BAD1B205496530VI1P194MB0429EURP_--