From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Adam Porter Newsgroups: gmane.emacs.devel Subject: Re: Sv: Sv: Sv: Christmas wish: Literate Elisp Date: Wed, 18 Dec 2019 12:49:00 -0600 Message-ID: <878sn9qxk3.fsf@alphapapa.net> References: <87r213qkhm.fsf@alphapapa.net> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="34498"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Dec 18 19:51:01 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 1ihePU-0008lH-Ns for ged-emacs-devel@m.gmane.org; Wed, 18 Dec 2019 19:51:00 +0100 Original-Received: from localhost ([::1]:59080 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ihePT-0002ol-Ed for ged-emacs-devel@m.gmane.org; Wed, 18 Dec 2019 13:50:59 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:52342) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iheNr-0001f8-RZ for emacs-devel@gnu.org; Wed, 18 Dec 2019 13:49:21 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1iheNq-0000jN-CG for emacs-devel@gnu.org; Wed, 18 Dec 2019 13:49:19 -0500 Original-Received: from 195-159-176-226.customer.powertech.no ([195.159.176.226]:41218 helo=blaine.gmane.org) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1iheNq-0000ZF-0Q for emacs-devel@gnu.org; Wed, 18 Dec 2019 13:49:18 -0500 Original-Received: from list by blaine.gmane.org with local (Exim 4.89) (envelope-from ) id 1iheNn-0006wc-8n for emacs-devel@gnu.org; Wed, 18 Dec 2019 19:49:15 +0100 X-Injected-Via-Gmane: http://gmane.org/ X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 195.159.176.226 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:243453 Archived-At: arthur miller writes: > As you mention yourself from,Wikipedia, literate programming is about moving > away from programming for computers to programming for humans. Using comments > 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. ; 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 whatever > 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 semicolons, do not ; or, at least, should not. > For the question of being concerned about omitting ';' to change the parser. > 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 the > 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.