Here's a article i extended from my previous post.
Modernization of Emacs Lisp
Xah Lee, 2008-01
Over the past decade, before i really got my hands down with elisp in
the last couple of years, i have heard many times of wishes and
projects that want to replace elisp with Common Lisp or Scheme lisp.
At those times with my ignorance of deep elisp, i wished alone the
same line, blithely hoping that one day we'll have a emacs with a
better lisp (without me needing to put anything in). (this is the $B!H(Bi
want to believe$B!I(B syndrome typical with Free Software Foundation and
OpenSource youngsters) However, in the past 2 years i studied elisp,
and chance to actually spend maybe 30 minutes about this issue of
modernizing elisp and looked at some websites about such projects that
uses Scheme lisp or Common Lisp. I think now that these efforts are
largely impractical.
------------------------
Benefits With A New Lisp In Emacs
To create a emacs with Common Lisp or Scheme Lisp as extension
language, is not going to work as one might thought. Because, the
basis of such wish is that a programer would just learn one language
(and a better one at that) and not to have to learn one for X lisp and
one for Emacs lisp. This line of thinking is reasonable, but have
hidden, unexpected flaws. Because, to create such a extension language
in a editing environment, you necessarily have to need a lot concepts
and data types extraneous to the language. Namely, emacs's buffers,
point, frame, kill-ring...etc and so on. So, even if one day we have a
emacs with Scheme Lisp as the extension lang, but the deeper fact is
that it will actually have perhaps hundreds, of functions inherent in
the system that has nothing to do with Scheme the lang or general
programing. (and, there will be needs or complexities, to separate
what's editing-related function from the language's core functions)
So, the final effect is that, to write any program for text processing
or editor-extension for the New-Lisp Emac, the programer is really,
factually, spending most of time learning about the working of these
functions in this text-system environment, even if he is already a
Scheme expert. In short, given a Scheme Emacs (or Common Lisp emacs),
it will not make that much of a difference as with current Elisp
Emacs, with regards to effort of coding, when writing code for emacs.
There will be, a major practical impact however, if such system come
into being and widely used. And that is, the benefits of a unification
in general sense of that word (imagine Scheme and Common lisp are
unified; or GNU Emacs and Xemacs; South Korea and North Korea, etc.).
A more practical benefit is a pre-packaged, coherent, IDE for Common
lisp or Scheme lisp development. (imagine Visual Studio with C++ or
Visual Basic; Xcode and Objective-C; Java with Eclipse or NetBeans.)
------------------------
Technical Advantage
Note: the fact a somewhat technically better lisp (CL,Scheme)
replacing elisp, has very little practical benefits for a emacs
extension language, even when we consider just the technical aspects.
It is certainly true, that Common Lisp and Scheme Lisp are technically
better than Emacs Lisp, in different ways. For example, elisp uses
dynamic scope. Elisp has a datatype that is both character and
integer. Elisp does not support exact arithmetics. These defects are
not present in CL or Scheme. And, CL has many tried-and-true
libraries. Scheme provide the same language power with a simpler,
cleaner language. However, there are also considerable technical
disadvantage. For example, CL is fret with baggages and ugliness, with
its voluminous language specification. Scheme does not have a library
system (same situation as elisp) untill the R6RS specification in late
2007, and fully conformant implementation are scarce even for R5RS.
When considering most uses of the extension language in emacs, they
are predominantly text processing related tasks, with some other uses
such as embedding a text-based client for ftp, irc, mail, web browser,
OS command line interface, file manager. The benefits of fixing
elisp's weaknesses by CL or Scheme for small-scale programing as these
are not major, and is offset by the various technical disadvantages
they themselves bring.
------------------------
Effort Required
It is a fact that the effort needed to create such as system basically
hampered all such projects (although such system with CL and Scheme
already exists (and to my knowledge, usable to some extent).). And,
the need to advertise such a system to get people to switch from
existing system (emacs) is nigh impossible. The 2 facts that the
effort needed for such system and the effort needed to cover legacy
elisp so people will switch, basically puts a death knell to such
systems (or, long, long time down the road, maybe 5, 10 years, if
without commercial incentive. (and with such long expected duration,
in today's technological speeding, i do not think lisp lang itself (in
particular, CL, Scheme, or anything with the cons business), are
suitable or competitive as a high-level general lang of the 2010s)).
Note: This essay does not discourage the development of a new lisp
emacs, especially because they already exist. This essay is meant to
bring out some facts that must be considered. As noted before, a major
benefit of a emacs with Common Lisp or Scheme Lisp is that they
provide a unified, packaged, system for development of these
languages, and since it uses the same language to extend functionality
of the editor, it will transparently increase the number of developers
both the editor as well as the language. Here are the home pages of 2
of the most prominent on-going efforts:
* http://common-lisp.net/project/climacs/
* http://www-swiss.ai.mit.edu/projects/scheme/documentation/user_8.html
------------------------
this post is archived at
http://xahlee.org/emacs/modernization_of_elisp.html
As far as i know, climacs and edwin is the most prominent ones.
Though, i wasn't sure Edwin now has any users or is it still being
developed. Are there any other major efforts?
PS i'm trying to find a more relevant link for the edwin project. I
remember someone showed me once in irc, where the left side is a panel
showing items like buffers, kill-ring etc, and it can be clicked to
see the source code. Anyone knows the url?
Xah
···@xahlee.org
$B-t(B http://xahlee.org/
In article
<····································@l6g2000prm.googlegroups.com>,
Xah Lee <···@xahlee.org> wrote:
<...>
> Note: the fact a somewhat technically better lisp (CL,Scheme)
> replacing elisp, has very little practical benefits for a emacs
> extension language, even when we consider just the technical aspects.
Not that I necessarily disagree with your analysis. Here are some
additional points:
* CL packages can be an advantage. there would be less a chance
for name clashes. At the same time they can be a source
of confusion.
* Emacs Lisp is single threaded. Many other Lisp implementations
have multiple threads. Single-threading is annoying.
* Common Lisp has keyword arguments. The code simply
reads better.
* Common Lisp has objects/structures which would make some user
interface programming easier.
<...>
>
> ------------------------
> this post is archived at
> http://xahlee.org/emacs/modernization_of_elisp.html
>
> As far as i know, climacs and edwin is the most prominent ones.
> Though, i wasn't sure Edwin now has any users or is it still being
> developed. Are there any other major efforts?
The most prominent Emacs-like editor in Common Lisp is Hemlock.
Hemlock has been implemented at CMU and originally ran
(and still does) in CMUCL. The editor of LIspWorks is a derivative
of Hemlock. It runs on Mac OS X, Windows, Linux and Unix.
Some time ago a portable version of
Hemlock has been developed. Recently Clozure integrated
Hemlock into Clozure CL and gave it a Mac OS X user interface
(Cocoa).
Hemlock needs more hacking. The code is a bit old-style,
but very well written. Hemlock is otherwise (not yet) widely
used, but it is no toy editor. It has features like multiple windows,
commands, modes, preferences and so on.
Hemlock comes with a nice manual:
http://www.cons.org/cmucl/hemlock/index.html
Other Common Lisps with editor implementations are for example
MCL (Fred, Fred resembles emacs deliberately), Allegro CL
and I think Corman CL.
More about Emacs in Common Lisp:
http://www.cliki.net/CL-Emacs
There is a list of Emacs-like editors:
http://www.finseth.com/emacs.html
Also very interesting: The book
The Craft of Text Editing or Emacs for the Modern World
by
Craig A. Finseth
http://www.finseth.com/craft/
Explains the implementation of Emacs-like editors.