>>>"Hrvoje" == Hrvoje Niksic schrieb am 02 Jul 1998
Hrvoje> sperber(a)informatik.uni-tuebingen.de (Michael Sperber
Hrvoje> [Mr. Preprocessor]) writes: Lots of elisp code can run under
Hrvoje> Common Lisp almost unchanged. This is not true for Scheme.
> Please substantiate this. By default, for instance, `let'
> lexically scoped in Common Lisp, which is clearly incompatible
> with Emacs Lisp.
Hrvoje> Not so by design. In fact, we were discussing introduction
Hrvoje> of a lexically scoped `let' to elisp many times. And guess
Hrvoje> what? The proposed semantics were equivalent to those used
Hrvoje> by CL -- lexical scope by default, dynamic scope for special
Excuse me, Hrovje, where is this an argument for "not so by design" ?
We're arguing about probably having to change a lot of _existing_
Emacs Lisp code and not about the introduction of a new `lex-let'.
> Consequently, you would need a library of macros and procedures
> emulate/translate Emacs Lisp functionality into Common Lisp.
Hrvoje> Quite true -- I am not denying this.
Hrvoje> I believe clisp is small enough, especially if we remove the
Hrvoje> parts we don't need.
> This, however, means that Emacs CLisp won't be a standard
> Lisp implementation anymore, and surely old CL buffs will
Hrvoje> I don't care. Emacs is not ANSI CL. If that was the
Hrvoje> impression I was giving, I apologize, because that is not
Hrvoje> what I meant.
But, what is then the point of substituting Emacs Lisp with another
non-sense Lisp ? I don't get it. If we substitute Emacs Lisp with
something else, I would like to have an ANSI CL system (preferred) or
a state-of-the-art RSR5-Scheme system. And, my favourite, if somebody
wants to replace the existing lisp engine, go for a language engine
that allows support for Emacs-Lisp, Common Lisp and Scheme (and perl
or tcl, perhaps). Is here somebody how followed the discussions on the
Lisp-OS/VM-Mailing Lists ? All arguments which came up here have been
discussed there already. With the following results: those who liked
Scheme, went to do some stuff in Scheme. And those, who wanted a CL
system, used CL. Guess what: I have not seen coming anything useful
out of the efforts.
Hrvoje> a clear idea of what it would take. This, however, should
Hrvoje> not mean I get no vote in the discussion. I know where I
Hrvoje> want to end up.
Please, say so, loud and clearly. I just said where I would like to
end up: with a Lisp engine supporting any flavour.
Hrvoje> I don't like CMU CL (far too slow and buggy IMHO), and I
Hrvoje> haven't worked with GCL much. It might be usable.
If you really think CMUCL is too slow and too buggy, you won't want to
consider GCL. (BTW: I haven't used CMUCL 18a, only the old 17f
version. On Linux, this old version certainly was slow [no high speed
garbage collection] and contained some bugs [especially the ffi], but
I never encountered any bugs on a grown-old 17f on Sun Systems. Note
that currently most development on CMUCL seems to be done on Intel
systems, so the situation is much likely to change [or has already
improved]. With clisp I had had problems in the past of even compiling
it under Linux.)
Why people hate using Lisp:
"Are people suffering from parenthophobia-by-proxy, mistaking
`parens' for `parents'?" - Erik Naggum in comp.emacs.xemacs