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: Christmas wish: Literate Elisp Date: Thu, 12 Dec 2019 15:45:50 +0000 Message-ID: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="_000_VI1P194MB04294449E6CCFFBB191565B596550VI1P194MB0429EURP_" Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="218760"; mail-complaints-to="usenet@blaine.gmane.org" To: emacs-devel Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Dec 12 16:47:13 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 1ifQgK-000um9-LT for ged-emacs-devel@m.gmane.org; Thu, 12 Dec 2019 16:47:12 +0100 Original-Received: from localhost ([::1]:33314 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ifQgJ-00017C-FE for ged-emacs-devel@m.gmane.org; Thu, 12 Dec 2019 10:47:11 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:49377) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ifQf9-0008Nf-PI for emacs-devel@gnu.org; Thu, 12 Dec 2019 10:46:02 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ifQf6-0005k8-AB for emacs-devel@gnu.org; Thu, 12 Dec 2019 10:45:59 -0500 Original-Received: from mail-oln040092072019.outbound.protection.outlook.com ([40.92.72.19]:25094 helo=EUR03-VE1-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 1ifQf5-0005bU-Qb for emacs-devel@gnu.org; Thu, 12 Dec 2019 10:45:56 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Km4Y6zkhSSLKVSIkf740mSTI8blmvMmfS1gLXORWg/WK5yEzq6yJ9uFlUJ+D0Wh1aWf59I5zqgxR0txKuyWnBVcWFHCTCBe6tV/yp0GBl2Ud9dk6BlXe7H2sPUFnsIzWiXg4jRf9SICODbvycmtqOYkLiSS3e1dNTtjFmlclgRfGopnYfjidvAbU3DHY8+2T8Kin6vy/e5lUsUI1WCGMH/imOhtiBwyTKKYx9kF7/7+KT5gIlujtdMI4yIxAgsjwP4Olc6sZgG1/xrAEB909LWt35t+1ZhuNxm5rQIvwByjd0qYBxHrs2rdc/yYqNtVM+hAO9A2eWFKcpFYENLvxmw== 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=CRHNfyu/j/53d2pJfk+yNpYN88aIXRAx0A+NtMWFeJE=; b=fxvOKZw9wPCaA2Dzcc6k5D56pix1fE5K9viDzasNN2z6NBs1jmFRWnQNliiBxkEV4qO9iDyA3/DVQ7REbApru7v+dvEFqC9SxhjEqGuW8BnjMB82PQVbcShYc+aL8b3Fgd78ucfI3pN3jzEjE2OC7OpQ/2TYTwDj6565Smd72Lb88Hw0XN582I2HZ3sYhIb913uifU/gaLN5BbJ7YDrJhOCKHURtXWftOduhA5WUg9ZXrl2ybtCYGn80iF4l1/4WjNhlF47aABEJpVwO2yr52GoArV2+fcuvUqYrH6+IRzU18aGyjA8fh0MxsoAwUwRqQ9llkxdkIU6n6+uJlClQIg== 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=CRHNfyu/j/53d2pJfk+yNpYN88aIXRAx0A+NtMWFeJE=; b=M6PWZ/IRPQ+UgPbMubj/2dS8Zu5sdVwbM/mWCsr0+LloKxb4AcTRKoHxBvm2E1vm1ZEpJ0Rqt/W6hnDFnO+LpJ1/rlkx8+uIvy96cXh2u83dH2TamVeK3W3K9kSFhIOtsIGHFpen4ff54ED+a9G36zJ2vMPC0Cg3DQuBq3s/74LR/Rm6a8yGIRChEPxC2FeIbMHzyNqO9X+zLnVJDztjzGVMIuIPRXvTNxh2Kw87vdr2rvaAXCfPqbnH1GcyeOCHp18xIqtO79Pdd4SwP9txRVL2itUXUS5avfCo0qK31kpEcWh7wrApnyBcNN6m1AmSuU6ZI5tiC7Egf4PLzDkFgg== Original-Received: from AM5EUR03FT048.eop-EUR03.prod.protection.outlook.com (10.152.16.59) by AM5EUR03HT022.eop-EUR03.prod.protection.outlook.com (10.152.17.50) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2495.18; Thu, 12 Dec 2019 15:45:51 +0000 Original-Received: from VI1P194MB0429.EURP194.PROD.OUTLOOK.COM (10.152.16.55) by AM5EUR03FT048.mail.protection.outlook.com (10.152.17.177) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2495.18 via Frontend Transport; Thu, 12 Dec 2019 15:45:51 +0000 Original-Received: from VI1P194MB0429.EURP194.PROD.OUTLOOK.COM ([fe80::4dfb:9ce1:cd8b:7dc0]) by VI1P194MB0429.EURP194.PROD.OUTLOOK.COM ([fe80::4dfb:9ce1:cd8b:7dc0%6]) with mapi id 15.20.2538.016; Thu, 12 Dec 2019 15:45:51 +0000 Thread-Topic: Christmas wish: Literate Elisp Thread-Index: AQHVsQLpbIcz5UxgfkCAm3tN+LzJEg== Accept-Language: sv-SE, en-US Content-Language: sv-SE x-incomingtopheadermarker: OriginalChecksum:15E57463AECED285E1B19D0598E477F161170C83C7DBE0B4A5AEA2918691B7A9; UpperCasedChecksum:94B59F5456574E8FB39848AC9374DB806BBF11DC8A7406660C9700D9B6E16591; SizeAsReceived:6659; Count:42 x-tmn: [Siqdr8rbP7K7e7ITAl9duB0Dme8t3Bq/] x-ms-publictraffictype: Email x-incomingheadercount: 42 x-eopattributedmessage: 0 x-ms-office365-filtering-correlation-id: f9896486-7b88-40b2-adaa-08d77f1a5d7e x-ms-traffictypediagnostic: AM5EUR03HT022: x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: SYIpOD9hvtKDFfsZ6O02ndQXebhJy4+9hRkKvrzn6hR/yRv2qR9Ku3AfN90SWQNJfxANG5tK/8pqTXWJrRSvMnVldCfG+l3CZSEt8lQA11uTaZaWCGi6oWsxBjPRQ33TdZ8AtYsz8JGTYFVs4GSLFrahRx6K9nj2ImhXGnOHksElHOYzkHbEeICsaL+eC6xL 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: f9896486-7b88-40b2-adaa-08d77f1a5d7e X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: 00000000-0000-0000-0000-000000000000 X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Dec 2019 15:45:50.9475 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Internet X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM5EUR03HT022 X-detected-operating-system: by eggs.gnu.org: Windows 7 or 8 [fuzzy] X-Received-From: 40.92.72.19 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:243326 Archived-At: --_000_VI1P194MB04294449E6CCFFBB191565B596550VI1P194MB0429EURP_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello, I have a question/proposal about Elisp and literate programming. Well, more of a proposal then a question, but here it is: >From Wikipedia: "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." Emacs already supports a form of literal programming in form of org mode and babel where we can insert code for programming languages in-between #+BEGIN_SRC and #+END_SRC markers, which is super nice and cool feature. However I got a thought that LISPs (lisp-like languages), have natural code markers, since all code is enclosed with parenthesis. Thus one could see '(' and ')' as code markers in literate-programming style, more of as Knuth proposed. In other words, LISP (or at least Elisp) does not need special markers to denote start and end of code. Unlike Haskell, there is no need to use '\begin_code' or '>' to differentiate code from text (comments). My proposal is to slightly change Elisp parser to treat lines that start with any other printable character but '(' as a start of comment and to simply ignore the line, just as it treats ';' as a comment. Code blocks would still be parsed as they are now, and ';' would still mean a comment, wherever it is encountered, it is just that anything that does not belong in a code-block (lists) is a comment. For example consider this mail= , if this would be thrown into parser all lines to this point would be simply ignored since they don't start with '(' or are white spaces. (my-elisp-fun (progn (while (very-cool) (do-something-very-literate-here)))) Then I could have Elisp code in between and continue to write this mail and later on just use this as a source code. Wouldn't that be a step toward true and more cool literate programming language? Below is another snippet of imaginary Elisp. If we could do this, then this email would be a working literate Elisp, where those two snippets are code and text of this mail is just ignored. (my-other-fun (progn ; this-is-some-other-fun (to-hopefully-demonstrate-the-idea))) What would this achieve More then highly increased coolness factor, it would be a small quality of life improvement. For example this would actually make it slightly easier to use org-mode for Elisp programming. For example for us that use org-mode to structure Emacs init file, we could just throw in our org file directly, instead of using babel to entangle it into Elisp file first. If every printable character but '(' starts a comment line, then everything in org-file but Elisp code would be simply ignored, and only Elisp executed= . If we think other way around, it would also let us use pure Elisp for liter= ate programming without org-mode whatsoever, albeit it would be a cool feature = to use org-headings and similar to structure the code. It might make code more structured and thus more readable. When I think in terms of Elisp as a star= ting point rather then in terms of org-mode as a starting point, that could resu= lt in adding org-mode organizational features directly to Elisp. One could even m= ark say not-implemented functions as todo items, use calendar etc. We could also entangle other languages within pure Elisp code without using= org mode whatsoever. Either within some code markers for processing them out to separate files, or without code markers just as documentation or whatever. = I don't have some better example of use-case at the moment. I don't mean that it is incredibly slow to entangle files, but it would be slightly more efficient to process Elisp entangled in org mode. I also don'= t think it is hard to type ';' at the beginning of a line to start a comment = line. But it is a small convenience and thus quality of life improvement that pro= bably does not need much changes to a parser but has quite a dramatic effect on h= ow source code looks in human eye (at least mine, if you don't mind that I cou= nt myself as a part of the species :-)). It would let us use org-mode as a sta= ndard Elisp source code format, which might be just a perceived convenience rathe= r then some real extra useful thing that does not exist yet. Some thoughts about implementation I think that in terms of cost effectiveness with implementation in mind, it probably isn't that much work to implement this, but honestly I have no ide= a. I believe it can't be much work, but I am not sure so I should really put a= n exclamation mark to word probably in paragraph above. Feel free to educate = me about cost of making it work. I was looking myself in C source to see if I = could test this myself before I post here, but I couldn't find where you have imp= lemented parser. I am sorry, but I am that bad :-(. Essentially when parsing literate Elisp, if I may call it so, what parser has to do is to simply not flag random printable characters, on line= s that does not belong to code-blocks, as errors in source code. Instead just= treat them as if it has seen a ';'. It means there are just two classes of printable characters: '(' that opens a code block, and everything else that opens a comment block. Well almost. Parsing code blocks would not need to be changed at all, and ';' in code bl= ocks would still mean that rest of line is a comment, and all code with comments would still continue to work as it does now. It would only affect new code = that is written in this style. However new Elisp code wouldn't be backward compatible with old versions of Emacs. As extra, one could keep current Elisp parser and make new one and use as in Haskell, en extra 'l' in suffix to denote a literate program, '.lel'. Th= ough it kind-a looks fun, I don't think it wouldn't be needed, I don't think thi= s change would need different parser, to ensure backward compatibility. I don= 't think that is very important since if we would write Elisp that needs to ru= n on older versions, we can just let be to write it in literal form. Drawbacks As I can think of, it would maybe make spotting errors slightly harder, for example I could type a random character before an opening parenthesis and comment out entire line, but those kind of errors are easily spotted on fir= st code run. Another drawback would be probably syntax highlighting. It could proba= bly become much harder to detect comments in code since there is no ';' to mark= a comment-line. Maybe I am wrong about this one, it is just a fast thought. Final thought I have no idea if somebody else has already thought about this and found th= at it can't work. It seems like a very straight-forward and simple thing so I am probably not the first one to think the thought, and there is probably some reason why it is not done that I am not aware of. In that case just ignore = this email. It was just a thought I got yesterday. There might be something I am= not aware of that makes this impossible, I am not that familiar with Emacs sour= ce to try to implement this myself unfortunately. It is just an idea, a thought f= or discussion, but it would be cool if it can work. I am sorry for very long email, I hope you have at least somewhat enjoyed m= y rather ramblings and Christmas wishes, and please ask Santa to excuse my English, I am not native English speaker, it is just my 3rd language if it = is in any defense or my horrible writing. --_000_VI1P194MB04294449E6CCFFBB191565B596550VI1P194MB0429EURP_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hello,

I have a question/proposal about Elisp and literate programming.
Well, more of a proposal then a question, but here it is:

From Wikipedia: "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."

Emacs already supports a form of literal programming in form of
org mode and babel where we can insert code for programming
languages in-between #+BEGIN_SRC and #+END_SRC markers,
which is super nice and cool feature.

However I got a thought that LISPs (lisp-like languages), have natural=
code markers, since all code is enclosed with parenthesis. Thus one
could see '(' and ')' as code markers in literate-programming style,
more of as Knuth proposed. In other words, LISP (or at least Elisp)
does not need special markers to denote start and end of code. Unlike<= br>
Haskell, there is no need to use '\begin_code' or '>' to differenti= ate
code from text (comments).

My proposal is to slightly change Elisp parser to treat lines that sta= rt
with any other printable character but '(' as a start of comment and t= o
simply ignore the line, just as it treats ';' as a comment. Code block= s
would still be parsed as they are now, and ';' would still mean a comm= ent,
wherever it is encountered, it is just that anything that does not
belong in a code-block (lists) is a comment. For example consider this= mail,
if this would be thrown into parser all lines to this point would be s= imply
ignored since they don't start with '(' or are white spaces.

(my-elisp-fun
        (progn
                (while (very-c= ool)
                    =    (do-something-very-literate-here))))

Then I could have Elisp code in between and continue to write this mai= l
and later on just use this as a source code. Wouldn't that be a step
toward true and more cool literate programming language? Below is anot= her
snippet of imaginary Elisp. If we could do this, then this email would= be
a working literate Elisp, where those two snippets are code and text o= f
this mail is just ignored.

(my-other-fun
        (progn
                ; this-is-some= -other-fun
                (to-hopefully-= demonstrate-the-idea)))

What would this achieve

More then highly increased coolness factor, it would be a small qualit= y
of life improvement. For example this would actually make it slightly<= br>
easier to use org-mode for Elisp programming. For example for us that<= br>
use org-mode to structure Emacs init file, we could just throw in our = org
file directly, instead of using babel to entangle it into Elisp file f= irst.
If every printable character but '(' starts a comment line, then every= thing
in org-file but Elisp code would be simply ignored, and only Elisp exe= cuted.

If we think other way around, it would also let us use pure Elisp for = literate
programming without org-mode whatsoever, albeit it would be a cool fea= ture to
use org-headings and similar to structure the code. It might make code= more
structured and thus more readable. When I think in terms of Elisp as a= starting
point rather then in terms of org-mode as a starting point, that could= result in
adding org-mode organizational features directly to Elisp. One could e= ven mark
say not-implemented functions as todo items, use calendar etc.

We could also entangle other languages within pure Elisp code without = using org
mode whatsoever. Either within some code markers for processing them o= ut to
separate files, or without code markers just as documentation or whate= ver. I
don't have some better example of use-case at the moment.

I don't mean that it is incredibly slow to entangle files, but it woul= d be
slightly more efficient to process Elisp entangled in org mode. I also= don't
think it is hard to type ';' at the beginning of a line to start a com= ment line.
But it is a small convenience and thus quality of life improvement tha= t probably
does not need much changes to a parser but has quite a dramatic effect= on how
source code looks in human eye (at least mine, if you don't mind that = I count
myself as a part of the species :-)). It would let us use org-mode as = a standard
Elisp source code format, which might be just a perceived convenience = rather
then some real extra useful thing that does not exist yet.

Some thoughts about implementation

I think that in terms of cost effectiveness with implementation in min= d, it
probably isn't that much work to implement this, but honestly I have n= o idea.
I believe it can't be much work, but I am not sure so I should really = put an
exclamation mark to word probably in paragraph above. Feel free to edu= cate me
about cost of making it work. I was looking myself in C source to see = if I could
test this myself before I post here, but I couldn't find where you hav= e implemented
parser. I am sorry, but I am that bad :-(.

Essentially when parsing literate Elisp, if I may call it so, what
parser has to do is to simply not flag random printable characters, on= lines
that does not belong to code-blocks, as errors in source code. Instead= just treat
them as if it has seen a ';'.

It means there are just two classes of printable characters: '(' that = opens
a code block, and everything else that opens a comment block. Well alm= ost.
Parsing code blocks would not need to be changed at all, and ';' in co= de blocks
would still mean that rest of line is a comment, and all code with com= ments
would still continue to work as it does now. It would only affect new = code that
is written in this style. However new Elisp code wouldn't be backward<= br>
compatible with old versions of Emacs.

As extra, one could keep current Elisp parser and make new one and use= as
in Haskell, en extra 'l' in suffix to denote a literate program, '.lel= '. Though
it kind-a looks fun, I don't think it wouldn't be needed, I don't thin= k this
change would need different parser, to ensure backward compatibility. = I don't
think that is very important since if we would write Elisp that needs = to run on
older versions, we can just let be to write it in literal form.

Drawbacks

As I can think of, it would maybe make spotting errors slightly harder= , for
example I could type a random character before an opening parenthesis = and
comment out entire line, but those kind of errors are easily spotted o= n first code
run. Another drawback would be probably syntax highlighting. It could = probably
become much harder to detect comments in code since there is no ';' to= mark a
comment-line. Maybe I am wrong about this one, it is just a fast thoug= ht.

Final thought

I have no idea if somebody else has already thought about this and fou= nd that it
can't work. It seems like a very straight-forward and simple thing so = I am
probably not the first one to think the thought, and there is probably= some
reason why it is not done that I am not aware of. In that case just ig= nore this
email. It was just a thought I got yesterday. There might be something= I am not
aware of that makes this impossible, I am not that familiar with Emacs= source to
try to implement this myself unfortunately. It is just an idea, a thou= ght for
discussion, but it would be cool if it can work.

I am sorry for very long email, I hope you have at least somewhat enjo= yed my
rather ramblings and Christmas wishes, and please ask Santa to excuse = my
English, I am not native English speaker, it is just my 3rd language i= f it is in
any defense or my horrible writing.

--_000_VI1P194MB04294449E6CCFFBB191565B596550VI1P194MB0429EURP_--