Multiple LISP's?

405 views
Skip to first unread message

Eyal Lotem

unread,
Sep 21, 2001, 4:34:42 PM9/21/01
to
I was always wondering why some software packages, that use LISP as a
base/extension language, either reimplement LISP (or use an existing
implementation), with some extended language functionality (in festival,
the function SayText), rather than have those packages (festival, or even
emacs?) as LISP libraries/code, that attach to the core LISP system
installed.
The main example that doesn't make sense to me is Festival.. it comes with
a LISP interpreter that has an additional function SayText, rather than
implementing a SayText function as a LISP library..
I also wondered why emacs needed its own variant of LISP, its own
interpreter with its own code, rather than writing it as a LISP program on
top of any other LISP interpreter/compiler..
Can anyone explain this weirdity?

Richard Krush

unread,
Sep 21, 2001, 7:13:19 PM9/21/01
to

Perhaps I am completely wrong, but it seems to me that programs such as
EMACS need a special Lisp. I don't know ELISP well enough to give actual
examples, but I would think that ELISP uses only a subset of CL, optimizes
the functions differently, and perhaps has some other extensions or
reductions. If they chose to use a subset of CL, they would still have to
somehow differentiate it from the actual CL.

Regards.

--
Richard Krushelnitskiy "I know not with what weapons World War III will
rich...@gmx.net be fought, but World War IV will be fought with
http://rkrush.cjb.net sticks and stones." -- Albert Einstein

cbbr...@acm.org

unread,
Sep 21, 2001, 11:29:42 PM9/21/01
to
Richard Krush <rich...@gmx.net> writes:
> Perhaps I am completely wrong, but it seems to me that programs such
> as EMACS need a special Lisp. I don't know ELISP well enough to give
> actual examples, but I would think that ELISP uses only a subset of
> CL, optimizes the functions differently, and perhaps has some other
> extensions or reductions. If they chose to use a subset of CL, they
> would still have to somehow differentiate it from the actual CL.

You HAVE to throw into this a whopping huge chunk of caveat to the
effect that:

"When ELISP was created, Common Lisp didn't exist yet, Scheme didn't
exist either, and so none of the modern Lisp dialects actually
_existed_ to give any guidance..."

Most pointedly, ELISP appears to predate the introduction of lexical
scoping, which was something that Scheme experimented with, and Common
Lisp subsequently adopted.

I see little reason why CL could not have been used instead of ELISP,
had it existed at the time.

If someone were to reimplement Emacs from scratch, it seems likely to
me that it would be a good candidate for _massive_ amounts of CLOS
definitions, and it would likely be very different under the covers
than it is.

But the fact is that ELISP was designed before the new college
students were _born_, and now, 20 years later, it's rather late to try
to turn it into either CL or Scheme, as there's vastly too much
existing code written in ELISP.
--
(reverse (concatenate 'string "ac.notelrac.teneerf@" "454aa"))
http://www.cbbrowne.com/info/nonrdbms.html
"...once can imagine the government's problem. This is all pretty
magical stuff to them. If I were trying to terminate the operations
of a witch coven, I'd probably seize everything in sight. How would I
tell the ordinary household brooms from the getaway vehicles?"
-- John Perry Barlow

Christopher Stacy

unread,
Sep 22, 2001, 4:55:50 AM9/22/01
to
>>>>> On Sat, 22 Sep 2001 03:29:42 GMT, cbbrowne ("cbbrowne") writes:

cbbrowne> Richard Krush <rich...@gmx.net> writes:
>> Perhaps I am completely wrong, but it seems to me that programs such
>> as EMACS need a special Lisp. I don't know ELISP well enough to give
>> actual examples, but I would think that ELISP uses only a subset of
>> CL, optimizes the functions differently, and perhaps has some other
>> extensions or reductions. If they chose to use a subset of CL, they
>> would still have to somehow differentiate it from the actual CL.

cbbrowne> You HAVE to throw into this a whopping huge chunk of caveat to the
cbbrowne> effect that:

cbbrowne> "When ELISP was created, Common Lisp didn't exist yet, Scheme didn't
cbbrowne> exist either, and so none of the modern Lisp dialects actually
cbbrowne> _existed_ to give any guidance..."

cbbrowne> Most pointedly, ELISP appears to predate the introduction of lexical
cbbrowne> scoping, which was something that Scheme experimented with, and Common
cbbrowne> Lisp subsequently adopted.

cbbrowne> I see little reason why CL could not have been used
cbbrowne> instead of ELISP, had it existed at the time.

Except that none of that is true!

GNU Emacs (and its Lisp extension language) were created around 1984.
Scheme was 1978, and Common Lisp (CLtL) was published in 1984 (based
on the existing implementations prior to that). And don't forget that
RMS was at the AI lab and was fully aware (and participated to some
degree) in of all the work for the preceeding 10 years leading up
to those languages.

RMS didn't think that lexical scoping was a good idea for Emacs,
because dynamic scoping makes it easier to rebind ("customize")
all the variables in the system.

The Emacs that was written for the Lisp Machine (years before GNU
Emacs was started), called ZWEI, was written in Lisp Machine Lisp
(sometimes called "ZetaLisp") which was one of the main precursors
to and a superset of Common Lisp. It's a somewhat different approach
internally than GNU Emacs (for example, buffer pointers rather than
cursor-oriented) and uses lexical scoping.

Tim Bradshaw

unread,
Sep 24, 2001, 5:22:09 AM9/24/01
to
Eyal Lotem <ey...@hyperroll.com> writes:


> The main example that doesn't make sense to me is Festival.. it comes with
> a LISP interpreter that has an additional function SayText, rather than
> implementing a SayText function as a LISP library..

Well, I think in the case of Festival, it's some huge mass of C++ code
and at some point they felt they needed an ability to script it, so
they used (I think) SIOD to do that, for which it's well suited. I
don't think there was an intention of implementing festival in Lisp
for whatever reason, and they almost certainly did not want to spend
ages sorting out foreign calls into n different Lisp implementations
so they just picked one.

--tim

James A. Crippen

unread,
Sep 25, 2001, 5:07:45 PM9/25/01
to
Christopher Stacy <cst...@spacy.Boston.MA.US> writes:

> >>>>> On Sat, 22 Sep 2001 03:29:42 GMT, cbbrowne ("cbbrowne") writes:

[...]


> cbbrowne> I see little reason why CL could not have been used
> cbbrowne> instead of ELISP, had it existed at the time.
>
> Except that none of that is true!
>
> GNU Emacs (and its Lisp extension language) were created around 1984.
> Scheme was 1978, and Common Lisp (CLtL) was published in 1984 (based
> on the existing implementations prior to that). And don't forget that
> RMS was at the AI lab and was fully aware (and participated to some
> degree) in of all the work for the preceeding 10 years leading up
> to those languages.
>
> RMS didn't think that lexical scoping was a good idea for Emacs,
> because dynamic scoping makes it easier to rebind ("customize")
> all the variables in the system.

The meme that Elisp predates CL has been spreading for a number of
years since CL was fully standardized and people began to wonder why
their Emacs wasn't compatible with their Lisp system.

RMS isn't exactly the _source_ of this meme, but suffice to say that
he hasn't said much to prevent its spread. It's now widely understood
that dynamic scoping, particularly in Elisp, is a *Bad Thing* because
of its surprising effects in certain situations. Since Emacs can Do
No Wrong, RMS isn't exactly willing to mention that he made a dumb
decision back in 1984.

One annoyance about the continued persistence of dynamic scoping in
Elisp is that it has encouraged others to implement dynamic scoping in
their own Lisps. The 'librepl' that is used in (I think) the Sawmill
X window manager is also dynamically scoped, and lots of code written
in it unfortunately relies on the peculiarities of dynamic scoping.

The XEmacs people have discussed reimplementing the Lisp engine in
XEmacs over and over. The major target languages are Scheme and CL.
Using Scheme would conveniently allow the use of Guile as the
implementation for XEmacs, but some people (myself included) think
that Guile needs some major cleanup before it gets used for something
as large as XEmacs (its use in SCWM is a good example of some of its
current deficiencies).

There are a number of other *NASTY* problems with Elisp, particularly
the way it interfaces with its garbage collector. This requires hairy
macro placement (using GCPRO()) to keep pointers from going missing in
the divide between C and Elisp.

Everyone pretty much agrees that the current guts of Elisp in XEmacs
suck, but nobody really wants to start down the road of rewriting the
whole thing *and then* porting the megs of software written in Elisp.
Compounded with that is that RMS will probably never allow GNU Emacs
to be rewritten to use a different Lisp, and hence the software that
is shared between the two most popular Emacsen (eg, Gnus, W3, PCL-CVS,
AUCTeX, etc) would no longer be portable between the two. Maintainers
would be forced to decide between one or the other Emacs, or to
maintain two distinct versions of their code.

XEmacs developers came up with the idea of an Elisp compatibility
package, but the details of this never arose, IIRC.

> The Emacs that was written for the Lisp Machine (years before GNU
> Emacs was started), called ZWEI, was written in Lisp Machine Lisp
> (sometimes called "ZetaLisp") which was one of the main precursors
> to and a superset of Common Lisp. It's a somewhat different approach
> internally than GNU Emacs (for example, buffer pointers rather than
> cursor-oriented) and uses lexical scoping.

ZWEI actually makes more sense in its internals than Emacs does. But
both of them still leave me running away. :-)

After that rant I should say that I still respect RMS for the huge
amount of work he's done, but he does get a bit annoying at times with
his recalcitrance... Can't be a figurehead without people disliking
you, anyway. :-P

'james

--
James A. Crippen <ja...@unlambda.com> ,-./-. Anchorage, Alaska,
Lambda Unlimited: Recursion 'R' Us | |/ | USA, 61.2069 N, 149.766 W,
Y = \f.(\x.f(xx)) (\x.f(xx)) | |\ | Earth, Sol System,
Y(F) = F(Y(F)) \_,-_/ Milky Way.

Thomas F. Burdick

unread,
Sep 25, 2001, 5:48:22 PM9/25/01
to
ja...@unlambda.com (James A. Crippen) writes:

> The meme that Elisp predates CL has been spreading for a number of
> years since CL was fully standardized and people began to wonder why
> their Emacs wasn't compatible with their Lisp system.
>
> RMS isn't exactly the _source_ of this meme, but suffice to say that
> he hasn't said much to prevent its spread.

He seems to have some serious beef against CL. I say "seems", because
I'm not sure that he's the source, but GNU Emacs doesn't allow the use
of the cl extension package in its distributed code. Which is crazy,
because there's some good stuff in there. Also, the whole choice of
Scheme as the official GNU extension language.

> It's now widely understood
> that dynamic scoping, particularly in Elisp, is a *Bad Thing* because

^^^^^^^^^^^^^^^^^^^^^


> of its surprising effects in certain situations.

I hardly think it's "widely understood" that dynamic scoping in Elisp
is a bad thing. Certainly some people think it is, but then there are
also a lot of proponents. My personal guess is that maintainers of
large packages are the least fond of it, and those trying to customize
others' large packages are the most fond of it. It definately has its
good and bad sides. IMO the only way to get rid of dynamic scoping
without making Elisp a lot less useful for its intended purpose
(customizing Emacs), would be to rewrite the whole thing to use CLOS
and be very disciplined about using OO style. I guess that given the
way advice is implemented, around advice could be used in a
lexically-scoped Emacs to emulate dynamic scoping.

> One annoyance about the continued persistence of dynamic scoping in
> Elisp is that it has encouraged others to implement dynamic scoping in
> their own Lisps. The 'librepl' that is used in (I think) the Sawmill
> X window manager is also dynamically scoped, and lots of code written
> in it unfortunately relies on the peculiarities of dynamic scoping.

I absolutely agree here. Emacs' status has given an impression of
credibility to its design decisions, outside of any context. I think
a lot of the way Elisp works is the right decision for Emacs now, not
because I couldn't think of a better way to do it, but because any
better way would involve rewriting Gnus, VM, AucTeX, etc, etc, making
the cure worse than the disease. Without understanding the context of
the goodness of these design decisions, though, people apparently will
just copy those decisions.

> There are a number of other *NASTY* problems with Elisp, particularly
> the way it interfaces with its garbage collector. This requires hairy
> macro placement (using GCPRO()) to keep pointers from going missing in
> the divide between C and Elisp.

I admit it's nit-picking a bit to differentiate between the language
and its implementation when the language isn't standardized and it
only has two nearly-identical implementations, but this is definitely
an implementation issue, and not one with the language. This is only
visible from within the implementation, and could be fixed without
breaking any existing lisp code. So it's a problem with the Elisp
interpreter, not with Elisp itself. If I'm not mistaken, GNU Emacs is
planning on replacing the current GC with a portable conservative GC
(maybe Boehm's), eventually making the whole, aweful GCPRO mess a
non-issue.

> Everyone pretty much agrees that the current guts of Elisp in XEmacs
> suck, but nobody really wants to start down the road of rewriting the
> whole thing *and then* porting the megs of software written in Elisp.
> Compounded with that is that RMS will probably never allow GNU Emacs
> to be rewritten to use a different Lisp, and hence the software that
> is shared between the two most popular Emacsen (eg, Gnus, W3, PCL-CVS,
> AUCTeX, etc) would no longer be portable between the two. Maintainers
> would be forced to decide between one or the other Emacs, or to
> maintain two distinct versions of their code.

See above about the cure being worse than the disease :). I think at
some point, crufty old Elisp will go away. I don't think it will
happen because of the will of the XEmacs maintainers, though. It's
gonna require a consensus on the part of the maintainers of the major
packages that things have gotten to the point where they'd rather
rewrite their packages than continue on in Elisp. Otherwise, no one
would use the New Improved Got-No-AUCTeX-No-W3-No-ILISP-No-Gnus Emacs.

James A. Crippen

unread,
Sep 25, 2001, 7:33:12 PM9/25/01
to
t...@hurricane.OCF.Berkeley.EDU (Thomas F. Burdick) writes:

> ja...@unlambda.com (James A. Crippen) writes:
>
> > The meme that Elisp predates CL has been spreading for a number of
> > years since CL was fully standardized and people began to wonder why
> > their Emacs wasn't compatible with their Lisp system.
> >
> > RMS isn't exactly the _source_ of this meme, but suffice to say that
> > he hasn't said much to prevent its spread.
>
> He seems to have some serious beef against CL. I say "seems", because
> I'm not sure that he's the source, but GNU Emacs doesn't allow the use
> of the cl extension package in its distributed code. Which is crazy,
> because there's some good stuff in there. Also, the whole choice of
> Scheme as the official GNU extension language.

It's probably because lots of people he no longer likes were involved
with the CL standardization effort. RMS is kinda snippety about
holding on to grudges. He's *still* got it in for Symbolics, even
though they're twice dead and resurrected already, 20 years later.

I think he just has some psychological problems that need some good
therapy. But that won't happen, because if we lost the free-software
loudmouth who would we replace him with? :-)

> I hardly think it's "widely understood" that dynamic scoping in Elisp
> is a bad thing. Certainly some people think it is, but then there are
> also a lot of proponents. My personal guess is that maintainers of
> large packages are the least fond of it, and those trying to customize
> others' large packages are the most fond of it. It definately has its
> good and bad sides. IMO the only way to get rid of dynamic scoping
> without making Elisp a lot less useful for its intended purpose
> (customizing Emacs), would be to rewrite the whole thing to use CLOS
> and be very disciplined about using OO style. I guess that given the
> way advice is implemented, around advice could be used in a
> lexically-scoped Emacs to emulate dynamic scoping.

CL has specials. Also, much of the effects of customizability could
be better done using something more rigorous than random variables
that the user setqs. The whole idea of using huge piles of variables
for customization is a bad idea because they proliferate all too
easily, particularly without a coherent namespace management system,
like CL's packages.

I'd prefer to see feature alists or something. One alist per mode, or
the like. Whatever. There are lots of better ways to do it than the
way it's done in Emacs right now.

> > in it unfortunately relies on the peculiarities of dynamic scoping.
>
> I absolutely agree here. Emacs' status has given an impression of
> credibility to its design decisions, outside of any context. I think
> a lot of the way Elisp works is the right decision for Emacs now, not
> because I couldn't think of a better way to do it, but because any
> better way would involve rewriting Gnus, VM, AucTeX, etc, etc, making
> the cure worse than the disease. Without understanding the context of
> the goodness of these design decisions, though, people apparently will
> just copy those decisions.

And unfortunately, copying those decisions in the form of *completely
new*, *nonstandard* Lisps just makes the proliferation and
compatibility problems worse.

It's so easy for someone to write a new Lisp that they never bother to
read up on implementation details, and perpetuate some of the more
ugly kluges and hacks without knowing that they're ugly.

> I admit it's nit-picking a bit to differentiate between the language
> and its implementation when the language isn't standardized and it
> only has two nearly-identical implementations, but this is definitely
> an implementation issue, and not one with the language. This is only
> visible from within the implementation, and could be fixed without
> breaking any existing lisp code. So it's a problem with the Elisp
> interpreter, not with Elisp itself. If I'm not mistaken, GNU Emacs is
> planning on replacing the current GC with a portable conservative GC
> (maybe Boehm's), eventually making the whole, aweful GCPRO mess a
> non-issue.

That's the hope. But it's been the hope to get rid of the GCPRO mess
for a number of years now. But it's really entrenched and poorly
understood.

> > Everyone pretty much agrees that the current guts of Elisp in XEmacs
> > suck, but nobody really wants to start down the road of rewriting the
> > whole thing *and then* porting the megs of software written in Elisp.
> > Compounded with that is that RMS will probably never allow GNU Emacs
> > to be rewritten to use a different Lisp, and hence the software that
> > is shared between the two most popular Emacsen (eg, Gnus, W3, PCL-CVS,
> > AUCTeX, etc) would no longer be portable between the two. Maintainers
> > would be forced to decide between one or the other Emacs, or to
> > maintain two distinct versions of their code.
>
> See above about the cure being worse than the disease :). I think at
> some point, crufty old Elisp will go away. I don't think it will
> happen because of the will of the XEmacs maintainers, though. It's
> gonna require a consensus on the part of the maintainers of the major
> packages that things have gotten to the point where they'd rather
> rewrite their packages than continue on in Elisp. Otherwise, no one
> would use the New Improved Got-No-AUCTeX-No-W3-No-ILISP-No-Gnus Emacs.

It'll never get to this point because, well, it's Lisp, innit? It's a
lot better than C, right? So we'll just live with its problems!

Which is okay, but annoying.

The real solution is to borrow the work done on automatic translation
of Elisp to Scheme that the Edwin people did for MIT Scheme. Snarf
that stuff and figure out how far you'd have to go to get it to do CL.
Then snatch a CL implementation (or roll your own partial-CL) and port
the front end of Emacs to it. A lot of work, which is why nobody's
doing it.

This debate goes on forever, BTW. I'm just saying the same things
people have said before. And yes, I'm too lazy to do the work
myself. If I wasn't as lazy, I'd be a C programmer, not a Lisp
hacker. But if I was any more lazy I'd be using Lazy ML. :-D

Thomas F. Burdick

unread,
Sep 25, 2001, 8:02:03 PM9/25/01
to
ja...@unlambda.com (James A. Crippen) writes:

> t...@hurricane.OCF.Berkeley.EDU (Thomas F. Burdick) writes:
>
> > I hardly think it's "widely understood" that dynamic scoping in Elisp
> > is a bad thing. Certainly some people think it is, but then there are
> > also a lot of proponents. My personal guess is that maintainers of
> > large packages are the least fond of it, and those trying to customize
> > others' large packages are the most fond of it. It definately has its
> > good and bad sides. IMO the only way to get rid of dynamic scoping
> > without making Elisp a lot less useful for its intended purpose
> > (customizing Emacs), would be to rewrite the whole thing to use CLOS
> > and be very disciplined about using OO style. I guess that given the
> > way advice is implemented, around advice could be used in a
> > lexically-scoped Emacs to emulate dynamic scoping.
>
> CL has specials. Also, much of the effects of customizability could
> be better done using something more rigorous than random variables
> that the user setqs. The whole idea of using huge piles of variables
> for customization is a bad idea because they proliferate all too
> easily, particularly without a coherent namespace management system,
> like CL's packages.
>
> I'd prefer to see feature alists or something. One alist per mode, or
> the like. Whatever. There are lots of better ways to do it than the
> way it's done in Emacs right now.

I agree with all of the above, but it's all orthogonal to
lexical/dynamic scoping (except for the mention of specials,
obviously).

> And unfortunately, copying those decisions in the form of *completely
> new*, *nonstandard* Lisps just makes the proliferation and
> compatibility problems worse.
>
> It's so easy for someone to write a new Lisp that they never bother to
> read up on implementation details, and perpetuate some of the more
> ugly kluges and hacks without knowing that they're ugly.

Yep, apparently it's easier than reading the CLISP or ECLS
documentation :-/

> > See above about the cure being worse than the disease :). I think at
> > some point, crufty old Elisp will go away. I don't think it will
> > happen because of the will of the XEmacs maintainers, though. It's
> > gonna require a consensus on the part of the maintainers of the major
> > packages that things have gotten to the point where they'd rather
> > rewrite their packages than continue on in Elisp. Otherwise, no one
> > would use the New Improved Got-No-AUCTeX-No-W3-No-ILISP-No-Gnus Emacs.
>
> It'll never get to this point because, well, it's Lisp, innit? It's a
> lot better than C, right? So we'll just live with its problems!

Actually, you're probably right. I'd rather write a
`with-lexical-scoping' macro that would make all the binding
primitives fake lexical scoping unless I (declare (special ...))'ed
'em. I guess that makes me part of the problem :)

> The real solution is to borrow the work done on automatic translation
> of Elisp to Scheme that the Edwin people did for MIT Scheme. Snarf
> that stuff and figure out how far you'd have to go to get it to do CL.
> Then snatch a CL implementation (or roll your own partial-CL) and port
> the front end of Emacs to it. A lot of work, which is why nobody's
> doing it.

The problem is that this would force the new Emacs to make a lot of
the same misdecisions as the old Elisp-based one. If I had 50-hour
days, I'd think it would be interesting to design a new Emacs from the
ground up, but if I had to maintain compatibility with Elisp-based
Emacs, even with 50-hour days I wouldn't want to.

> This debate goes on forever, BTW.

Oh, yeah, but it seemed interesting, and this is usenet, after all,
with noexpectation of actually accomplishing anything :)

cbbr...@acm.org

unread,
Sep 25, 2001, 8:54:18 PM9/25/01
to
ja...@unlambda.com (James A. Crippen) writes:
> Christopher Stacy <cst...@spacy.Boston.MA.US> writes:
>
> > >>>>> On Sat, 22 Sep 2001 03:29:42 GMT, cbbrowne ("cbbrowne") writes:
> [...]
>> cbbrowne> I see little reason why CL could not have been used
>> cbbrowne> instead of ELISP, had it existed at the time.
>>
>> Except that none of that is true!
>>
>> GNU Emacs (and its Lisp extension language) were created around 1984.
>> Scheme was 1978, and Common Lisp (CLtL) was published in 1984 (based
>> on the existing implementations prior to that). And don't forget that
>> RMS was at the AI lab and was fully aware (and participated to some
>> degree) in of all the work for the preceeding 10 years leading up
>> to those languages.
>>
>> RMS didn't think that lexical scoping was a good idea for Emacs,
>> because dynamic scoping makes it easier to rebind ("customize")
>> all the variables in the system.

> The meme that Elisp predates CL has been spreading for a number of
> years since CL was fully standardized and people began to wonder why
> their Emacs wasn't compatible with their Lisp system.

I guess I have to confess mistake on this one. It still seems not
outrageous to consider that there was considerable "flux" going on at
the time, and that it's not obvious that dynamic scoping was
necessarily a backwards and dumb choice at the time.

> RMS isn't exactly the _source_ of this meme, but suffice to say that
> he hasn't said much to prevent its spread. It's now widely
> understood that dynamic scoping, particularly in Elisp, is a *Bad
> Thing* because of its surprising effects in certain situations.
> Since Emacs can Do No Wrong, RMS isn't exactly willing to mention
> that he made a dumb decision back in 1984.

Mind you, what we'd do today, using CL (with CLOS!), is quite
different from what would have been likely back in 1984. So while I
may have been emitting the "usual, mistaken meme," it would be equally
wrong to look at the CLHS as the description of what "ought" to have
been used...

> One annoyance about the continued persistence of dynamic scoping in
> Elisp is that it has encouraged others to implement dynamic scoping
> in their own Lisps. The 'librepl' that is used in (I think) the
> Sawmill X window manager is also dynamically scoped, and lots of
> code written in it unfortunately relies on the peculiarities of
> dynamic scoping.

> The XEmacs people have discussed reimplementing the Lisp engine in
> XEmacs over and over. The major target languages are Scheme and CL.
> Using Scheme would conveniently allow the use of Guile as the
> implementation for XEmacs, but some people (myself included) think
> that Guile needs some major cleanup before it gets used for
> something as large as XEmacs (its use in SCWM is a good example of
> some of its current deficiencies).

Could you elaborate on the SCWM comment?

> There are a number of other *NASTY* problems with Elisp,
> particularly the way it interfaces with its garbage collector. This
> requires hairy macro placement (using GCPRO()) to keep pointers from
> going missing in the divide between C and Elisp.

It's entirely possible that any other implementation would have been
just about as bad...

> Everyone pretty much agrees that the current guts of Elisp in XEmacs
> suck, but nobody really wants to start down the road of rewriting
> the whole thing *and then* porting the megs of software written in
> Elisp. Compounded with that is that RMS will probably never allow
> GNU Emacs to be rewritten to use a different Lisp, and hence the
> software that is shared between the two most popular Emacsen (eg,
> Gnus, W3, PCL-CVS, AUCTeX, etc) would no longer be portable between
> the two. Maintainers would be forced to decide between one or the
> other Emacs, or to maintain two distinct versions of their code.

> XEmacs developers came up with the idea of an Elisp compatibility
> package, but the details of this never arose, IIRC.

Making it cover the simultaneous needs of:
- compatibility
- speed
- cleanliness in the 'new syntax'
makes it hard even in concept to fill in details.

The Guile folk had a different but similarly ambitious vision to make
it simultaneously support several syntaxes, notably a C-like one
called "C-Tax," and then fell afoul of the intent to try to support
Perl syntax. The notion of supporting _that_ seemed to daunt any
consideration of trying to implement _any_ of this stuff...

> > The Emacs that was written for the Lisp Machine (years before GNU
> > Emacs was started), called ZWEI, was written in Lisp Machine Lisp
> > (sometimes called "ZetaLisp") which was one of the main precursors
> > to and a superset of Common Lisp. It's a somewhat different approach
> > internally than GNU Emacs (for example, buffer pointers rather than
> > cursor-oriented) and uses lexical scoping.
>
> ZWEI actually makes more sense in its internals than Emacs does. But
> both of them still leave me running away. :-)

> After that rant I should say that I still respect RMS for the huge
> amount of work he's done, but he does get a bit annoying at times
> with his recalcitrance... Can't be a figurehead without people
> disliking you, anyway. :-P

Well, if he wasn't so "recalcitrant," he'd probably not have stayed
unswervingly behind the GPL for such a long time. Sometimes that's
for the worse, sometimes for the better.

The utter lack of compromise on so many issues certainly shows him off
as "not the most diplomatic person in the world;" that's bad if the
goal is to make treaties, but it's kind of useful to have someone so
steadfast around irrespective of whether or not you agree with them...

--
(concatenate 'string "aa454" "@freenet.carleton.ca")
http://www.cbbrowne.com/info/sap.html
"People are more vocally opposed to fur than leather because it's
easier to harass rich women than motorcycle gangs." [bumper sticker]

Rahul Jain

unread,
Sep 25, 2001, 8:57:48 PM9/25/01
to
ja...@unlambda.com (James A. Crippen) writes:

> Christopher Stacy <cst...@spacy.Boston.MA.US> writes:
> One annoyance about the continued persistence of dynamic scoping in
> Elisp is that it has encouraged others to implement dynamic scoping in
> their own Lisps. The 'librepl' that is used in (I think) the Sawmill
> X window manager is also dynamically scoped, and lots of code written
> in it unfortunately relies on the peculiarities of dynamic scoping.

This is incorrect. rep (librep is the name of the library that is
linked to for applications that would like to use rep) is lexically
scoped. I don't know if it even supports dynamic scope at all. It's
sort of halfway between elisp and scheme for the most part, which
makes me terribly confused most of the time when I'm trying to use
it. :)

Oh and Sawmill is a web log analyzer. The window manager's name had to
be changed to Sawfish due to a trademark conflict.

--
-> -/- - Rahul Jain - -\- <-
-> -\- http://linux.rice.edu/~rahul -=- mailto:rahul...@usa.net -/- <-
-> -/- "I never could get the hang of Thursdays." - HHGTTG by DNA -\- <-
|--|--------|--------------|----|-------------|------|---------|-----|-|
Version 11.423.999.220020101.23.50110101.042
(c)1996-2000, All rights reserved. Disclaimer available upon request.

cbbr...@acm.org

unread,
Sep 25, 2001, 9:02:25 PM9/25/01
to
t...@hurricane.OCF.Berkeley.EDU (Thomas F. Burdick) writes:
> He seems to have some serious beef against CL. I say "seems",
> because I'm not sure that he's the source, but GNU Emacs doesn't
> allow the use of the cl extension package in its distributed code.
> Which is crazy, because there's some good stuff in there. Also, the
> whole choice of Scheme as the official GNU extension language.

I think there must have been something very political that happened
some time in the mists of the past. GCL was out there, and largely
ignored by all _sorts_ of folk for the longest time.

And it seems to me that there _should_ have been some really vastly
serious push to have some form of "Schemely" code generator associated
with GCC in order to encourage wider use of Scheme, and not merely for
"scripting."

> > It's now widely understood
> > that dynamic scoping, particularly in Elisp, is a *Bad Thing* because
> ^^^^^^^^^^^^^^^^^^^^^
> > of its surprising effects in certain situations.

> I hardly think it's "widely understood" that dynamic scoping in
> Elisp is a bad thing. Certainly some people think it is, but then
> there are also a lot of proponents. My personal guess is that
> maintainers of large packages are the least fond of it, and those
> trying to customize others' large packages are the most fond of it.
> It definately has its good and bad sides.

That seems logical.

<http://www.gnu.org/software/emacs/emacs-paper.html#SEC18> describes
this in albeit limited detail.

> IMO the only way to get rid of dynamic scoping without making Elisp
> a lot less useful for its intended purpose (customizing Emacs),
> would be to rewrite the whole thing to use CLOS and be very
> disciplined about using OO style. I guess that given the way advice
> is implemented, around advice could be used in a lexically-scoped
> Emacs to emulate dynamic scoping.

Attaching extra information to objects would be doable... _With Modern
CLOS_, and the various metaobject protocol stuff that isn't quite
formally standardized.

As you say, the need would be to "rewrite the whole thing to use
CLOS;" if we step back a little closer to 1984, CLOS+MOP weren't
nearly as standardized as they are now, and weren't realistically an
option.

>> One annoyance about the continued persistence of dynamic scoping in
>> Elisp is that it has encouraged others to implement dynamic scoping
>> in their own Lisps. The 'librepl' that is used in (I think) the
>> Sawmill X window manager is also dynamically scoped, and lots of
>> code written in it unfortunately relies on the peculiarities of
>> dynamic scoping.

> I absolutely agree here. Emacs' status has given an impression of
> credibility to its design decisions, outside of any context. I
> think a lot of the way Elisp works is the right decision for Emacs
> now, not because I couldn't think of a better way to do it, but
> because any better way would involve rewriting Gnus, VM, AucTeX,
> etc, etc, making the cure worse than the disease. Without
> understanding the context of the goodness of these design decisions,
> though, people apparently will just copy those decisions.

.. And if the point is to build something that's long-term
extensible, there _are_ properties of dynamic scope that have some
value, so that the "cure" might, along with being worse than the
disease, make some extensions harder to do later.

>> There are a number of other *NASTY* problems with Elisp,
>> particularly the way it interfaces with its garbage collector.
>> This requires hairy macro placement (using GCPRO()) to keep
>> pointers from going missing in the divide between C and Elisp.

> I admit it's nit-picking a bit to differentiate between the language
> and its implementation when the language isn't standardized and it
> only has two nearly-identical implementations, but this is
> definitely an implementation issue, and not one with the language.
> This is only visible from within the implementation, and could be
> fixed without breaking any existing lisp code. So it's a problem
> with the Elisp interpreter, not with Elisp itself. If I'm not
> mistaken, GNU Emacs is planning on replacing the current GC with a
> portable conservative GC (maybe Boehm's), eventually making the
> whole, aweful GCPRO mess a non-issue.

You should see Tom Lord's discussion of conservative GC; _greatly_
scathing... He was one of the guys that used to work on Guile, and is
more recently responsible for Systas Scheme.

>> Everyone pretty much agrees that the current guts of Elisp in
>> XEmacs suck, but nobody really wants to start down the road of
>> rewriting the whole thing *and then* porting the megs of software
>> written in Elisp. Compounded with that is that RMS will probably
>> never allow GNU Emacs to be rewritten to use a different Lisp, and
>> hence the software that is shared between the two most popular
>> Emacsen (eg, Gnus, W3, PCL-CVS, AUCTeX, etc) would no longer be
>> portable between the two. Maintainers would be forced to decide
>> between one or the other Emacs, or to maintain two distinct
>> versions of their code.

> See above about the cure being worse than the disease :). I think
> at some point, crufty old Elisp will go away. I don't think it will
> happen because of the will of the XEmacs maintainers, though. It's
> gonna require a consensus on the part of the maintainers of the
> major packages that things have gotten to the point where they'd
> rather rewrite their packages than continue on in Elisp. Otherwise,
> no one would use the New Improved
> Got-No-AUCTeX-No-W3-No-ILISP-No-Gnus Emacs.

I'm not sure when that point in time will be...
--
(concatenate 'string "cbbrowne" "@cbbrowne.com")
http://www.cbbrowne.com/info/emacs.html
``God decided to take the devil to court and settle their differences
once and for all. When Satan heard of this, he grinned and said, "And
just where do you think you're going to find a lawyer?"''

Dave Pearson

unread,
Sep 25, 2001, 9:20:55 PM9/25/01
to
* James A. Crippen <ja...@unlambda.com>:

> One annoyance about the continued persistence of dynamic scoping in Elisp
> is that it has encouraged others to implement dynamic scoping in their own
> Lisps. The 'librepl' that is used in (I think) the Sawmill X window
> manager is also dynamically scoped, and lots of code written in it
> unfortunately relies on the peculiarities of dynamic scoping.

That changed a long time ago (a year or more?). From librep's news:

,----
| 0.8
| ===
|
| * Default scoping is now lexical, only variables declared using
| `defvar' are dynamically scoped.
`----

sawmill is known as sawfish these days.

--
Dave Pearson: | lbdb.el - LBDB interface.
http://www.davep.org/ | sawfish.el - Sawfish mode.
Emacs: | uptimes.el - Record emacs uptimes.
http://www.davep.org/emacs/ | quickurl.el - Recall lists of URLs.

Graham Hughes

unread,
Sep 25, 2001, 9:23:12 PM9/25/01
to
>>>>> "Thomas" == Thomas F Burdick <t...@hurricane.OCF.Berkeley.EDU> writes:

Thomas> He seems to have some serious beef against CL. I say
Thomas> "seems", because I'm not sure that he's the source, but
Thomas> GNU Emacs doesn't allow the use of the cl extension
Thomas> package in its distributed code. Which is crazy, because
Thomas> there's some good stuff in there. Also, the whole choice
Thomas> of Scheme as the official GNU extension language.

cd /usr/share/emacs/21.0.104/lisp/
grep -n "(require 'cl)" *.el /dev/null
winner.el:44: (require 'cl))
wid-browse.el:36:(eval-when-compile (require 'cl))
vc.el:363: (require 'cl)
vc-rcs.el:36: (require 'cl)
vc-hooks.el:37: (require 'cl))
uniquify.el:90:(eval-when-compile (require 'cl))
tooltip.el:37: (require 'cl)
sun-curs.el:34:(eval-when-compile (require 'cl))
strokes.el:192:(eval-when-compile (require 'cl))
smerge-mode.el:49:(eval-when-compile (require 'cl))
simple.el:33: (require 'cl))
pcvs.el:125:(eval-when-compile (require 'cl))
pcvs-util.el:32:(eval-when-compile (require 'cl))
pcvs-parse.el:37:(eval-when-compile (require 'cl))
pcvs-info.el:36:(eval-when-compile (require 'cl))
pcvs-defs.el:31:(eval-when-compile (require 'cl))
msb.el:83:(eval-when-compile (require 'cl))
mouse-sel.el:144: (require 'cl))
midnight.el:42: (require 'cl))
log-view.el:36:(eval-when-compile (require 'cl))
log-edit.el:35:(eval-when-compile (require 'cl))
lazy-lock.el:275: (require 'cl)
iswitchb.el:212: (require 'cl))
imenu.el:64:(eval-when-compile (require 'cl))
generic.el:121: (require 'cl))
font-lock.el:673: (require 'cl)
fast-lock.el:192: (require 'cl)
faces.el:28: (require 'cl)
edmacro.el:74: (require 'cl))
diff-mode.el:63:(eval-when-compile (require 'cl))
cvs-status.el:34:(eval-when-compile (require 'cl))
cus-dep.el:27:(eval-when-compile (require 'cl))
autorevert.el:73:(eval-when-compile (require 'cl))

That is perhaps overstated. It is true, I believe, that any packages
that are automatically loaded into Emacs and then dumped with the
Emacs image (cc-mode comes to mind) cannot use the CL library, and I
don't know why that is, but certainly (require 'cl) is not actively
discouraged.
--
Graham Hughes <gra...@sigwinch.org>
(defun whee (n e) (subseq (let ((c (cons e e))) (nconc c c)) 0 n))

Christopher Stacy

unread,
Sep 26, 2001, 12:06:48 AM9/26/01
to
>>>>> On 25 Sep 2001 13:07:45 -0800, James A Crippen ("James") writes:
James> Compounded with that is that RMS will probably never allow GNU Emacs
James> to be rewritten to use a different Lisp

Huh? Anybody is "free" to do so! However, RMS might or might not
want to help with such a port/rewrite: you'd have to ask him.

Let us not start YAGFL (Yet Another GPL Flame War) here, though.
That's what gnu.misc.discuss is for!

James> XEmacs developers came up with the idea of an Elisp compatibility
James> package, but the details of this never arose, IIRC.

Someone did a paper (maybe it was an undergraduate thesis) at MIT
which included a Scheme compatability library for GNU Elisp.
I think they then ported GNUS or something big, to demonstrate that it could
be done. If someone wants to do something similar (in either CL or Scheme)
they should take a look at that...........aha..here it is:

AITR-1451
Emacs Lisp in Edwin SScheme
Author[s]: Matthew Birkholz
Date: September 1993

Abstract: sThe MIT-Scheme program development environment includes a
general-purpose text editor, Edwin, that has an extension language,
Edwin Scheme. Edwin is very similar to another general-purpose text
editor, GNU Emacs, which also has an extension language, Emacs Lisp.
The popularity of GNU Emacs has lead to a large library of tools
written in Emacs Lisp. The goal of this thesis is to implement
a useful subset of Emacs Lisp in Edwin Scheme. This subset was chosen
to be sufficient for simple operation of the GNUS news reading program.

PS Download: ftp://publications.ai.mit.edu/ai-publications/1000-1499/AITR-1451.ps.Z
PDF Download: ftp://publications.ai.mit.edu/ai-publications/pdf/AITR-1451.pdf

I'd be more interested in a CL version. One issue is: what compiler/interpreter
and development tools would be distributed with the editor so that people could
load extension libraries, and write their own extensions.

Christopher Stacy

unread,
Sep 26, 2001, 12:10:20 AM9/26/01
to
>>>>> On Wed, 26 Sep 2001 00:54:18 GMT, cbbrowne ("cbbrowne") writes:
cbbrowne> Mind you, what we'd do today, using CL (with CLOS!), is quite
cbbrowne> different from what would have been likely back in 1984.

Huh?

cbbr...@acm.org

unread,
Sep 26, 2001, 12:36:12 AM9/26/01
to

Looking at the references in my online copy of CLTL2, the CLOS
references are all dated 1989.

Keene's book indicates that in '86, when CL object models started
coalesceing into _something_, that there was a diverse set of
different object models.

The point? In 2001 (and, for that matter, 1991 :-() we can point to
CLOS as an appropriate object model to mandate. In 1984, it certainly
wasn't an option.

Similarly (though probably less crucial!), the LOOP facility in CL in
1984 differed considerably from the much-extended design voted on in
1989.

Differing object models, differing loop models, all would lead to an
Emacs design based on "CL as of 1984" being a quite different animal
from one based on "CL as of 1989." (Regardless of whether SERIES is
considered at _all_ standardized :-).)

--
(reverse (concatenate 'string "ac.notelrac.teneerf@" "454aa"))

http://www.ntlug.org/~cbbrowne/nonrdbms.html
There is a theory that states: "If anyone finds out what the universe
is for, it will disappear and be replaced by something more bizarrely
inexplicable." There is another theory that states: "This has already
happened..." -Douglas Adams, "Hitch-Hikers Guide to the Galaxy"

James A. Crippen

unread,
Sep 26, 2001, 1:37:01 AM9/26/01
to

Ah, yes, thank you for the reality check. :-)

Do I endorse it on the back?

James A. Crippen

unread,
Sep 26, 2001, 2:32:59 AM9/26/01
to
cbbr...@acm.org writes:

> Christopher Stacy <cst...@spacy.Boston.MA.US> writes:
> > >>>>> On Wed, 26 Sep 2001 00:54:18 GMT, cbbrowne ("cbbrowne") writes:
> > cbbrowne> Mind you, what we'd do today, using CL (with CLOS!), is quite
> > cbbrowne> different from what would have been likely back in 1984.
> >
> > Huh?
>
> Looking at the references in my online copy of CLTL2, the CLOS
> references are all dated 1989.

The first edition of CLTL was *published* in 1984. It was considered
good enough of a standard for Symbolics to implement a Common Lisp for
Genera, and LMI (TI?) to implement a Common Lisp for their LispM
offering (what the heck did they call their OS anyway? Or did they
call it anything?) as well as Spice Lisp (later CMU CL) to try to
implement as closely as possible *before* the book was even through
publication. And Kyoto Common Lisp was developed straight from this
book, external from the US Lisp community, IIRC.

> Keene's book indicates that in '86, when CL object models started
> coalesceing into _something_, that there was a diverse set of
> different object models.

Keep in mind that this book is _focusing_ on OO, and hence would see
things from an exaggerated perspective. There weren't *that* many
different object models.

> The point? In 2001 (and, for that matter, 1991 :-() we can point to
> CLOS as an appropriate object model to mandate. In 1984, it certainly
> wasn't an option.

Flavors was already in use in 1984. Flavors was an object system
based on ideas in Smalltalk, developed by (I think) Howard Cannon.
Lisp OO systems were not unknown in 1984 by any means. OO systems
were implemented in Lisp as research toys in the late 70s.

> Similarly (though probably less crucial!), the LOOP facility in CL in
> 1984 differed considerably from the much-extended design voted on in
> 1989.

From AI:.INFO.;LISP LOOP:

LOOP is a Lisp macro which provides a programmable iteration
facility. The same LOOP module operates compatibly in both Lisp
Machine Lisp and Maclisp (PDP-10 and Multics).

This Maclisp implementation of LOOP would serve as the model for LOOP
in the CL standard. Its surface syntax is similar enough in a number
of respects that any modern CL programmer would understand its use.

From CMUCL 18c src/code/loop.lisp:

;;;> Portions of LOOP are Copyright (c) 1986 by the Massachusetts Institute of Technology.
;;;> All Rights Reserved.

The LOOP used in CMUCL started life as Maclisp's LOOP. Seeing as
there is a comment from Symbolics in there as well, I'd be surprised
if Genera didn't use a LOOP derived from the same source (my LispM
isn't powered up otherwise I'd say for certain).

> Differing object models, differing loop models, all would lead to an
> Emacs design based on "CL as of 1984" being a quite different animal
> from one based on "CL as of 1989." (Regardless of whether SERIES is
> considered at _all_ standardized :-).)

It is also good to keep in mind that a good chunk of code written for
CLTL1 will work fine in CLTL2 *and* in ANSI CL as well. There are a
number of differences between these, but they have more in common with
each other than any one of them does with say Scheme or InterLisp.
Indeed, look to any large Lisp implementation for code that even
predates CLTL1 which still runs well or with only minor modifications
in a modern CL.

Really, CL isn't that different now from what it was then, just more
stuff has been added to it, and a lot of software libraries that were
floating around in one form or another were standardized so
programmers could depend upon specific behaviors.

If you want a Lisp that's really *different*, try Lisp 1.5. Heck, try
L Peter Deutsch's Lisp for the PDP-1. It runs on Bob Supnik's PDP-1
emulator at some insane multiple of its original speed.

James A. Crippen

unread,
Sep 26, 2001, 2:34:44 AM9/26/01
to
Rahul Jain <rj...@rice.edu> writes:

> ja...@unlambda.com (James A. Crippen) writes:
>
> > Christopher Stacy <cst...@spacy.Boston.MA.US> writes:
> > One annoyance about the continued persistence of dynamic scoping in
> > Elisp is that it has encouraged others to implement dynamic scoping in
> > their own Lisps. The 'librepl' that is used in (I think) the Sawmill
> > X window manager is also dynamically scoped, and lots of code written
> > in it unfortunately relies on the peculiarities of dynamic scoping.
>
> This is incorrect. rep (librep is the name of the library that is
> linked to for applications that would like to use rep) is lexically
> scoped. I don't know if it even supports dynamic scope at all. It's
> sort of halfway between elisp and scheme for the most part, which
> makes me terribly confused most of the time when I'm trying to use
> it. :)
>
> Oh and Sawmill is a web log analyzer. The window manager's name had to
> be changed to Sawfish due to a trademark conflict.

Yes, I hadn't looked at it in some time. I see now that librep is
lexically scoped. When I had looked at it earlier (two years ago?) it
was dynamically scoped, because the author borrowed its design from
Emacs Lisp.

James A. Crippen

unread,
Sep 26, 2001, 2:54:27 AM9/26/01
to
cbbr...@acm.org writes:

> t...@hurricane.OCF.Berkeley.EDU (Thomas F. Burdick) writes:
> > He seems to have some serious beef against CL. I say "seems",
> > because I'm not sure that he's the source, but GNU Emacs doesn't
> > allow the use of the cl extension package in its distributed code.
> > Which is crazy, because there's some good stuff in there. Also, the
> > whole choice of Scheme as the official GNU extension language.
>
> I think there must have been something very political that happened
> some time in the mists of the past. GCL was out there, and largely
> ignored by all _sorts_ of folk for the longest time.

GCL was based on Austin Kyoto Common Lisp (AKCL) which derives from
Kyoto Common Lisp (KCL) which was based on CLTL1 by Taiichi Yuasa and
Masama Hagiya.

> And it seems to me that there _should_ have been some really vastly
> serious push to have some form of "Schemely" code generator associated
> with GCC in order to encourage wider use of Scheme, and not merely for
> "scripting."

The RTL (register transfer language) used in GCC bears some
resemblance to Lisp, but its primitives are not symbols -- they are
hardcoded in meaning. Thus it has a Lisp syntax, but isn't a Lisp.

RMS used the Lisp syntax because it was easy to parse, so he said.
And probably because it was easily edited with Emacs.

> You should see Tom Lord's discussion of conservative GC; _greatly_
> scathing... He was one of the guys that used to work on Guile, and

Guile has a lame GC. It's mark-sweep and the interpreter spends a lot
of time in it. It needs something with a write barrier or treadmill,
I think. This has been an outstanding problem of Guile's for some
time now, several years.

> is more recently responsible for Systas Scheme.

Yah, conservative GC is only good for languages that need
conservativism, which are typically languages that don't have
intrinsic support for GC, like C or C++. Languages which are designed
around the idea of a GC typically benefit more from some form of
generational collector or perhaps a combination of reference counter,
incremental mark-sweep, and a slower ephemeral generational collector.
The hybrid approach works best in large systems with large spaces. In
small systems a small, simple GC like mark-sweep works better. Some
research has shown that compactifying collectors win, other research
shows the opposite (I think it depends on how long you cook the
numbers, and at what temperature).

Hairy GC questions should be taken to the gc-list. Those people
*live* for garbage collection. It's somewhat frightening, really.
And definitely read Paul Wilson's surveys of GC and dynamic
allocation. Those are required reading. And read Jones and Lins's
book on GC as well, which summarizes much of the current research in
the last decade, research that is missing from the more common
treatments of the subject.

I lived and breathed garbage collection for a while. I suppose I will
again when I get my little Lisp system finished so I can play with GC
implementations again.

James A. Crippen

unread,
Sep 26, 2001, 3:06:04 AM9/26/01
to
Christopher Stacy <cst...@spacy.Boston.MA.US> writes:

> >>>>> On 25 Sep 2001 13:07:45 -0800, James A Crippen ("James") writes:
> James> Compounded with that is that RMS will probably never allow GNU Emacs
> James> to be rewritten to use a different Lisp
>
> Huh? Anybody is "free" to do so! However, RMS might or might not
> want to help with such a port/rewrite: you'd have to ask him.

I meant that he wouldn't go recommending it as his 'official' Emacs,
which he does with GNU Emacs (as opposed to its red-headed stepchild,
XEmacs). RMS is a bit protective of his baby, which is why XEmacs
exists in the first place.

> Let us not start YAGFL (Yet Another GPL Flame War) here, though.
> That's what gnu.misc.discuss is for!

YAG(PL)FW, heh, yeah. :-)

> James> XEmacs developers came up with the idea of an Elisp compatibility
> James> package, but the details of this never arose, IIRC.
>
> Someone did a paper (maybe it was an undergraduate thesis) at MIT
> which included a Scheme compatability library for GNU Elisp.

I think I mentioned this elsewhere as well.

> I'd be more interested in a CL version. One issue is: what
> compiler/interpreter and development tools would be distributed with
> the editor so that people could load extension libraries, and write
> their own extensions.

Well, there'd only be a couple to choose from. CMUCL, CLisp, and GCL.
And GCL isn't as well maintained as the other two, so that's a strike
against it. CMUCL has a large memory footprint (but then, so does
Emacs), and it's slow to start (but then, so is Emacs). CLisp doesn't
perform as well as CMUCL, and the compiler is external (don't know
about CLisp's byte compiler or how that's going lately). Both CLisp
and CMUCL have FFIs, so loading extension libraries is a matter of
writing the Lisp interfaces. As far as other development tools
(pretty printer, cross-indexer/who-calls, class browser, etc) they
should all be in the editor! :-)

It's a tossup between CLisp and CMUCL I think. The other alternative,
rolling a new CL, is also a possibility. The 'white pages' part that
goes into a Lisp kernel isn't that difficult, but implementing all the
rest of the standard takes time.

Erik Winkels

unread,
Sep 26, 2001, 5:31:26 AM9/26/01
to
ja...@unlambda.com (James A. Crippen) writes:
>
> The real solution is to borrow the work done on automatic
> translation of Elisp to Scheme that the Edwin people did for MIT
> Scheme. Snarf that stuff and figure out how far you'd have to go to
> get it to do CL.

Might this be a start? :

http://groups.google.com/groups?q=elisp+cllib&hl=en&rnum=2&selm=u66uc5d82.fsf%40ksp.com

(I have to admit that I haven't looked at it myself)


cheers,
Erik
--
"Have faith in Darwin... By the looks of it, this guy couldn't reproduce
himself if he had an installation wizard."
-- Andreas Skau in the Monastery

Tim Bradshaw

unread,
Sep 26, 2001, 5:33:02 AM9/26/01
to
* James A Crippen wrote:
> Keep in mind that this book is _focusing_ on OO, and hence would see
> things from an exaggerated perspective. There weren't *that* many
> different object models.

There were enough that it was a pain to write large chunks of code and
port them. At least two kinds of flavors (old and new) in several
variants, as well as things like LOOPS (no not the iteration thing)
which were a whole other ball game.

Of course the differences were just a small matter of syntax, except
they weren't, because some systems had MI, some didn't and those that
did computed precedence lists in various differing ways which could be
quite exciting. And I don't think anyone had multiple dispatch (maybe
LOOPS did).

And even post-CLOS it was not clear to a lot of people that CLOS
implementations would ever be fast enough to really use in anger
because of all the frightening stuff like redefinition and so on. In
practice PCL (which was all that most people had for a fair time) was
just *glacial* at times. Genera didn't have native CLOS till 8.x, ACL
till I'm not sure when (4.x?), and until people saw those
implementations - mostly for us ACL's, because I don't think we really
saw a future in special HW - it really was not obvious that CLOS was
going to be usable.

It all seems clear now in retrospect, and maybe it was even clear then
if you were one of the right 20 people, but it really was not clear to
a random Lisp hacker.

--tim

Tim Bradshaw

unread,
Sep 26, 2001, 5:17:37 AM9/26/01
to
* cbbrowne wrote:
> I think there must have been something very political that happened
> some time in the mists of the past. GCL was out there, and largely
> ignored by all _sorts_ of folk for the longest time.

Well, GCL was KCL and then AKCL before it was GCL and it was
encumbered in various curious ways which probably prevented its free
use. I forget the details, but I think the deal may have been that it
was free for educational use only, and even then you had to physically
sign something. This is trying to remember more than 12 years back,
so I may have the licensing details wrong.

Tim Bradshaw

unread,
Sep 26, 2001, 5:38:20 AM9/26/01
to
* I wrote:

> He seems to have some serious beef against CL. I say "seems", because
> I'm not sure that he's the source, but GNU Emacs doesn't allow the use
> of the cl extension package in its distributed code. Which is crazy,
> because there's some good stuff in there. Also, the whole choice of
> Scheme as the official GNU extension language.

It's not clear to me that not allowing the cl package is because of
anti-CL sentiment: it may be because of history. There have been at
least two versions of cl.el, and the older one was *seriously* awful.
I'm a CL programmer, and *I* have elisp packages I've written which
contain implementations of bits of CL because I absolutely did not
want cl.el loaded into my emacs if I could possibly avoid it because
it broke so much stuff.

The new cl.el is much better - I'm not sure when the transition was
but it's not that long ago (maybe 5-7 years). I still have to remind
myself that (require 'cl) is an OK thing to do, though.

--tim

Erik Naggum

unread,
Sep 26, 2001, 7:39:25 AM9/26/01
to
* James A Crippen
> Compounded with that is that RMS will probably never allow GNU Emacs to

> be rewritten to use a different Lisp

* Christopher Stacy


> Huh? Anybody is "free" to do so! However, RMS might or might not want
> to help with such a port/rewrite: you'd have to ask him.

Well... the freedom to fork is illusory at best. The animosity from RMS
over the fork between Classic Emacs and Lucid Emacs (later XEmacs) is
legendary. When I tried to help people get access to the new features of
Emacs 20 but get rid of the still seriously braindamaged MULE crap, I
carefully created a backward-compatible "Multi-Byte Survival Kit", which
was picked up by RedHat and had many thousands of users. RMS' response
to this was to introduce an incompatibility in the byte-compiled file
format (it now required MULE crap to load, which really is unnecesasry)
the very next release in order to keep people away from it.

> I'd be more interested in a CL version.

I think it would have been the greatest thing for the spread of Common
Lisp to produce the next generation Emacs based in a real Lisp with a
much better design of the whole application and user-visible language.
Emacs Lisp is hopelessly ancient, and has even gone the way of Scheme
with non-general and type-specific functions.

> One issue is: what compiler/interpreter and development tools would be
> distributed with the editor so that people could load extension
> libraries, and write their own extensions.

Since this is one of those thing that really would move the Common Lisp
community forward, the ideal situation would be for the vendors to gang
up with a funded, but voluntary team and provide the necessary support to
get this going as a demonstration project for the power of Common Lisp.
However, I think it might be as much as a 100-man-year job, the funding
for which might have to come from Osama bin Laden's frozen funds because
there simply is not enough resources to do this for free elsewhere now.

///
--
Why did that stupid George W. Bush turn to Christian fundamentalism to
fight Islamic fundamentalism? Why use terms like "crusade", which only
invokes fear of a repetition of that disgraceful period of Christianity
with its _sustained_ terrorist attacks on Islam? He is _such_ an idiot.

Erik Naggum

unread,
Sep 26, 2001, 7:43:35 AM9/26/01
to
* Christopher Stacy

> I'd be more interested in a CL version. One issue is: what
> compiler/interpreter and development tools would be distributed with the
> editor so that people could load extension libraries, and write their own
> extensions.

* James A. Crippen


> Well, there'd only be a couple to choose from. CMUCL, CLisp, and GCL.

This is a _very_ counter-productive position. Excluding the commercial
vendors from this project will be the best way ever to destroy Common
Lisp. Instead, write the Emacs on top of sufficiently powerful Common
Lisp and cause the free Common Lisps to become powerful enough to deal
with it. If you start with an insufficiently powerful Common Lisp, you
will get the same kind of rushed disasters that Emacs Lisp is full of.
We have to realize that the reason that Emacs Lisp is the way it is, is
that the core language support is hopelessly insufficient.

Christopher Stacy

unread,
Sep 26, 2001, 9:36:23 AM9/26/01
to
>>>>> On Wed, 26 Sep 2001 04:36:12 GMT, cbbrowne ("cbbrowne") writes:
>> >>>>> On Wed, 26 Sep 2001 00:54:18 GMT, cbbrowne ("cbbrowne") writes:
cbbrowne> Mind you, what we'd do today, using CL (with CLOS!), is quite
cbbrowne> different from what would have been likely back in 1984.

cbbrowne> Looking at the references in my online copy of CLTL2,
cbbrowne> the CLOS references are all dated 1989.

I think that if the editor had been written in 1984, it would have
been very much like what a CLOS programmer would do today.
Everything else was!

Flavors, the original first-class object-oriented Lisp language extension
on the Lisp Machine, is more than 10 years before your date. Flavors was
single-dispatch, and originally used the (SEND obj :MESSAGE args) calling
syntax but much later switched to normal function calling syntax.
You said DEFFLAVOR instead of DEFCLASS, you said DEFMETHOD, but there was
no DEFGENERIC and method lambda-list congruency was not enforced, and
Flavors had some features that CLOS lacks. Flavors had no MOP.
CLOS is very much like Flavors in many ways, and it is easy to
mechanically convert programs from Flavors into CLOS.

Why does everyone act like nothing existed before CLTL1?!?
Common Lisp is mostly descended from the Lisp Machine (and MACLISP).
The Lisp Machine itself began around 1975 - the CADR came out around
1978, and Flavors was part of the system by at least 1980. Flavors
was based on some ideas about certain generic operations in MACLISP
(SFAs) and influenced by Smalltalk. and by Hewitt's Actors, and by
a nearby ice cream store (Steve's) where they "mixed in" additional
behaviours (well, specific nuts and candies) with the primary flavor
that you selected.

The original Lisp Machine editor circa 1977 was called EINE, and ZWEI
was around before the end of 1979. My guess for the reason that ZWEI
used DEFSTRUCT (and the "array-leader" hack) instead of Flavors, is that
Flavors may not have been ready for prime-time when DLW began writing
the program. The Lisp Machine window system did not use Flavors until
a little after ZWEI.

j...@itasoftware.com

unread,
Sep 26, 2001, 9:51:16 AM9/26/01
to
ja...@unlambda.com (James A. Crippen) writes:

> It was considered good enough of a standard for Symbolics to
> implement a Common Lisp for Genera, and LMI (TI?) to implement a
> Common Lisp for their LispM offering (what the heck did they call
> their OS anyway? Or did they call it anything?)

LMI didn't call it anything. They sort of thought naming the OS (such
as it was) was pompous.

> Flavors was already in use in 1984. Flavors was an object system
> based on ideas in Smalltalk, developed by (I think) Howard Cannon.
> Lisp OO systems were not unknown in 1984 by any means. OO systems
> were implemented in Lisp as research toys in the late 70s.

I recall that `new flavors' was a major contender. No one has
mentioned Drescher's `Object Lisp', but that had a few proponents as
well (mostly at LMI).

People skeptical of CLOS thought multi-dispatch would be `too slow'
and that perhaps functions ought to belong to a class. The
self-referential MOP was also considered to be `overkill' (or mental
masturbation). There is quite a bit of work in bootstraping CLOS in
order to present the illusion that CLOS is implemented in CLOS, and
this seemed to be a rather academic issue.

There was also the issue that there was virtually no interesting code
written in CLOS, but the entire LispM window system was written in
Flavors (I think new flavors held the promise of an easier migration
route).

Marco Antoniotti

unread,
Sep 26, 2001, 10:04:13 AM9/26/01
to

Tim Bradshaw <t...@cley.com> writes:

The original KCL had a not-so-restrictive license. The license was
not DFSG compliant AFAIR, and, to actually get it, you had to write
Kyoto. I still have mine somewhere. The same applied for AKCL.

Before AKCL, there where two commercial products based on KCL. Ibuki
CL (from California, a Stanford spin off, headed by Professor
Weyrauch - barring spelling mistakes) and Delphi CL, from Pisa,
originating from the startup of Prof. Attardi's (incidentally, the
first importer of Symbolics and Sun workstations in Italy).

Delphi CL evolved into EcoLisp, which is now being evolved again as
ECL (is that the name?)

Cheers

--
Marco Antoniotti ========================================================
NYU Courant Bioinformatics Group tel. +1 - 212 - 998 3488
719 Broadway 12th Floor fax +1 - 212 - 995 4122
New York, NY 10003, USA http://bioinformatics.cat.nyu.edu
"Hello New York! We'll do what we can!"
Bill Murray in `Ghostbusters'.

Erik Winkels

unread,
Sep 26, 2001, 10:38:39 AM9/26/01
to
Marco Antoniotti <mar...@cs.nyu.edu> writes:
>
> Delphi CL evolved into EcoLisp, which is now being evolved again as
> ECL (is that the name?)

It is called ECLS now:

http://ecls.sourceforge.net/


Erik.

James A. Crippen

unread,
Sep 26, 2001, 1:29:30 PM9/26/01
to
Christopher Stacy <cst...@spacy.Boston.MA.US> writes:

> I think that if the editor had been written in 1984, it would have
> been very much like what a CLOS programmer would do today.
> Everything else was!

Indeed.

> Flavors, the original first-class object-oriented Lisp language extension
> on the Lisp Machine, is more than 10 years before your date. Flavors was
> single-dispatch, and originally used the (SEND obj :MESSAGE args) calling
> syntax but much later switched to normal function calling syntax.
> You said DEFFLAVOR instead of DEFCLASS, you said DEFMETHOD, but there was
> no DEFGENERIC and method lambda-list congruency was not enforced, and
> Flavors had some features that CLOS lacks. Flavors had no MOP.
> CLOS is very much like Flavors in many ways, and it is easy to
> mechanically convert programs from Flavors into CLOS.

New Flavors IIRC discarded the (SEND obj :MESSAGE args) stuff in favor
of something more resembling generic functions. Right? Haven't
looked at any Flavors code in a while though.

> Why does everyone act like nothing existed before CLTL1?!?

Too many things existed before CLTL1. That's why CLTL1 was created.

> Common Lisp is mostly descended from the Lisp Machine (and MACLISP).
> The Lisp Machine itself began around 1975 - the CADR came out around
> 1978, and Flavors was part of the system by at least 1980. Flavors
> was based on some ideas about certain generic operations in MACLISP
> (SFAs)

^^^^
Can you explain?

> and influenced by Smalltalk. and by Hewitt's Actors, and by
> a nearby ice cream store (Steve's) where they "mixed in" additional
> behaviours (well, specific nuts and candies) with the primary flavor
> that you selected.

Coldstone is now well known for the same process.

> The original Lisp Machine editor circa 1977 was called EINE, and ZWEI
> was around before the end of 1979. My guess for the reason that ZWEI
> used DEFSTRUCT (and the "array-leader" hack) instead of Flavors, is that
> Flavors may not have been ready for prime-time when DLW began writing
> the program. The Lisp Machine window system did not use Flavors until
> a little after ZWEI.

Was EINE related to Multics Emacs which (as I recall) was written in
Maclisp? Or was EINE created from whole cloth?

Thomas F. Burdick

unread,
Sep 26, 2001, 5:51:14 PM9/26/01
to
cbbr...@acm.org writes:

> t...@hurricane.OCF.Berkeley.EDU (Thomas F. Burdick) writes:
>
> > I absolutely agree here. Emacs' status has given an impression of
> > credibility to its design decisions, outside of any context. I
> > think a lot of the way Elisp works is the right decision for Emacs
> > now, not because I couldn't think of a better way to do it, but
> > because any better way would involve rewriting Gnus, VM, AucTeX,
> > etc, etc, making the cure worse than the disease. Without
> > understanding the context of the goodness of these design decisions,
> > though, people apparently will just copy those decisions.
>
> .. And if the point is to build something that's long-term
> extensible, there _are_ properties of dynamic scope that have some
> value, so that the "cure" might, along with being worse than the
> disease, make some extensions harder to do later.

I think CLOS with *tasteful* use of special variables would provide
the same power to extend, and those extensions would be easier to
follow. Leaving Elisp as it is, except making it lexically scoped
*would* be terrible. Every function would have 20 pieces of around
advice (*shudder*).

> >> There are a number of other *NASTY* problems with Elisp,
> >> particularly the way it interfaces with its garbage collector.
> >> This requires hairy macro placement (using GCPRO()) to keep
> >> pointers from going missing in the divide between C and Elisp.
>
> > I admit it's nit-picking a bit to differentiate between the language
> > and its implementation when the language isn't standardized and it
> > only has two nearly-identical implementations, but this is
> > definitely an implementation issue, and not one with the language.
> > This is only visible from within the implementation, and could be
> > fixed without breaking any existing lisp code. So it's a problem
> > with the Elisp interpreter, not with Elisp itself. If I'm not
> > mistaken, GNU Emacs is planning on replacing the current GC with a
> > portable conservative GC (maybe Boehm's), eventually making the
> > whole, aweful GCPRO mess a non-issue.
>
> You should see Tom Lord's discussion of conservative GC; _greatly_
> scathing... He was one of the guys that used to work on Guile, and is
> more recently responsible for Systas Scheme.

I think that's only relevant when you have a choice. I don't think
it's possible to have a precise GC for portable C code (although I'd
be happy to be corrected, preferably on the gc-list :). Certainly for
something as messy as the Emacs source code, a conservative GC is
really the only option.

Thomas F. Burdick

unread,
Sep 26, 2001, 5:57:02 PM9/26/01
to
Graham Hughes <gra...@sigwinch.org> writes:

> >>>>> "Thomas" == Thomas F Burdick <t...@hurricane.OCF.Berkeley.EDU> writes:
>
> Thomas> He seems to have some serious beef against CL. I say
> Thomas> "seems", because I'm not sure that he's the source, but
> Thomas> GNU Emacs doesn't allow the use of the cl extension
> Thomas> package in its distributed code. Which is crazy, because
> Thomas> there's some good stuff in there. Also, the whole choice
> Thomas> of Scheme as the official GNU extension language.
>
> cd /usr/share/emacs/21.0.104/lisp/
> grep -n "(require 'cl)" *.el /dev/null
> winner.el:44: (require 'cl))

Well what'd'y'know.

[ more references ... ]

> That is perhaps overstated. It is true, I believe, that any packages
> that are automatically loaded into Emacs and then dumped with the
> Emacs image (cc-mode comes to mind) cannot use the CL library, and I
> don't know why that is

Hmm, that must be it. I'm actually more confused now, because if so
many packages use `cl', it would be nice to have it in pure space, so
it could be shared. It's kind of big, after all...

Thomas F. Burdick

unread,
Sep 26, 2001, 6:02:57 PM9/26/01
to
Erik Naggum <er...@naggum.net> writes:

> * Christopher Stacy
> > I'd be more interested in a CL version. One issue is: what
> > compiler/interpreter and development tools would be distributed with the
> > editor so that people could load extension libraries, and write their own
> > extensions.
>
> * James A. Crippen
> > Well, there'd only be a couple to choose from. CMUCL, CLisp, and GCL.
>
> This is a _very_ counter-productive position. Excluding the commercial
> vendors from this project will be the best way ever to destroy Common
> Lisp. Instead, write the Emacs on top of sufficiently powerful Common
> Lisp and cause the free Common Lisps to become powerful enough to deal
> with it.

Okay, but you'd still need it to ship with a free CL, because I can't
imagine any C++ programmer wanting to buy a commercial CL just to run
Emacs, especially if s/he could just use the old Elisp-based one.

Plus, as far as I know, CLISP is the only CL that's approximately as
portable as GNU/X Emacs.

> If you start with an insufficiently powerful Common Lisp, you will
> get the same kind of rushed disasters that Emacs Lisp is full of.
> We have to realize that the reason that Emacs Lisp is the way it
> is, is that the core language support is hopelessly insufficient.

That's probably true. So the first step would be to beef up CLISP to
around commercial quality. Hell, if you threw all the development
hours going to GNU Emacs and X Emacs into the task of writing a Really
Good CL-Based Emacs, you could probably do it. Alas, I'll probably be
having a snowball fight with the devil by the time this happens,
though...

Thomas F. Burdick

unread,
Sep 26, 2001, 6:08:44 PM9/26/01
to
Erik Naggum <er...@naggum.net> writes:

> * James A Crippen
> > Compounded with that is that RMS will probably never allow GNU Emacs to
> > be rewritten to use a different Lisp
>
> * Christopher Stacy
> > Huh? Anybody is "free" to do so! However, RMS might or might not want
> > to help with such a port/rewrite: you'd have to ask him.
>
> Well... the freedom to fork is illusory at best. The animosity from RMS
> over the fork between Classic Emacs and Lucid Emacs (later XEmacs) is
> legendary. When I tried to help people get access to the new features of
> Emacs 20 but get rid of the still seriously braindamaged MULE crap, I
> carefully created a backward-compatible "Multi-Byte Survival Kit", which
> was picked up by RedHat and had many thousands of users. RMS' response
> to this was to introduce an incompatibility in the byte-compiled file
> format (it now required MULE crap to load, which really is unnecesasry)
> the very next release in order to keep people away from it.

Interesting, I'd wondered why the format had changed. I kind of wish
I didn't know, because that's a really stupid reason and it's really
annoying on a system with several versions of Emacs installed.

At various times I've considered spending some time on Emacs
development, but I always end up deciding that the source is too
nasty, and my skin's not thick enough. Periodically I get that second
point reinforced again.

Kent M Pitman

unread,
Sep 26, 2001, 6:25:53 PM9/26/01
to
ja...@unlambda.com (James A. Crippen) writes:

> > Flavors
> > was based on some ideas about certain generic operations in MACLISP
> > (SFAs)
> ^^^^
> Can you explain?

Software File Arrays. Howard Cannon designed both SFA's in Maclisp and,
later, Flavors for the LispM. Chris is right to point out SFA's as the
conceptual parent of them. They were a special-purpose kind of object
for use in defining I/O (sort of like a class system whose only purpose
was writing streams, though technically nothing forced you to do I/O through
them and some of us perverted them for other purposes once in a while).
They basically had the ability to make an object with n indexed slots for
data and then to do SFA-CALL on the object to access one of several methods
that were defined by the programmer. The system had some pre-defined methods
it looked for, but you could add your own. The method got a pointer to the
object and could do an indexed slot access. It was really just a crude
flavor system where the storage mechanism was all too prominent and needed
to be abstracted away.

Kent M Pitman

unread,
Sep 26, 2001, 6:32:40 PM9/26/01
to
ja...@unlambda.com (James A. Crippen) writes:

> Christopher Stacy <cst...@spacy.Boston.MA.US> writes:
>
> > [Flavors]...You said DEFFLAVOR instead of DEFCLASS, you said


> > DEFMETHOD, but there was no DEFGENERIC and method lambda-list

> > congruency was not enforced, and...

> New Flavors IIRC discarded the (SEND obj :MESSAGE args) stuff in favor
> of something more resembling generic functions. Right? Haven't
> looked at any Flavors code in a while though.

Most of what Chris said is right, but James' correction is also essentially
right. The New Flavors DEFGENERIC was still single-dispatch and didn't have
the arglist congruency, so it allowed some awful overloading.

> > The original Lisp Machine editor circa 1977 was called EINE, and ZWEI
> > was around before the end of 1979. My guess for the reason that ZWEI
> > used DEFSTRUCT (and the "array-leader" hack) instead of Flavors, is that
> > Flavors may not have been ready for prime-time when DLW began writing
> > the program. The Lisp Machine window system did not use Flavors until
> > a little after ZWEI.
>
> Was EINE related to Multics Emacs which (as I recall) was written in
> Maclisp? Or was EINE created from whole cloth?

I'm pretty sure Multics Emacs was written by Bernie Greenberg in
Multics Maclisp.

I'm pretty sure EINE was a completely unrelated project. Having looked at
the code, I'd guess by Mike McMahon. But maybe others, too.

Kent M Pitman

unread,
Sep 26, 2001, 6:46:43 PM9/26/01
to
j...@itasoftware.com writes:

> ja...@unlambda.com (James A. Crippen) writes:
>
> > It was considered good enough of a standard for Symbolics to
> > implement a Common Lisp for Genera, and LMI (TI?) to implement a
> > Common Lisp for their LispM offering (what the heck did they call
> > their OS anyway? Or did they call it anything?)
>
> LMI didn't call it anything. They sort of thought naming the OS (such
> as it was) was pompous.
>
> > Flavors was already in use in 1984. Flavors was an object system
> > based on ideas in Smalltalk, developed by (I think) Howard Cannon.
> > Lisp OO systems were not unknown in 1984 by any means. OO systems
> > were implemented in Lisp as research toys in the late 70s.
>
> I recall that `new flavors' was a major contender. No one has
> mentioned Drescher's `Object Lisp', but that had a few proponents as
> well (mostly at LMI).

There were four contenders: Flavors, Object Lisp, LOOPS (from Xerox), and
another one by Russ Atkinson that I can't remember the name of. Maybe
Common Objects? It had some nice notions of encapsulation I was sad
got lost.

The chief proble with Object Lisp was that it didn't have a class/object
distinction. If I recall, it worked like the MOO language of today, and
perhaps like Logo?, where you can instantiate any instance. I think a lot
of people feel this isn't as clean and leads to problems in describing
behaviors of objects because one must always speak in terms of pedigrees
instead of classes. Classes are really a natural conceptual concept
and one is handicapped without a corresponding implementational object.
I've used MOO and I can appreciate that there are some cool things about
this paradigm, but sort of like the Mac user interface, it feels more
optimized to newbies than serious uses. The more complex things get, the
more you wish for class structure.

> People skeptical of CLOS thought multi-dispatch would be `too slow'
> and that perhaps functions ought to belong to a class. The
> self-referential MOP was also considered to be `overkill' (or mental
> masturbation). There is quite a bit of work in bootstraping CLOS in
> order to present the illusion that CLOS is implemented in CLOS, and
> this seemed to be a rather academic issue.

Offering a freely available PCL (Portable Common LOOPS) that was a
proto-CLOS was essential to gaining community consensus to the idea that
this could be done efficiently.

The condition system had the same problem (and the same solution-- a free
reference implementation).

> There was also the issue that there was virtually no interesting code
> written in CLOS, but the entire LispM window system was written in
> Flavors (I think new flavors held the promise of an easier migration
> route).

The Xerox crowd had been largely omitted from the design of Common
Lisp, primarily because CL's design addressed the issue that Interlisp
almost won ARPA's heart for having more installed base. The Maclisp
community had lots of users, but every installation used a slightly
variant dialect and we had to unify to make CL in order to prove to
ARPA that we had the bigger installed base. So we were at war with
Interlisp, and we left them out. When ANSI CL happened, Xerox showed
up to join. I've heard it said that the price of repatriating a
left-out party is that you have to take some of their ideas and
integrate them, and I heard some people say that letting Xerox have
its way a lot with CLOS was the price of getting the Xerox/Interlisp
community folded back into Lisp community as a whole. To some extent
I think people didn't believe in the ideas but just weren't up to
fighting. But the ideas were sound and it's good we took them, I
think... except it did create some rift between Lisp and the rest of
the "encapsulation" community of programming languages. But c'est la
vie. This is all just my subjective impression and personal opinion;
not the official opinion of anything or anyone I've worked for or
belonged to.

Erik Naggum

unread,
Sep 26, 2001, 7:12:53 PM9/26/01
to
* t...@whirlwind.OCF.Berkeley.EDU (Thomas F. Burdick)

> Okay, but you'd still need it to ship with a free CL, because I can't
> imagine any C++ programmer wanting to buy a commercial CL just to run
> Emacs, especially if s/he could just use the old Elisp-based one.

It would probably not be a commercial product based on the commercial
Common Lisps. I would argue that there is so much marketing value in an
Emacs running on a Commercial Lisp that is downloadable over the Net that
it would far outweigh the usefulness of, say, a free Linux trial edition.

> Plus, as far as I know, CLISP is the only CL that's approximately as
> portable as GNU/X Emacs.

I do not think it is useful to aim for maximal portability from day 1.

> So the first step would be to beef up CLISP to around commercial quality.

Well, you cannot do that without the demand and a serious competition to
catch up with. Large free projects die when they have no cometitor, even
though most of the propaganda for Open Source and the like is that people
share their efforts. Linux succeeds so well because many very good and
very smart people hate Microsoft's hegemony so much they want to beat it
into a pulp. Take way Microsoft, and you take away so much of the "fuel"
for Linux's and Open Source development that people will realize that it
was not for anything else they __actually did it. Good thing there will
be yet a few years before they croak.

James A. Crippen

unread,
Sep 26, 2001, 7:41:16 PM9/26/01
to
t...@whirlwind.OCF.Berkeley.EDU (Thomas F. Burdick) writes:

> Erik Naggum <er...@naggum.net> writes:
>
> > * Christopher Stacy
> > > I'd be more interested in a CL version. One issue is: what
> > > compiler/interpreter and development tools would be distributed with the
> > > editor so that people could load extension libraries, and write their own
> > > extensions.
> >
> > * James A. Crippen
> > > Well, there'd only be a couple to choose from. CMUCL, CLisp, and GCL.
> >
> > This is a _very_ counter-productive position. Excluding the commercial
> > vendors from this project will be the best way ever to destroy Common
> > Lisp. Instead, write the Emacs on top of sufficiently powerful Common
> > Lisp and cause the free Common Lisps to become powerful enough to deal
> > with it.
>
> Okay, but you'd still need it to ship with a free CL, because I can't
> imagine any C++ programmer wanting to buy a commercial CL just to run
> Emacs, especially if s/he could just use the old Elisp-based one.
>
> Plus, as far as I know, CLISP is the only CL that's approximately as
> portable as GNU/X Emacs.

Ah, good point. Hadn't thought of that. It would be. CMUCL doesn't
run on certain platforms. And it has some funny build requirements.

Dunno what the state of SBCL is as far as porting it to platforms that
CMUCL hasn't already been ported to at some point.

I think that bundling CLisp with the CL-based Emacs wouldn't be a bad
idea, but it would be important to design the Emacs such that it could
be easily recompiled and used in some other CL. Thus the interfaces
to things like files, network protocols, graphics displays, etc,
should all be done through clean interfaces so that the internals of
each could be reimplemented without having to untangle the Emacs from
its support systems.

This is only good design, but that's part of the problem -- the two
popular Emacsen suffer from a lack of design forethought.

> > If you start with an insufficiently powerful Common Lisp, you will
> > get the same kind of rushed disasters that Emacs Lisp is full of.
> > We have to realize that the reason that Emacs Lisp is the way it
> > is, is that the core language support is hopelessly insufficient.
>
> That's probably true. So the first step would be to beef up CLISP to
> around commercial quality. Hell, if you threw all the development
> hours going to GNU Emacs and X Emacs into the task of writing a Really
> Good CL-Based Emacs, you could probably do it. Alas, I'll probably be
> having a snowball fight with the devil by the time this happens,
> though...

Nah, it's not important to take on the task of improving CLisp. You'd
be better off leaving that to the people who hack on CLisp regularly.
They'd be quite happy to help get an Emacs running faster in their
system, I'm sure. Don't fall into the trap of 'one person should do
everything' or 'everything should be implemented from scratch'.
That's what kills a lot of public software development projects.

The whole idea of implementing a CL Emacs isn't that terribly
difficult. Someone just needs to start planning it. If the plans and
design are public then anyone can pick up from there. The hard parts
are design and infrastructure. Building the Emacs is just a matter of
borrowing the best Emacs design ideas from the past and implementing
them efficiently, then gluing them all together according to the
design specs. And if it's all done in CL it'd be pretty fast to
develop, as compared to something like C.

What parts already exist?

CLX for the X interface. Design with the idea of using CLIM someday
when a free implementation is available. Perhaps extending CLX's back
end to use the Lucid Emacs widgets that have already been built.
Those are completely free and hackable, and are well ported. Or else
some popular widget set could be used (I don't encourage the use of
the Athena widgets, really) but most of those widget libraries are
more complicated, or carry licensing restrictions.

Sam Steingold appears to have taken the initial baby steps in getting
ELisp code usable under CL. See http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/~checkout~/clocc/clocc/src/cllib/elisp.lisp

Networking seems to have been started with net.lisp, another work by
Sam Steingold: http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/~checkout~/clocc/clocc/src/port/net.lisp

The various implementations of networking protocols already done in
ELisp should be coalesced into a general sort of networking layer.

File system handling is fairly well taken care of already in CL. It's
not pretty, and perhaps some sort of Emacs-specific file handling
library should be built on top of it (since the major targets for it
will be Unix, WinDOS, and perhaps MacOS <=9).

The existing ELisp software would need porting, but I don't think that
it would be terribly hard to implement an ELisp REPL under CL, based
on the work already done by Steingold, and perhaps using some of the
ideas from that MIT-AI memo on translating ELisp to Scheme. Then
software could be easily converted over time, or just used in the
emulated ELisp.

However, I think that the users of CL Emacs would soon end up
developing their own software for use with CL Emacs, separate from
that used in RMS Emacs. Things would just be better done differently
in a CL Emacs than they would simply translating ELisp.

All in all, the parts are already out there to build a CL Emacs. All
it needs is some careful work put into design. Then it just takes
time and commitment.

Hrvoje Niksic

unread,
Sep 26, 2001, 8:22:59 PM9/26/01
to
Graham Hughes <gra...@sigwinch.org> writes:

> That is perhaps overstated. It is true, I believe, that any
> packages that are automatically loaded into Emacs and then dumped
> with the Emacs image (cc-mode comes to mind) cannot use the CL

> library, and I don't know why that is, but certainly (require 'cl)
> is not actively discouraged.

An examination of your `grep' hits shows that most, if not all, of
them are wrapped in `eval-when-compile', which means that they are
careful not to require cl*.el at run-time.

Things might have changed recently, but it used to be the case that
Stallman allowed the use of CL macros like `setf' and `push', but
discouraged the use of functions. He requested that often-used Emacs
packages in the Emacs distribution not require cl*.el to be loaded at
run-time.

Unfortunately, this prevents some very useful parts of the interface
from being used.

Daniel Barlow

unread,
Sep 26, 2001, 9:07:20 PM9/26/01
to
ja...@unlambda.com (James A. Crippen) writes:

> Dunno what the state of SBCL is as far as porting it to platforms that
> CMUCL hasn't already been ported to at some point.

SBCL is fundamentally about as hard to port as CMUCL is: i.e. not much
work at all for new OSes on an existing architecture, provided they're
POSIXy; substantially more work to introduce a new backend, much of
which is doing things like transcribing the entire instruction set and
assembler mnemonics thereof.

It's not a candidate for software that you hope to see on Windows any
time soon, unless you'd like to work on porting it to windows.

> All in all, the parts are already out there to build a CL Emacs. All
> it needs is some careful work put into design. Then it just takes
> time and commitment.

I love the way you say "just"


-dan

--

http://ww.telent.net/cliki/ - Link farm for free CL-on-Unix resources

Arun Welch

unread,
Sep 26, 2001, 10:25:32 PM9/26/01
to

>> ja...@unlambda.com (James A. Crippen) writes:
>>
>> There was also the issue that there was virtually no interesting code
>> written in CLOS, but the entire LispM window system was written in
>> Flavors (I think new flavors held the promise of an easier migration
>> route).

I think the first major system implemented in CLOS (aside from CLOS
itself :-) was CLIM. If memory serves, there was even some shared code
in early versions of each, since Gregor and Ramana were colocated. It
was also the only object system that satisfied the portability
requirements of CLIM.

On Wed, 26 Sep 2001 22:46:43 GMT, Kent M Pitman <pit...@world.std.com>
wrote:

>
>The Xerox crowd had been largely omitted from the design of Common
>Lisp, primarily because CL's design addressed the issue that Interlisp
>almost won ARPA's heart for having more installed base. The Maclisp
>community had lots of users, but every installation used a slightly
>variant dialect and we had to unify to make CL in order to prove to
>ARPA that we had the bigger installed base. So we were at war with
>Interlisp, and we left them out. When ANSI CL happened, Xerox showed
>up to join.

The early history has been pretty well documented already, but I think
Xerox shot their own foot off by thinking they could go it alone.

>I've heard it said that the price of repatriating a
>left-out party is that you have to take some of their ideas and
>integrate them, and I heard some people say that letting Xerox have
>its way a lot with CLOS was the price of getting the Xerox/Interlisp
>community folded back into Lisp community as a whole.

Actually, CLOS is radically different from LOOPS, and shares almost
nothing with it other than the early name of CommonLoops. Gregor did
most of the implementation on a Symbolics, and even porting PCL to
Xerox Common Lisp was non-trivial. I think the analogy to SERIES is
closer, as it was a portable object system that ran on most
implementations, and the bulk of the work on it was done by an
independent third party (Gregor worked for PARC, and by that time
Xerox had rid themselves of the Lisp business).

I think the biggest objection to CLOS was the perception that it was
going to be slow and expensive. I've got a paper around here that
theorised that the fastest slot lookup would take at least 3 cycles,
method dispatch 5, or something like that. PCL of that era was much
slower.

The first native CLOS, if memory serves, was that for the TI Explorer.
In fact TICLOS was faster than Flavors. I think Jonl was next to
depart from PCL as a base for CLOS, and Lucid's native version was a
lot faster than the PCL version. Franz did the same thing, if memory
serves, with similar results. This is also why the MOP never got
standardised, since everyone had started to diverge from the base
code. I seem to remember some sort of "ignore the MOP and you can run
faster CLOS" switches in the early native versions (I remember
something like this in Lucid, I'm not so certain about Franz'
version).

There's a bunch of CLOS history in Andreas Paepcke's book, "Object
Oriented Programming - The CLOS Perspective".

...arun

Friedrich Dominicus

unread,
Sep 27, 2001, 1:50:14 AM9/27/01
to
ja...@unlambda.com (James A. Crippen) writes:


> This is only good design, but that's part of the problem -- the two
> popular Emacsen suffer from a lack of design forethought.

Don't you think this is a bit arrogant? To what time were the Emacses
implemented? And haven't the grown since then considerably? Have you
considered that all the adding and patches to support the new ideas
have messed up the initial design?

>
> The whole idea of implementing a CL Emacs isn't that terribly
> difficult. Someone just needs to start planning it.

Well I encourage you to start the planning. And of course I hope you
can show a "proof-of-concept" soon it isn't "that terrible difficult"
(your words)

>If the plans and
> design are public then anyone can pick up from there. The hard parts
> are design and infrastructure.

Is design really the problem? I can't see how a design can be so good
right from the start to grow in such strange areas as the Emacs stuff
has. Well according to Peter? Gabriel in software patterns it seems
it's more important to plan for what he calls "piecemeal growth" than
for anything else. The promoters of XP have a simular opinion I guess
and they have some good reasons on their side.

>Building the Emacs is just a matter of
> borrowing the best Emacs design ideas from the past and implementing
> them efficiently, then gluing them all together according to the
> design specs.

Well I really would see one of those design specs. And I bet the end
result will not have much in commoin with it.


> And if it's all done in CL it'd be pretty fast to
> develop, as compared to something like C.

Again, I encourage you to got for it. You can bash C as long as you
like but you will find magnitudes more code and libraries written in C
than in Common Lisp.

>
> What parts already exist?
>
> CLX for the X interface. Design with the idea of using CLIM someday
> when a free implementation is available.

What a work, plan for one implementation but be sure that you can
change it on the fly during later stages without sacrifiying
anything.

I bet that this is hardly possible. And I too think one probably
better start with CLIM right from the start. Even if there isn't a
free implementation available at the moment. Why now CLX as you said
is runs on X. What about Apples? What about Windows? AFAIK does all
the vendors offer CLIM and it's available on all platforms. Well the
decision of course should be if one should care right from the start
about portability or not. Well you mentioned design foresougth, I
can't tell what "the right thing" would be.


>
> The various implementations of networking protocols already done in
> ELisp should be coalesced into a general sort of networking layer.

Oh fine, I assume you volonteer?


>
> The existing ELisp software would need porting, but I don't think that
> it would be terribly hard to implement an ELisp REPL under CL, based
> on the work already done by Steingold, and perhaps using some of the
> ideas from that MIT-AI memo on translating ELisp to Scheme. Then
> software could be easily converted over time, or just used in the
> emulated ELisp.

That might be a feasible way. I can't tell. It could be that a sort of
compiler or so may be a better option. Wel I do not think that the
MIT memo about Elisp and Scheme is all too helpful, they have a bunch
of problems which simply do not exist in Common Lisp...

>
> However, I think that the users of CL Emacs would soon end up
> developing their own software for use with CL Emacs, separate from
> that used in RMS Emacs.

I agree, anyway it will be the question if CL Emacs provides so much
as the "old" Emacses do at the moment. Or at least the provide what
most of the people are expecting from an "Emacs-based" Editor.

Regards
Friedrich

Christopher Stacy

unread,
Sep 27, 2001, 3:35:16 AM9/27/01
to
>>>>> On 27 Sep 2001 07:50:14 +0200, Friedrich Dominicus ("Friedrich") writes:
>> And if it's all done in CL it'd be pretty fast to
>> develop, as compared to something like C.
Friedrich> Again, I encourage you to got for it. You can bash C as long as you
Friedrich> like but you will find magnitudes more code and libraries written in C
Friedrich> than in Common Lisp.

Are you trying to say that the most popular programming language is the
one that will allow you to most quickly develop robust complex applications?

John Paul Wallington

unread,
Sep 27, 2001, 4:50:25 AM9/27/01
to
Friedrich Dominicus wrote:
>
> Is design really the problem? I can't see how a design can be so
> good right from the start to grow in such strange areas as the Emacs
> stuff has. Well according to Peter? Gabriel in software patterns it
> seems it's more important to plan for what he calls "piecemeal
> growth" than for anything else.

It's Richard P. Gabriel. Or at a pinch Nickieben Bourbaki :)
Peter Gabriel is a musician (Sledgehammer, Don't Give Up, etc).

--
John Paul Wallington

Alain Picard

unread,
Sep 27, 2001, 5:59:50 AM9/27/01
to
ja...@unlambda.com (James A. Crippen) writes:

> This is only good design, but that's part of the problem -- the two
> popular Emacsen suffer from a lack of design forethought.

That's an interesting statement. My take on this is rather different;
I think its _because_ emacs wasn't over-designed to start with that
it had all this wonderful life and extensibility. You know, the
"big ball of mud" thing.

I'd take CL over elisp anyday, but I wonder why people think
a re-write would be a good thing? Just speed of execution of
the lisp stuff?

What _important_ changes would YOU like to see to emacs?
Curious minds want to know.

--
It would be difficult to construe Larry Wall, in article
this as a feature. <1995May29....@netlabs.com>

Tim Bradshaw

unread,
Sep 27, 2001, 5:42:03 AM9/27/01
to
* John Paul Wallington wrote:
> It's Richard P. Gabriel. Or at a pinch Nickieben Bourbaki :)
> Peter Gabriel is a musician (Sledgehammer, Don't Give Up, etc).

Curiously enough I have this thing lying around. I don't know it's
pedigree, except that I typed this in from a printed version I made
with TEdit, so it may have bugs. I finally threw away the tapes with
my dmachine stuff (including this, probably) on only quite recently, I
suspect I will regret this one day.

--tim

--cut--
* Lisp Hacker
(Tony Simons, LEPS '87)
(Sung to the tune of *Sledge Hammer*, by Peter Gabriel)
... dedicated to the memory of DWIM, the programmer's assistant

You could have a workstation
If you'd just lay down the Vax.
You could have a floating point, floating
If you'd send your Symbolics back.
All you do is call me...
I'll do anything you need.

You could have spaghetti stacks,
Going up and down, all around the bends.
You could have a break package, breaking...
This amusement never ends!!

I want to be ... your lisp hacker.
Why don't you call me by name?
Oh let me be ... your lisp hacker.
I'll do anything you mean (Yeah! ... Yeah!)

Show me round your program,
'Cause I will be your honey bee
Buzzing round your bonmnet,
Fixing all your code where it seems right to me.
Don't mind if you can't spell it...
I'll do anything you mean.

You could have CONDitionals for CONNect;
I could change your variable names.
I could lock you in the default directory,
Catch me if you can, I just love these games!

I want to be ... your lisp hacker.
Why don't you call me by name?
You better call ... the lisp hackler.
Do what I mean for a change.
I want to be ... your lisp hacker.
Put your mind at rest.
I'm going to be ... the lisp hacker,
Let there be no doubt about it.

Lisp ... lisp ... lisp hacker.

I've kicked the habit (kicked the habit),
Shed my skin (shed my skin).
This is the new stuff (this is the new stuff),
I go dancing in (we go dancing in).
Oh, won't you call for me
And I will call for you;
Oh, won't you call for me
And I will call for you.
I've been loading the Lyric,
Been loading the Lyric.
Going to build that power,
Build, build up that power, hey! ...

Tim Bradshaw

unread,
Sep 27, 2001, 6:15:48 AM9/27/01
to
* John Paul Wallington wrote:
> It's Richard P. Gabriel. Or at a pinch Nickieben Bourbaki :)
> Peter Gabriel is a musician (Sledgehammer, Don't Give Up, etc).

Curiously enough I have this thing lying around. I don't know its

Doug Alcorn

unread,
Sep 27, 2001, 9:37:52 AM9/27/01
to
Alain Picard <api...@optushome.com.au> writes:

> ja...@unlambda.com (James A. Crippen) writes:
>
> > This is only good design, but that's part of the problem -- the two
> > popular Emacsen suffer from a lack of design forethought.
>
> That's an interesting statement. My take on this is rather different;
> I think its _because_ emacs wasn't over-designed to start with that
> it had all this wonderful life and extensibility. You know, the
> "big ball of mud" thing.

I'm not smart enought to talk about the design of either GNU Emacs or
XEmacs.

> What _important_ changes would YOU like to see to emacs?
> Curious minds want to know.

The two things I would love to pick up in emacs is multi-threaded
support and FFI. Oh, add a third thing: ability to write directly to
devices (think palm syncing).
--
(__) Doug Alcorn (mailto:do...@lathi.net http://www.lathi.net)
oo / PGP 02B3 1E26 BCF2 9AAF 93F1 61D7 450C B264 3E63 D543
|_/ If you're a capitalist and you have the best goods and they're
free, you don't have to proselytize, you just have to wait.

Friedrich Dominicus

unread,
Sep 27, 2001, 10:03:02 AM9/27/01
to
Christopher Stacy <cst...@spacy.Boston.MA.US> writes:


>
> Are you trying to say that the most popular programming language is the
> one that will allow you to most quickly develop robust complex
>applications?

No, ways beyond what I want to say. Anyway I can get a lot of
libraries for C and I expect that they have run for a while before and
are "stable". But I have the libraries and if I'm unhappy with one of
it I surely can find another implementation. So I think one can write
extremly robust code even in C while using the appropriate libraries.

Regards
Friedrich

Erik Naggum

unread,
Sep 27, 2001, 9:58:59 AM9/27/01
to
* Alain Picard

> What _important_ changes would YOU like to see to emacs?
> Curious minds want to know.

My primary concern is the educational value of a Common Lisp application
that could replace the bogus Emacs Lisp as a demonstration of what a good
Lisp can do. There is also the speed and convenience of many sorts, but
that is way below the effect of enhancing the Common Lisp systems because
they suddenly have to face up to a much larger user community who will
have all the needs that are not with the current systems, and hopefully
will be enthusiastic about a "better Emacs" and want to do stuff in it,
which will then be a real Common Lisp environment that can compile their
files and such things, not just an application that is fairly closed.

Friedrich Dominicus

unread,
Sep 27, 2001, 10:09:01 AM9/27/01
to
John Paul Wallington <j...@shootybangbang.com> writes:

> Friedrich Dominicus wrote:
> >
> > Is design really the problem? I can't see how a design can be so
> > good right from the start to grow in such strange areas as the Emacs
> > stuff has. Well according to Peter? Gabriel in software patterns it
> > seems it's more important to plan for what he calls "piecemeal
> > growth" than for anything else.
>
> It's Richard P. Gabriel.

Well sorry I wasn't sure and hadn't the book at hand. But I checked
and yes I was wrong. But the idea was to "design" for piecemeal grow
and that's the point. So Emacs was extended extremly but it's users
and so it seems that the design allowed that. So let's assume the
"original" design is more than 20 years. Well I think that's quite a
long time for software.

Regards
Friedrich