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: return Date: Sat, 04 Dec 2010 15:18:15 +0900 Message-ID: <87bp52xdqw.fsf@uwakimon.sk.tsukuba.ac.jp> References: <201011261019.20727.tassilo@member.fsf.org> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: dough.gmane.org 1291444669 22642 80.91.229.12 (4 Dec 2010 06:37:49 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sat, 4 Dec 2010 06:37:49 +0000 (UTC) Cc: Tassilo Horn , Lars Magne Ingebrigtsen , emacs-devel@gnu.org To: Fren Zeee Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Dec 04 07:37:44 2010 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1POlkb-0001x6-6Q for ged-emacs-devel@m.gmane.org; Sat, 04 Dec 2010 07:37:43 +0100 Original-Received: from localhost ([127.0.0.1]:56011 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1POlka-0001Bs-6Z for ged-emacs-devel@m.gmane.org; Sat, 04 Dec 2010 01:37:40 -0500 Original-Received: from [140.186.70.92] (port=49270 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1POlkS-0001Bn-M2 for emacs-devel@gnu.org; Sat, 04 Dec 2010 01:37:33 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1POlkR-0007EJ-8W for emacs-devel@gnu.org; Sat, 04 Dec 2010 01:37:32 -0500 Original-Received: from [130.158.254.170] (port=54149 helo=dmail01.cc.tsukuba.ac.jp) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1POlkQ-0007Ce-MR for emacs-devel@gnu.org; Sat, 04 Dec 2010 01:37:31 -0500 Original-Received: from imss12.cc.tsukuba.ac.jp (unknown [130.158.254.130]) by dmail01.cc.tsukuba.ac.jp (Postfix) with ESMTP id BAA39E0267 for ; Sat, 4 Dec 2010 15:19:13 +0900 (JST) Original-Received: from imss12.cc.tsukuba.ac.jp (imss12.cc.tsukuba.ac.jp [127.0.0.1]) by postfix.imss71 (Postfix) with ESMTP id 573D62AF543; Sat, 4 Dec 2010 15:19:04 +0900 (JST) Original-Received: from mgmt1.sk.tsukuba.ac.jp (unknown [130.158.97.223]) by imss12.cc.tsukuba.ac.jp (Postfix) with ESMTP id 3DAA72AF542; Sat, 4 Dec 2010 15:19:04 +0900 (JST) Original-Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) by mgmt1.sk.tsukuba.ac.jp (Postfix) with ESMTP id 2E7453FA0557; Sat, 4 Dec 2010 15:19:04 +0900 (JST) Original-Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id 890DC11F034; Sat, 4 Dec 2010 15:18:15 +0900 (JST) In-Reply-To: X-Mailer: VM undefined under 21.5 (beta29) "garbanzo" ed3b274cc037 XEmacs Lucid (x86_64-unknown-linux) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:133394 Archived-At: Fren Zeee writes: > Why not just throw the whole elisp and use CL to run emacs with > lexical scoping ? A better question might be "why not build elisp on top of a more efficient extension language?" Mike Sperber did some experiments with Scheme48 several years ago that he claims indicate that a Scheme48 implementation of elisp is quite competitive with XEmacs Lisp (mostly written in C). Experiments done in about 2000 indicated that the XEmacs virtual machine was about 15% faster than Emacs's, and 10% faster than Python's. I suppose we *now* lag behind the state of the art somewhat, but for a Scheme implementation of Emacs Lisp to be competitive with XEmacs's C implementation at that time suggests that a well-performing implementation of elisp in another language suitable for use as an extension language for Emacs is quite feasible (a "SMOP", as they say). Note that Python (at least) has adopted this approach, with a core language definition that is 99% or so independent of implementation (cf. CPython, Cython nee pyrex, Stackless Python, Jython, IronPython, and PyPy). I doubt this will appeal to core Emacs hackers (I hear loud echoes of YAGNI from the future, especially since Miles's "lexbind" branch is scheduled for addition to Emacs 24 AIUI), but you might want to look into it, at least try a couple of implementations of Python on the same script a few times to see how little it could matter to users, and then talk to Mike about somehow reviving his project or at least getting advice (eg, if you prefer a different substrate language -- but I suspect Common Lisp would a lot more work to get decent performance than a Scheme). Speaking of Common Lisp, since it has a package scheme, you might be able to implement the elisp interpreter by using the elisp interpreter, and put in in a package that uses elisp eval instead of Common Lisp's eval. (Maybe I'm just smoking too much pakalolo. :-) > What particular advantages do there accrue from the dyn scoped elisp > and by incrementally making fixes to this dinosaur ? Read Richard's screed about Emacs and its dependence on dynamic scoping for why dynamic scoping is a feature in a language designed for implementing editors. (It's an MIT AI Lab working paper but it's publicly available online somewhere.) Of course like Common Lisp you could default to lexical scoping and require declaration of dynamically-scoped variables; Richard has said that on this list so there's no disagreement on that point. However, some form of dynamic scoping is needed, and needed frequently even in modern Emacs, according to him. OTOH, AIUI he doesn't think dynamic scoping causes problems all that often, lexical scoping is a bugaboo of minds that have taken too many language design courses. :-) The pragmatic advantage to reusing the code base based on the now- archaic Emacs Lisp is that Emacs hackers rarely ;-) write code designed to isolate use of dynamic scoping to where it's needed, so it would be a huge effort to (1) find all those dynamically-scoped variables, (2) identify the ones that can be lexical, (3) change them, and (4) debug the product. Like knowledge based on "obsolete" scientific paradigms, code developed using "obsolete" programming paradigms is too valuable in use to throw away. It gets gradually replaced over time, and only rarely "just because we can't bear to look at that any more!" The Emacs-Lisp-in-a-better-extension-language idea is attractive because it makes that evolution possible.