Subject: Re: Free ?
From: Erik Naggum <>
Date: 1997/04/16
Newsgroups: comp.lang.lisp
Message-ID: <>

* Hrvoje Niksic
| It was my misexpression.  Again, the question stands -- *why* is that so?
| Is it that complex to write a good CL implementation, so that people have
| to work full-time on it, or...?

it is not particularly hard to implement Common Lisp from Guy Steele's
Common Lisp the Language from 1984.  it is _much_ harder to implement from
Common Lisp the Standard (ANSI X3.226).  to implement a full Common Lisp
system, however, requires a lot more than just the language.  this is
really no different from other languages, except that it is useful to
implement this from inside the Lisp, and that effectively means doing more
initial work before payoff time.

| Why are the current Lisp implementations an exception?

my experience with programmers of free software and their undiminished need
for rewards for their work (only in different ways) indicates that the
incremental rewards for enhancing a language environment that leaves (or is
believed to leave) little room for personal invention preclude serious
investment in a Common Lisp system.

another "problem" is that just about anybody can "contribute" something to
those relatively simple stand-alone Unix tools, and they grow to become
quite sophisticated, but each incremental improvement is (immediately)
gratifying to the programmer.  before you can start improving on Common
Lisp, you need a few years of experience with it, and a real implementation
to boot.  more often than not, any improvements you might have in mind are
already in the language, and your adding non-standard ways to do it is only
going to hurt your users.

look how Emacs grows as an example: rarely are new language features or
fundamental functions contributed, but often packages, small incremental
improvements, etc.  (e.g., a few people ask why I don't write new packages
for Emacs.  however, they wouldn't notice that I implemented `encode-time',
`decode-time', and `format-time-string' to get rid of the annoying hacking
of `current-time-string'.  nor would they see the enhancement to the Lisp
reader and printer that allows Emacs Lisp macros to use `make-symbol' or
`gensym' correctly.  to do so, I made the first step towards packages in
Emacs Lisp, and the other day I taught `intern' to recognize keywords.
almost all of this is already in (and taken from) Common Lisp.)

I'm no longer young enough to know everything.