From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Unknown Newsgroups: gmane.emacs.devel Subject: Re: Christmas wish: Literate Elisp Date: Sat, 21 Dec 2019 00:58:51 +0900 Message-ID: <1723CF55-FAC1-4B72-B578-FE44D427C1F2@icloud.com> References: <87r213qkhm.fsf@alphapapa.net> <878sn9qxk3.fsf@alphapapa.net> <87zhfpp6is.fsf@alphapapa.net> Reply-To: =?UTF-8?Q?=C3=AC=C2=A1=C2=B0=C3=AC=C2=84=C2=B1=C3=AB=C2=B9=C2=88=20=3Cpcr910303=40?= =?UTF-8?Q?icloud=2Ecom=3E?= Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.40.2.2.4\)) Content-Type: text/plain; charset=utf-8; delsp=yes; format=flowed Content-Transfer-Encoding: quoted-printable Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="139023"; 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 Fri Dec 20 16:59:07 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 1iiKgF-000Zy7-2b for ged-emacs-devel@m.gmane.org; Fri, 20 Dec 2019 16:59:07 +0100 Original-Received: from localhost ([::1]:58294 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iiKgD-00081R-Rd for ged-emacs-devel@m.gmane.org; Fri, 20 Dec 2019 10:59:05 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:49320) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iiKg7-00081K-5F for emacs-devel@gnu.org; Fri, 20 Dec 2019 10:59:00 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1iiKg5-0001CO-8q for emacs-devel@gnu.org; Fri, 20 Dec 2019 10:58:59 -0500 Original-Received: from mr85p00im-ztdg06021201.me.com ([17.58.23.189]:50194) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1iiKg4-0001BR-Vt for emacs-devel@gnu.org; Fri, 20 Dec 2019 10:58:57 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=icloud.com; s=1a1hai; t=1576857535; bh=LZt6WUgrnI4aF5196A/OzjK+x+hNz/xh5zPGp42e+ag=; h=Content-Type:Subject:From:Date:Message-Id:To; b=BkUclQh5f+FukxEpbsN3ZK1YF6KlfxVzhHsuDdB2BS9HyxMsNXP1Xe3g6JBqKQd+N gSbhBtFS+ja7MTj+TupcBy7xisyKgIm2BpIlT+2EYo1KV2MQYVNvp3KYrRIDPwqQES lQzMugSogS1255Nrk0hm+QoDaCKXLvAqD3dIlw6SfcayCh5mFQ+TAWDg/Y2Le9Klad d+sS4h5dxN2PfAZ6sYmTHwQeaLvPYz+96g4+RSRhCAOsX0XNJ9tD/eY6RygIy86PLL rhEFsQmS5K/cjINAl7bnq6rP9Hi+fyXBDzgFIFi7DEWGU3vmLVvCP11zGVRg5pxNk8 UmTViOUXyT9Sg== Original-Received: from [192.168.0.18] (unknown [1.230.108.64]) by mr85p00im-ztdg06021201.me.com (Postfix) with ESMTPSA id D6B9912055B; Fri, 20 Dec 2019 15:58:54 +0000 (UTC) In-Reply-To: X-Mailer: Apple Mail (2.3608.40.2.2.4) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-12-20_04:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1908290000 definitions=main-1912200126 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 17.58.23.189 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" Original-From: =?UTF-8?Q?=C3=AC=C2=A1=C2=B0=C3=AC=C2=84=C2=B1=C3=AB=C2=B9=C2=88=20via=20=22Emacs=20?= =?UTF-8?Q?development=20discussio?= =?UTF-8?Q?ns=2E=22=20=3Cemacs=2Ddevel=40gnu?= =?UTF-8?Q?=2Eorg=3E?= Xref: news.gmane.org gmane.emacs.devel:243513 Archived-At: arthur miller =EC=9E=91=EC=84=B1: > I don=E2=80=99t want to repeat myself, but I am sure that as long as on= e don=E2=80=99t > use the new feature all your external tools will continue to work as > they do now. If you don=E2=80=99t write literal code then your code wou= ld 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=E2=80=99t deal with =E2=80=9Dli= teral syntax=E2=80=9D, > than don=E2=80=99t use the literal syntax or the tool. Is that a proble= m? Yeah, it is, mostly because code written be people who believes that =20 writing prose interleaved with Elisp without any explicit markers (like =20 you) will break the existing tools. If one decided to push their prose-with-elisp code to GitHub, GitHub=E2=80= =99s =20 Elisp highlighter would be confused. That=E2=80=99s just one example with= the =20 problem. You might totally be fine with that: you know that it=E2=80=99s = not the =20 usual syntax=E2=80=A6 but other people would find out & be upset about th= at. I bet there will be elisp-mundging code in Emacs that aren=E2=80=99t hook= ed onto =20 the reader=E2=80=A6 which means that those code will be also broken. > 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=E2=80=99t 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=E2=80=99t buy the argument that h= umans > need some special markers to understand the difference between code > and text. The whole Idea with literal programming is to minimize that > difference. Well, maybe the whole idea of literal programming is to minimize the =20 difference, but elisp isn=E2=80=99t for literal programming right? If you really want this, I would nudge you to make a Elisp dialect =20 optimized for literal programming implemented by a preprocessor in the =20 front of the Elisp reader. I really can=E2=80=99t see why this is beneficial to anyone (except maybe= for you). > Fr=C3=A5n: Adam Porter > Skickat: den 19 december 2019 00:18 > Till: emacs-devel@gnu.org > =C3=84mne: Re: Sv: Sv: Sv: Sv: Christmas wish: Literate Elisp > > arthur miller writes: > > >> On the contrary, the semicolon prefix (and fontification according t= o > >> my preferences in Elisp buffers) makes it easy for me to see what is > >> code and what is prose. > > > > Aren=E2=80=99t starting =E2=80=99(=E2=80=99 and =E2=80=99)=E2=80=99 += 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 bot= h > >> states in my code. > > > > In which way? Can you alaborate more please? You would not need to > > write anything special. If you don=E2=80=99t wish to write literal co= de, then > > just don=E2=80=99t. Prefix your comment lines with =E2=80=99;=E2=80=99= as currently and don=E2=80=99t > > care about it, Everything will work as it does now. I don=E2=80=99t s= ee 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 you= r > 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 semicol= ons, > >> 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 o= r > > 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=E2=80=99t see how org makes it any different? In org you still = have to > > use both =E2=80=99;=E2=80=99 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 i= s > > 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=E2=80=99s inhabitants, cos= t > > 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 =E2=80=99;=E2=80=99 just continue to use it. But if a c= hange 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 proposa= l > is like being a cave-dweller.