Re: return

["Stephen J. Turnbull" <stephen@xemacs.org>]

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 <sperber@xemacs.org> 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.