Re: Where do you want to go tomorrow?

Hrvoje> 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. Hrvoje> Not so by design. In fact, we were discussing introduction of a Hrvoje> lexically scoped `let' to elisp many times. And guess what? The Hrvoje> proposed semantics were equivalent to those used by CL -- lexical Hrvoje> scope by default, dynamic scope for special variables. Great. While I don't remember the proposed semantics, and don't necessarily agree with this, this is just as easy to implement in Scheme. 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 what Hrvoje> I meant. One important benefit in swapping the extension language would be that we could use library code not specifically written for XEmacs. There's lots and lots of library code for both Scheme and Common Lisp. Stripping down the language would mean we couldn't use much of it. If we're going to hook to a Lisp engine maintained by someone else (which we hopefully will), there's no reason to take only a part of it. Hrvoje> I will probably not be the one doing the work, and I have not a clear Hrvoje> idea of what it would take. This, however, should not mean I get no Hrvoje> vote in the discussion. I know where I want to end up. Sure. But in the end, we'll need someone who knows what it would take. I have a pretty good idea, and the effort required is only marginally different between Scheme and CL. Hrvoje> The Scheme users and implementors don't have the constraint of Hrvoje> previous implementation of Common Lisp idioms. We do, and I would Hrvoje> like us to preserve them. Sure. Let's. Hrvoje> I don't believe this. Common Lisp may not be perfect, but it's far Hrvoje> too complex to simulate correctly without a *lot* of effort. Most of it's been done. PC Scheme used to come with a substantial emulation, and we could probably hack it to make it work for us. Hrvoje> What kind of write-up? Haven't I sent you my discussion with Bruno Hrvoje> Haible? Ermh, no, you haven't ... Please do! 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> and I haven't worked with GCL much. It might be usable. Now *that*'s what I would call slow and buggy. (Took me three days just to get it installed without dumping core.) CLisp is significantly preferrable. -- Cheers =8-} Chipsy Friede, Völkerverständigung und überhaupt blabla