Multiple LISP's?

429 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