From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Stephen J. Turnbull" Newsgroups: gmane.emacs.devel Subject: Re: Upcoming loss of usability of Emacs source files and Emacs. Date: Wed, 17 Jun 2015 16:17:17 +0900 Message-ID: <87k2v2hkhu.fsf@uwakimon.sk.tsukuba.ac.jp> References: <20150615142237.GA3517@acm.fritz.box> <87y4jkhqh5.fsf@uwakimon.sk.tsukuba.ac.jp> <557F3C22.4060909@cs.ucla.edu> <87eglbff5n.fsf@debian.uxu> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 X-Trace: ger.gmane.org 1434525513 24794 80.91.229.3 (17 Jun 2015 07:18:33 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 17 Jun 2015 07:18:33 +0000 (UTC) Cc: emacs-devel@gnu.org To: Emanuel Berg Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Jun 17 09:18:25 2015 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Z57bS-0000vH-Ou for ged-emacs-devel@m.gmane.org; Wed, 17 Jun 2015 09:17:42 +0200 Original-Received: from localhost ([::1]:44869 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z57bN-00061R-2P for ged-emacs-devel@m.gmane.org; Wed, 17 Jun 2015 03:17:37 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:39393) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z57bA-0005am-2H for emacs-devel@gnu.org; Wed, 17 Jun 2015 03:17:30 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Z57b6-0003AI-KF for emacs-devel@gnu.org; Wed, 17 Jun 2015 03:17:24 -0400 Original-Received: from shako.sk.tsukuba.ac.jp ([130.158.97.161]:45518) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z57b6-00039D-9t for emacs-devel@gnu.org; Wed, 17 Jun 2015 03:17:20 -0400 Original-Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by shako.sk.tsukuba.ac.jp (Postfix) with ESMTPS id D1E9E1C3920; Wed, 17 Jun 2015 16:17:17 +0900 (JST) Original-Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id B6A031A2CA2; Wed, 17 Jun 2015 16:17:17 +0900 (JST) In-Reply-To: <87eglbff5n.fsf@debian.uxu> X-Mailer: VM undefined under 21.5 (beta34) "kale" 83e5c3cd6be6 XEmacs Lucid (x86_64-unknown-linux) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 130.158.97.161 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 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-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:187234 Archived-At: Emanuel Berg writes: > But when it is computers, it is English, True. There is very good reason to agree on one language to draw keywords from[1], and similarly for one encoding for characters. The choice of English is due to backward compatibility, however -- if we had chosen a Han language, all keywords and variables could be single characters, removing the lexing problem from program analysis and allowing some operation to be denoted implicitly by juxtaposition.[2] (I don't know if that would be a good change, but it would be an interesting experiment. It's pretty much foreclosed for the next several decades -- Chinese programmers and teachers of programmers, who are used to English-derived programming languages, would resist such a change, too!) > and it is ASCII, This restriction, however, has only one justification, and that is backward compatibility with systems incompetent to display non-ASCII Unicode, and with humans who prefer not to learn the new conventions and configure their systems to deal with them conveniently. One of the great ideas in Lisp was that parentheses would be the *only* syntax. Parentheses are asymmetric delimiters, making Lisp exceedingly easy and efficient to parse, even from "inside" an expression. Then we add comments (with asymmetric delimiters, ";" and "\n") which are similarly easy to deal with, and then strings -- and there goes the neighborhood, because it's not possible to determine which side of '"' is inside and which outside without parsing the whole program *and* assuming the prefix is well-formed. The world would be a better place if strings were delimited asymmetrically. With Unicode we can do that, and we could also make some usages (such as the convention for displaying literal symbols in documentation) prettier. Since Emacs Lisp is a language that observes, but does not promise to conform to, external standards, it *could* be a leader here. We (and our Lisp parsers) have already learned to deal with the restriction to ASCII and several instances of symmetric delimiters, so it's not a big improvement for us, but we would find it useful when grepping, for example. I suspect newbies would find it even more useful, increasing readability. > To encourage computer-computer usage in other > languages seems to be tolerant and open-minded but it > boils down to doing a disfavor. No, computer-computer usage uses *many* different languages, and we invent new ones every day (usually called "protocols" in this context). It's computer-human usage that demands a single language. Footnotes: [1] And in fact for long-lived programs the same arguments apply to docstrings and internal comments! (And to some extent, developer documentation in general, although it makes more sense to translate manuals than internal documentation.) [2] Haskell and SmallTalk already do this to a great extent, of course.