Re: An Acceptable Lisp

On Wed, 27 Aug 2008 17:36:09 +0000, Kaz Kylheku wrote:

On 2008-08-26, Matthew D Swank <akopa.gmane.poster@xxxxxxxxx> wrote:
On Tue, 26 Aug 2008 12:06:48 -0700, Vsevolod wrote:

What they are missing is that CL is a great language because it is
extremely well-engineered, and the existing features fit together
very nicely.
I completely agree with you.

*** Gabriel said: "I think there will be a next Lisp". (http://
www.dreamsongs.com/WIB.html. 3.6 The Next Lisp) And actually I'm
willing to put effort in the direction of "the Ultimate Lisp" and plan
to do that, when I'm ready. But, surely, my efforts won't be enough,
and, moreover, as I've mentioned above, one- man efforts can't lead to
something as finely thought-out and engineered, as well as acceptable,
as, for example, Common Lisp

Vsevolod

He also said:
"There should be a simple, easily implementable kernel to the Lisp.
That kernel should be both more than Scheme -- modules and macros --
and less than Scheme -- continuations remain an ugly stain on the
otherwise clean manuscript of Scheme.

The kernel should emphasize implementational simplicity, but not at the
expense of interface simplicity.

Simplicity is for amateurs. Or maybe for seasoned hackers who are
breaking new ground.

Production quality, N-th generation systems should emphasize reliability
and performance.

If you keep simplicity out of a kernel, it doesn't disappear. It simply
moves somewhere else, and possibly multiplies, because certain things
can't be done in a straightforward way outside of the kernel.

Well the desire for a kernel/library separation is mostly a pragmatic one
in my case. With a correct reference implementation of most of common
lisp as portable library, the leaning curve and time investment to
implement the kernel and bootstrap a proper lisp would not be so steep.

For example, despite the hand-wringing over R6RS, having the libraries
and macro-system basically available off-the shelf in psyntax makes it
easy to adopt.

Also the explicit kernel/library separation would hopefully encourage
more language experimentation, with the kernel basically providing a
common runtime in which these lisps can coexist.

Matt
.

Quantcast