>>>> "Hrvoje" == Hrvoje Niksic
> If we're going to hook to a Lisp engine maintained by someone
> (which we hopefully will), there's no reason to take only a part of
Hrvoje> Well, there are reasons such as size, speed, efficiency etc.
And there's maintainability.
Hrvoje> The Scheme users and implementors don't have the constraint
Hrvoje> of previous implementation of Common Lisp idioms. We do,
Hrvoje> and I would like us to preserve them.
> Sure. Let's.
Hrvoje> If we choose Scheme, I don't see the point.
The main idea to programming in Lisp-like languages has always been
that you tailor the programming idioms you use to the problem at hand,
and implement them using macros and higher-order functions.
Essentially, you embed your own "little language" into Lisp. If
there's any one Lisp programming idiom, that's it.
This doesn't happen much in Emacs Lisp because the language is not
expressive enough. It happens all the time in Common Lisp as well as
in Scheme. Scheme 48 comes with an embedded version of Icon and one
of Dylan. scsh comes with an embedded version of awk. MzScheme comes
with essentially an embedded version of Java etc. etc. etc. This all
makes perfect sense. I'm quite sure similar things exist in CL
implementations. (The CL *standard* specifies embeddings of Standard
Lisp, Franz Lisp, Lisp 1.5, Fortran, ..., ...)
Hrvoje> I don't like CMU CL (far too slow and buggy IMHO),
> Actually, CMU CL produces pretty much the fastest CL code around.
> Unfortuntately, it only works on very few architectures.
Hrvoje> Exactly. And it's almost impossible to compile. And it's fucking
Hrvoje> huge. Etc.
I didn't mean to advocate it too much. CMU CL occasionally shows up
in language benchmarks, and does pretty well there. If and when it
Hrvoje> Clisp doesn't have a native compiler, but it would
Hrvoje> probably serve our purposes much better.
Hrvoje> I'll forward my exchange with Bruno to the list.
Cheers =8-} Chipsy
Friede, Völkerverständigung und überhaupt blabla