From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: MON KEY Newsgroups: gmane.emacs.devel Subject: Re: Return Date: Mon, 6 Dec 2010 00:50:36 -0500 Message-ID: References: <87mxojwu15.fsf@uwakimon.sk.tsukuba.ac.jp> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 X-Trace: dough.gmane.org 1291614651 915 80.91.229.12 (6 Dec 2010 05:50:51 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Mon, 6 Dec 2010 05:50:51 +0000 (UTC) Cc: emacs-devel@gnu.org To: "Stephen J. Turnbull" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Dec 06 06:50:47 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 1PPTyH-0003LY-Sy for ged-emacs-devel@m.gmane.org; Mon, 06 Dec 2010 06:50:46 +0100 Original-Received: from localhost ([127.0.0.1]:39840 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PPTyH-0000lh-AG for ged-emacs-devel@m.gmane.org; Mon, 06 Dec 2010 00:50:45 -0500 Original-Received: from [140.186.70.92] (port=47030 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PPTyC-0000lb-7X for emacs-devel@gnu.org; Mon, 06 Dec 2010 00:50:41 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PPTyA-0007ng-OC for emacs-devel@gnu.org; Mon, 06 Dec 2010 00:50:40 -0500 Original-Received: from mail-ww0-f49.google.com ([74.125.82.49]:63208) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PPTyA-0007nV-Cu for emacs-devel@gnu.org; Mon, 06 Dec 2010 00:50:38 -0500 Original-Received: by wwb17 with SMTP id 17so3780814wwb.30 for ; Sun, 05 Dec 2010 21:50:36 -0800 (PST) Original-Received: by 10.216.172.149 with SMTP id t21mr2192558wel.43.1291614636355; Sun, 05 Dec 2010 21:50:36 -0800 (PST) Original-Received: by 10.216.70.212 with HTTP; Sun, 5 Dec 2010 21:50:36 -0800 (PST) In-Reply-To: <87mxojwu15.fsf@uwakimon.sk.tsukuba.ac.jp> X-Google-Sender-Auth: -TFAqT7AwbDXtb9qbTJTciFT1Cc X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 2) 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:133444 Archived-At: On Sun, Dec 5, 2010 at 8:48 PM, Stephen J. Turnbull wrote: > > Pshaw... Doesn't GVR eschew ++Lambda++ in p3k? Heresy! ,---- | No, YAGNI. Even more so in Emacs Lisp: `---- Indeed, one often doesn't miss what one never knew wasn't there to be missed. GVM has no doubt leveraged this against future Python initiates. Fortunately a good many lispers are too accustomed w/ lambda by virtue of defmacro and Lisp's terse parenthetical syntax to not miss it. ,---- | (defmacro lambda (&rest forms) `(defun ,(gensym) ,@forms)) | | or something like that. ;-) `---- Perhaps, but quite a bit more happens at compile time around lambda and will do more so if/when the lexbind is merged. :) > ,---- > | 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. > `---- > > Sam Steingold has explored [...] ,---- | I'll take a look. But ... `---- FWIW I've found the old LispM sources to be the most enlightening. > Also, there are any number of legacy "Emacs like" editors ,---- | Indeed. For unacceptably small values of "like", though. | | AFAIK the people you would expect to actually be working on those things (eg, | you mention Bruno Haible as well as Sam Steingold) use "real" Emacs | instead for production work. I wonder why? ;-) `---- I've no idea why either of those individuals might do what they do. What would be interesting to learn is whether there is any will for a formal incorporation of the C in Clisp w/ the E in elisp? I imagine there are still a good many Common Lisp hacks that would contribute their valuable skills to such an effort were it not for the closed/proprietary control maintained on the FSF Emacs source tree. Regardless, the "real" Emacsen we are using today are not fundamentally so far removed from the legacy CLTL based systems they were once built upon that we can describe the contemporary Emacsen as somehow more "real" than its ancestor. Indeed, as you have framed it, mine was a comparison of Emacs to TECO. I would offer that the situation may be inverted, and that in many ways todays Emacsen are the TECOs to a certain breed of ancestral Emacsen. No doubt you're well aware of the lineage ;-) Indeed, when browsing through the LispM sources it is quite surprising to learn how much of the underlying Emacs VM (now C based) was once CLTL based. In some cases one can still catch glimpes of entire blocks of text which nearly superimpose one another (syntax differences aside)... > why on earth should a switch to either a Scheme/Python VM warrant > consideration. ,---- | I'm not suggesting switching to the Python VM, I'm proposing Python as | an example of a language with several implementations targeting | multiple VMs. `---- Great! I misunderstood. ,---- | The reason for using a Scheme is that it's much lighter | weight than a Common Lisp implementation. `---- This is an awfully general assertion. Which Scheme implementation? Which Scheme with which R[456]RS? And for any given implementation, which shared/linked libraries are required? Which CL implementation? ,---- | That may not butter your bread, but it matters to Richard, I believe, and to | the people who work on those implementations. `---- Butter aside, it isn't at all clear what the matter that matters is and to and for whom. > FWIW I find it quite odd that discussions of moving the Emacs VM to > Guile are bandied about ,---- | "Bandied about" is quite the odd term to use for a decision that AIUI | was made more than a decade ago. `---- Which decision, the decision to fork Emacs' CLTL code base from the LispM or the decision that Guile might eventually grow into its shoes enough to become a worthy consideration as the Emacs scripting engine? ,---- | Emacs just has a long gestation period for features. :-) `---- And enough hubris to squelch many such features which should never have been removed during the initial LispM fork 25+ yrs ago. -- /s_P\