Re: Differences between Elisp and Lisp

[Kent M Pitman]

bojohan+news@dd.chalmers.se (Johan Bockgård) writes:

> From gnu.emacs.help, followup-to set to gnu.emacs.help
> 
> "Daniel R. Anderson" <dan@mathjunkies.com> writes:
> 
> > On emacswiki.org there is a "wish list". Quite a few people want
> > emacs to be based on another version of LISP. Out of curiosity, what
> > is it that makes elisp inherently bad, or why would people want it
> > to be changed?

I hope the following information is taken as constructive.  (Why does
something in the back of my mind warn me to just decline to respond?
Usenet is so unpredictable.)  It is impossible to speak on this matter
without appearing to invite controversy, but that is not my intent.
The question you have asked is clearly a call for opinions and the
notes below are just my personal opinion.  Others should presumably
share their own opinions, and doubtless some will differ from mine,
but it would be better if such conflicting opinions were offered in
response to your original question than in response to my answer.

I don't know that I think that elisp is `inherently bad' so much as
`gratuitously different'.  That is, a lot of stuff between CL and Lisp
are culturally similar, but if you were to read a book on ANSI CL, you
would be told to do a lot of stuff that when you try it in elisp
doesn't work.

A number of Lisp dialects are what they are because they represent a
desire to show a new kind of power or a new technique.  From where I
sit, elisp was not this.  It was an attempt to hold onto a vestige of
the past, when Common Lisp was emerging and Stallman didn't like it.
I urged Stallman at that time to make elisp be compatible with Common 
Lisp in its core elements so that we could share a user community, but
my recollection is that he told me CL had abandoned the dynamic nature
(special variables) that were so important to the construction of a
scripting language.

I would (probably slightly oversimplifying, but for purposes of making
a point) characterize elisp as being a dialect that began less "about
something" and more "about not-something".  For this reason, I think
it is linguistically undistinguished.  Implementationally, certainly,
it has a proud history, but I don't think that history would have gone
much differently with a different dialect of Lisp.  The key
empowerment was the set of emacs-related data structures and the tight
integration with emacs.  It would be better for Lisp overall if there
were fewer dialects [some call them languages], since there would be
more cross-play of cultures and there could be more sharing of code,
education, etc.  (The big question then becomes which dialect to merge
with.  CL and Scheme present themselves as obvious choices.)

I also think, to some degree, that this is an issue of competition
among political parties.  (My 1995 paper
http://www.nhplace.com/kent/PS/Lambda.html is a bit dated in some
ways, but addresses the issue of languages as political parties and
will clarify (for those who care) what I mean by this, if it's not
clear just from context.)  That is, Stallman may have wanted to retain
a sense of control that perhaps he felt he would lose by going with
CL, which at that time was a moving target not controlled by him.
ANSI CL is stable for nearly a decade, and being compatible with it no
longer means being hostage to a committee, so I don't see that as the
political issue it might once have been.  And certainly nothing
requires one to take all of ANSI CL--one could just subset out the
parts that are useful to elisp if there was an issue about not wanting
the entire language.  Just having the core language align would be
very helpful to the Lisp community as a whole.

At this point, my understanding is that the Emacs community has come
to understand that lexicality is good and that elisp should have gone
with it.  I know there is some pressure to go with Scheme because it's
small and simple, but I think its 'style' is more different than CL's
is, and my sense is that changing to Scheme would be a bigger change.
That is, I think elisp is more of a Lisp than a Scheme (if you think
those two are different, which I do).  For example, elisp has multiple
namespaces and it would be a point of major incompatibility to move it
to a single namespace.  Moving to a single namespace [as Scheme does]
causes, I claim, the need for a complete overhaul of the macro system.
Scheme advocates sometimes assert that their so-called "hygienic macros"
are needed by all lisps, and sometimes speak with disdain about Common
Lisp for its lack of hygiene, but the truth is that the protective divisions
among modules are achieved differently in CL (through package separations
and namespace separations), and that allows a consequentially simpler
macro system for which I'll here coin the term "aequately hygienic".

I also think that in spite of the joy that the Scheme community takes over
its 'formal semantics', the fact is that the spec is quite ill-defined
on the issue of how to manage unwind-protect exactly because it interacts
very badly with call/cc.  Because emacs relies heavily on unwind-protect
and needs to have deterministic behavior in this area, I really don't
recommend getting into the call/cc issue unless you're SURE you have
resolved this issue and I really don't see how to resolve the issue without
confronting some pretty basic problems in the Scheme design that no one
seems to want to admit are even there. See my comp.lang.lisp article
 http://groups.google.com/groups?selm=sfwn1ic516r.fsf%40world.std.com

There is the sometimes issue of tail-call elimination which sometimes
separates the CL and Scheme community.  CL does not require it, but it
does permit it.  It would be CL-compliant to make elisp, as either an
implementation or subdialect, permit so-called "proper" tail-call
elimination (assuming that care was taken not to do this across things
that necessarily push stack, like special variable bindings.  (I would
like to see this part not become a subject of major debate since I
think it can be resolved in a way that is favorable to both
communities without huge amounts of wasted hot air.)

More subjectively, I feel Scheme has an implicit element to it, which
is that 'functional programming' is fundamentally empowering.  That
is, it's not just trying to empower the programmer but also trying to
push a particular message about how one ought to feel empowered and,
implicitly, how one ought not.  Common Lisp is much more agnostic
about paradigm, by explicit intent.  It tries to offer features that
are accomodate those with 'imperative', 'functional', and 'object
oriented' styles, leaving it to the programmer to figure out how to
structure programs.  In my experience, many members of the Scheme 
community have greeted the variation of options CL provides with disdain
because (apparently) it is not about a simple set of common principles.
But I, and many CL people, see this simply as an issue of 'tolerance'.
The elisp community is very large, and while there will _surely_ be
numerous (and probably vocal) Scheme advocates among them, I don't 
imagine that every one of them wants to be forced into the functional
programming mold.  Incidentally, I have the same issue with other single
paradigm languages--Smalltalk is, like Scheme, a very pretty design but
is not how I want to structure _my_ programs, and it doesn't leave room
for my way of thinking.

One option that would allow both paradigms might be to do like AutoCad
did and separate the notion of 'library' and 'datastructures' from the
issue of 'language'.  In that way, you might be able to design a system
where you could elect to program in any of several languages using the
same stack, data, error handling as glue between them.  In that world,
both Scheme and CL (or a CL subset) could survive, as well as perhaps
other languages, if someone were interested to provide such.  I don't
really so much want to keep people from programming in Scheme [if you
can address that unwind-protect issue, which I think is a real technical
concern] as to assure that people who are used to programming in a certain
Lisp style already aren't told they no longer can.  If there's a way to
frame this as "increasing one's options" instead of "one political party
triumphing over another", that would be superior in my view.

[Incidentally, thank you for NOT having cross-posted this to multiple
 communities.  I don't think very useful dialog happens that way.
 I routinely decline to involve myself in cross-posted discussions.
   http://www.nhplace.com/kent/PFAQ/cross-posting.html
]