sperber(a)informatik.uni-tuebingen.de (Michael Sperber [Mr. Preprocessor]) writes:
Hrvoje> Lots of elisp code can run under Common Lisp almost
Hrvoje> unchanged. This is not true for Scheme.
Please substantiate this. By default, for instance, `let' is
lexically scoped in Common Lisp, which is clearly incompatible with
Not so by design. In fact, we were discussing introduction of a
lexically scoped `let' to elisp many times. And guess what? The
proposed semantics were equivalent to those used by CL -- lexical
scope by default, dynamic scope for special variables.
Consequently, you would need a library of macros and procedures to
emulate/translate Emacs Lisp functionality into Common Lisp.
Quite true -- I am not denying this.
>> I personally believe a small substrate is less likely to
>> people than a large substrate.
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 Common
Lisp implementation anymore, and surely old CL buffs will complain.
I don't care. Emacs is not ANSI CL. If that was the impression I was
giving, I apologize, because that is not what I meant.
Hrvoje> My point is that choosing Common Lisp is a better idea
Hrvoje> because it is closer to Emacs Lisp.
The thing I'm having trouble is that you have not substantiated this
statement based on the nature of the three languages involved. We
really need to get down to the technical issues of this, and you
haven't addressed them. I did outline what would be needed to adapt
Scheme to Emacs Lisp. Someone should do the same for Common Lisp,
and we can compare.
I will probably not be the one doing the work, and I have not a clear
idea of what it would take. This, however, should not mean I get no
vote in the discussion. I know where I want to end up.
>> I honestly want to understand what you mean by this, but I
>> Sure, it has made sense to write Elisp libraries with constructs
>> modelled like equivalent constructs in Common Lisp. It makes
>> sense to write Scheme libraries with those constructs as well.
Hrvoje> Does it? Not for me!
Well, a lot of Scheme users and implementors disagree with you.
The Scheme users and implementors don't have the constraint of
previous implementation of Common Lisp idioms. We do, and I would
like us to preserve them.
Hrvoje> Yes, that's what we were doing with Emacs Lisp, and I
Hrvoje> really like the "poor man's common lisp" any more.
In Scheme, you could actually implement a "rich man's Common Lisp"
I don't believe this. Common Lisp may not be perfect, but it's far
too complex to simulate correctly without a *lot* of effort.
>> There must be a misunderstanding here, Hrvoje. My
"battle plan" (I
>> assume you're referring to my Web page on the subject matter)
>> *specifically* includes other options.
Hrvoje> Yes, but all the "Lisp engines" you mention are Scheme engines.
Yes, because that's what I have personal experience with. Send me a
write-up on CLisp or GCL or CMU CL, and I'll put it up.
What kind of write-up? Haven't I sent you my discussion with Bruno
Haible? Bruno's messages are an excellent case /pro/ clisp.
I don't like CMU CL (far too slow and buggy IMHO), and I haven't
worked with GCL much. It might be usable.
Hrvoje Niksic <hniksic(a)srce.hr> | Student at FER Zagreb, Croatia
HOW YOU CAN TELL THAT IT'S GOING TO BE A ROTTEN DAY:
#15 Your pet rock snaps at you.