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: Christmas wish: Literate Elisp Date: Wed, 18 Dec 2019 20:04:09 +0000 Message-ID: References: <87r213qkhm.fsf@alphapapa.net> , <878sn9qxk3.fsf@alphapapa.net> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="_000_VI1P194MB0429CD885D5A3C60E74A97FC96530VI1P194MB0429EURP_" Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="72528"; 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 21:05:35 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 1ihfZd-000Id4-Ud for ged-emacs-devel@m.gmane.org; Wed, 18 Dec 2019 21:05:34 +0100 Original-Received: from localhost ([::1]:60042 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ihfZc-0004V2-Jj for ged-emacs-devel@m.gmane.org; Wed, 18 Dec 2019 15:05:32 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:51372) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ihfYP-0003VD-JU for emacs-devel@gnu.org; Wed, 18 Dec 2019 15:04:21 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ihfYL-0005dE-VA for emacs-devel@gnu.org; Wed, 18 Dec 2019 15:04:16 -0500 Original-Received: from mail-oln040092071030.outbound.protection.outlook.com ([40.92.71.30]:10445 helo=EUR03-DB5-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 1ihfYJ-0005ZI-Tl for emacs-devel@gnu.org; Wed, 18 Dec 2019 15:04:12 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=RXa3oeYZ5tRzeRlsRSOm+DPd2TlfjQL8gE+SAwdQ9y3Sf9r+Ew/rg/eJMIiP/uY7u7TrF0Lp2JjgcrjYWM3Pt6C3Kkr3ji1Dh39OIgUlAyaRKdudQwLmaBdnLZCxsDQDUZYSku37l2/M5T8GkMXOSfnWoA4yFTZAuXYfabnnIeceboJJEyW5F/y+UcZlvKUTaskNRWapPVF0wGWEcc49FaqCA4ZTQdBGNcLdSvAXOgeguHYO6dgk/+obNXjBEhG3cHZ2rxwF8yURssE0WqCbTqQDyVxBB1ute9mDazh4VzmlXwEJzN6u8ow+n5lPVsKLIN/7it7Kto7YvZfBE75LxA== 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=lEQwC+o0Ioi0Om9C0SMEhcmL7kNjzLMrbHhNKGqhZLE=; b=aLFNBQaqXuzQo8RSnSQDRxeBx4Gmh1CX02NkyR+MKl2OIw/AIb+MasPntkTPOV4GIBQsruji7kMBxuRXm+oB8vR44DMuS35aR0aV/uqIuLaPZDh1BJK+T11oyQdmBetw81uj6p3QIPnAveZFwTYL/ZiIhWTvQ68v5y3BOxyDrcDx9p/MWaNvsokbmFkqV/hfxQEeUM3gJ2J841r47pfL/8is5bdD/UIgnxzAN0m1Yxp8jeGeOn1EgMFWgc5ZiJKB5xVDAG14TmBfwvlymxxf3sZmHf1f7MY88Yrb7QQCjEnBFu04gYQY2Rg/q960vXAHw1SMX7XpLyqBwyxN/o/C4Q== 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=lEQwC+o0Ioi0Om9C0SMEhcmL7kNjzLMrbHhNKGqhZLE=; b=WW9x0qwtPRZpRMr4jF8avTMJRUx6xSu3Ky9OnoYTeL7Jg397q5PFv73DabxaRiNAUr2vsqBMoMjjFYf70gdT82LtPAAGZ4ktGh5KA6kcQ+CEBcIM1AwmT52KZ+R0w5VnLIJJyND1lC4Kei6UtPZ2rAKUv5Psn/rVrhHqXw0AKOE9ia6EaAAQIGibrO72TdeHgnrvQ5oxJi9t4cP52hzWeHhyjpUN0iRJyTT9bJHFQLM7KfymmrKP5CSEf+5cgIoXCxElx2j1RhBcPlNvFo4zQTlYna9e1RY56uQW4NSEn9O/UllyLhTNeWYBMly9yCRptFcSYcb0TQV6NO8WaXONGA== Original-Received: from AM5EUR03FT009.eop-EUR03.prod.protection.outlook.com (10.152.16.54) by AM5EUR03HT171.eop-EUR03.prod.protection.outlook.com (10.152.17.196) 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 20:04:09 +0000 Original-Received: from VI1P194MB0429.EURP194.PROD.OUTLOOK.COM (10.152.16.53) by AM5EUR03FT009.mail.protection.outlook.com (10.152.16.110) 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 20:04:09 +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 20:04:09 +0000 Thread-Topic: Sv: Sv: Sv: Christmas wish: Literate Elisp Thread-Index: AQHVsQLpbIcz5UxgfkCAm3tN+LzJEqe2wVZzgAJDFqiAAKl6MoAC8pPxgAAqfC+AAAV3ZoAAI1MAgACoIPyAAJZsXoAB5Il6gAAvTFqAAA1arg== In-Reply-To: <878sn9qxk3.fsf@alphapapa.net> Accept-Language: sv-SE, en-US Content-Language: sv-SE x-incomingtopheadermarker: OriginalChecksum:53DF78D215982A72827E6BD67E61F688455EECF8E5253535B62773663C2FC5BF; UpperCasedChecksum:AFC5811C4B50FB8C70ED3B92A2713E0264C166EC3B6B33C60291CC1ABA54C62C; SizeAsReceived:7657; Count:45 x-ms-exchange-messagesentrepresentingtype: 1 x-tmn: [kpap9nzOi617LgDfrEFj6+44OwDkGUdS] x-ms-publictraffictype: Email x-incomingheadercount: 45 x-eopattributedmessage: 0 x-ms-office365-filtering-correlation-id: e7936e6c-05ed-4b0f-4d8e-08d783f57184 x-ms-traffictypediagnostic: AM5EUR03HT171: x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: Pe1kFpYP+PJouz1c4xKMQO1knMkeXY63QYkeTc5/i/mdRK//tFvJZ43e9ILrNAxwwcAmOw64X/FZWLtkoaVs32yqziMytsnaf0pwoJCJg/tjQmA7TQW2VoREKF6fBzI2WftyyuXR+/uGSYcdFq1s6IPgc5KtE57cWwccwcp93jfXTfmJ9f5p6Zj0FJhxDZdA 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: e7936e6c-05ed-4b0f-4d8e-08d783f57184 X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: 00000000-0000-0000-0000-000000000000 X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Dec 2019 20:04:09.0496 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Internet X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM5EUR03HT171 X-detected-operating-system: by eggs.gnu.org: Windows 7 or 8 [fuzzy] X-Received-From: 40.92.71.30 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:243455 Archived-At: --_000_VI1P194MB0429CD885D5A3C60E74A97FC96530VI1P194MB0429EURP_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable > 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? > 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, Eve= rything will work as it does now. I don=92t see a problem there. If I am wrong please ex= plain. > 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? > Until we can write programs in human language, we must write both. For > humans' sake, the two need to be clearly separated. If you don't like > comment prefix syntax, you can use Org files and their source blocks, so > your prose and your code can both start at column 0. You can even > choose a face for org-meta-line that makes #+BEGIN_SRC lines virtually > (or literally!) disappear. 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. I d= on=92t see how org makes it any different? In org you still have to use both =92;=92 and #= +BEGIN_SRC - #+END_SRC markers. So it is even more clutter to eye. It is not about start= ing at column 0, 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 th= ink it violates old ways, so obviously we wont agree on that one. But thank you for the discuss= ion, I surely appreciate the input, even if I don=92t agree on the main conclusion. I gla= dly read more! As a small reflection about us humans being slentrians, I have an illustrat= ion. Caves are still as good for living as they were 20 000 years ago. We can fo= r sure make many cases against living in houses such as not being natural, can cra= sh 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 may= be 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. Fr=E5n: Adam Porter Skickat: den 18 december 2019 19:50 Till: emacs-devel@gnu.org =C4mne: Re: Sv: Sv: Sv: Christmas wish: Literate Elisp arthur miller writes: > As you mention yourself from,Wikipedia, literate programming is about mov= ing > away from programming for computers to programming for humans. Using comm= ents > to comment-away text ment for humans or to mark lines between comments an= d > 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 o= f > machine does take a little more effort then not doing it. ; I am not more distracted while reading this line of text than I am while reading this one. 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. > I can also imagine case where Elisp is impossible to distinguish from tex= t, > (for example this line is valid text but would fail in parser), or whatev= er > we would put into a parenthesis on a separate line that does not > belong to code. That line beginning with a paren parses as valid Elisp. Whether it evaluates depends on the context. > Anyway, due to elisp looks, we have those "natural markers", ( and ) whic= h > we can use as delimiters between code and text. 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. > For the question of being concerned about omitting ';' to change the pars= er. > Well yes :-). Small syntactic sugar change but it reduces that visual > clutter. You call it clutter; I call it clearly delineating code and prose. What would look cluttered to me would be prose (which may include commented-out code) interspersed with (insert "code, which may include or generate prose.") > It is one step in that direction of writing code for humans and not for t= he > computer. Until we can write programs in human language, we must write both. For humans' sake, the two need to be clearly separated. If you don't like comment prefix syntax, you can use Org files and their source blocks, so your prose and your code can both start at column 0. You can even choose a face for org-meta-line that makes #+BEGIN_SRC lines virtually (or literally!) disappear. > 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 wouldn't suggest it. By the way, one could also add > a variable to turn off that feature. No, in fact, some of my Elisp would have to change, because it would no longer be sufficient to look at comment prefixes to know whether a line is 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. And since parens can appear at the start of lines in prose, how would anyone but a human know whether a line is code or prose? > As for the tools, since old elisp code does not change, all your tools > would 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 some 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 since 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 elisp. My tools which handle Elisp would have no such luxury, because they must handle all valid Elisp. > I have no idea how hard would it be to change font-locking and > indentation checkers, maybe hard, maybe not at all. Please, if you won't take my word for it, try it and see. --_000_VI1P194MB0429CD885D5A3C60E74A97FC96530VI1P194MB0429EURP_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

> On the contrary, the semicolon prefix (and font= ification 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 + identati= on enough?


> No, in fact, some of my Elisp would have to change, because it would n= o
> 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 term= s of
> the necessary human work that would ripple outward.  And your pro= posed
> 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 liter= al 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.

> This is the problem: as you have shown, parentheses commonly appear in=
> prose, even at the beginning of lines.  Punctuation, such as semi= colons,
> do not
> ; or, at least, should not

 

Yes, and it is always possible to construct some obs= cure case where things break.

Look for example at C or C++ and all undefin= ed 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 pro= gramming, and there is one

explicit case not allowed to use, how important is t= han to use exactly that

constrcut? I mean considering cons and pros, should = one abandon the entire

idea because of one minor obscurity?

> Until we can write programs in human language, = we must write both.  For
> humans' sake, the two need to be clearly separated.  If you don't= like
> comment prefix syntax, you can use Org files and their source blocks, = so
> your prose and your code can both start at column 0.  You can eve= n
> choose a face for org-meta-line that makes #+BEGIN_SRC lines virtu= ally
> (or literally!) disappear.

 

Well as I see literal programming it is to make it e= asier for humans to mix code and

prosa. What I proposedis just one small step further= in that direction. 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. So it is even more clutter to= eye. It is not about starting at column 0,

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 coo= l thing, you seem to think it violates old

ways, so obviously we wont agree on that one. But th= ank you for the discussion, I surely

appreciate the input, even if I don=92t agree on the= main conclusion. I gladly read more!

 

As a small reflection about us humans being slentria= ns, I have an illustration.
Caves are still as good for living as they were 20 000 years ago. We c= an 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. Bu= t yet, pros of liiving in houses outweigh

far the cons, and not many people today prefer to li= ve 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 devel= opment 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.=

 

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

 

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

> As you mention yourself from,Wikipedia, literate programming is about = moving
> away from programming for computers to programming for humans. Using c= omments
> 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 sak= e of
> machine does take a little more effort then not doing it.

; I am not more distracted while reading this line of text
than I am while reading this one.

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.

> 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 wha= tever
> we would put into a parenthesis on a separate line that does not
> belong to code.

That line beginning with a paren parses as valid Elisp.  Whether it evaluates depends on the context.

> Anyway, due to elisp looks, we have those "natural markers",= ( and ) which
> we can use as delimiters between code and text.

This is the problem: as you have shown, parentheses commonly appear in
prose, even at the beginning of lines.  Punctuation, such as semicolon= s,
do not
; or, at least, should not.

> For the question of being concerned about omitting ';' to change the p= arser.
> Well yes :-). Small syntactic sugar change but it reduces that visual<= br> > clutter.

You call it clutter; I call it clearly delineating code and prose.  Wh= at
would look cluttered to me would be prose (which may include commented-out<= br> code) interspersed with
(insert "code, which may include or generate prose.")

> It is one step in that direction of writing code for humans and not fo= r the
> computer.

Until we can write programs in human language, we must write both.  Fo= r
humans' sake, the two need to be clearly separated.  If you don't like=
comment prefix syntax, you can use Org files and their source blocks, so your prose and your code can both start at column 0.  You can even
choose a face for org-meta-line that makes #+BEGIN_SRC lines virtually<= br> (or literally!) disappear.

> 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 fo= r
> free. If it would be an intrusive change that requires your old elisp<= br> > to change, than I wouldn't suggest it. By the way, one could also add<= br> > a variable to turn off that feature.

No, in fact, some of my Elisp would have to change, because it would no
longer be sufficient to look at comment prefixes to know whether a line
is 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.

And since parens can appear at the start of lines in prose, how would
anyone but a human know whether a line is code or prose?

> As for the tools, since old elisp code does not change, all your tools=
> would 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<= br> > be able to write some 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 since 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 elisp.=

My tools which handle Elisp would have no such luxury, because they must handle all valid Elisp.

> I have no idea how hard would it be to change font-locking and
> indentation checkers, maybe hard, maybe not at all.

Please, if you won't take my word for it, try it and see.

 

--_000_VI1P194MB0429CD885D5A3C60E74A97FC96530VI1P194MB0429EURP_--