>>>"SJT" == Stephen J Turnbull schrieb am Thu, 2
Jul 1998 15:45:35 +0900 (JST):
ms> Many features aren't part of the Scheme
standard because they can
ms> be easily expressed within the language as it stands. True
ms> concepts are more important, and here CL is weak. I could go on
ms> about the virtues of hygienic macros, the evils of CL-style
ms> macros, especially in connection with module systems, the
ms> usefulness and beauty of call-with-current-continuation
ms> etc. etc. etc. Someone make me.
I do. Especially about the module system. As far as I know, Scheme
(even in RSR5) has no standarized module system (the package-system is
a familiar thing for CL-programmers. AFAIK, standarized Scheme offers
no such thing).
What about OO ? I always wanted to start using CLOS (the Common Lisp
Object System), but haven't had the urgent need to. But obviously,
many current Elisp applications could probably benefit from _any_ OO
SJT> Re: global options and keyword arguments
ms> However, Scheme idiomatics usually uses a parameterization
ms> mechanism to achieve what you're talking about; they're similar
ms> to a structured and thread-compatible version of dynamic binding.
SJT> Urk. I mean, URL please. :-)
Yes, I want to second that. In which way are "dynamic binding" and
keyword arguments connected ? And is there a *standarized* way for
keyword arguments in RSR ?
What I am after: this whole discussion about the benefits of Scheme
and Common Lisp has been lead a thousands time. Why should we
re-discuss very old arguments ?
And, where is the _urgent_ need for replacing Emacs Lisp with either
Scheme or Common Lisp that makes worth the work ? Sure, I would like
to have a _real_ Common Lisp as the Lisp to program Emacs in (and
that's why I have an eye on Erik Naggum's CL-Emacs project), but I am
certainly not convinced that _replacing_ the current engine with
anything else really offers any big gains. Say, we would replace the
current engine with some (modified) foo-scheme implementation, like
say guile, or the gtk-engine. Fine, now we can have some guys that
already use that foo-Scheme implement some new bar-functionality. But
what is the benefit for the current existing system ? And is it really
true that replacing Emacs Lisp with another Lisp will encourage new
users ? I doubt it, because, well, hey, here we have another lisp
engine, that mainly consists of "Emacs Lisp" (note the quotes),
because the _essential_ things for programming Emacs is _not_ the lisp
language underneath but the functionality, and this is the real part
which makes Emacs Lisp _Emacs_ Lisp (be it that the Lisp language is
Elisp, Scheme, CL ...).
And, I'm sorry to say that, but I always thought that the major
difference between Emacs Lisp and both Scheme and Common Lisp is how
binding works and that this is not a trival problem (i.e. translating
Emacs Lisp binding to CL binding). But it's been a while since I
looked inside that topic. If this is not a problem for some
translator, please correct me and tell me why/how.
ms> (Note that the reverse is not generally possible, since Common
ms> Lisp is not properly tail-recursive and does not support control
AFAIK, tail-recursion is not required by the (ANSI) CL standard. Is it
part of RSR(45) ? This would be very surprising news to me.
SJT> But _we_ only care if those features would be useful to XEmacs
SJT> running Scheme idioms emulated inside a Common Lisp substrate.
I second that. Where is the beef ?
SJT> Point is that a lot of the people who should contribute to this
SJT> discussion don't even know where to start asking questions. I
SJT> assume I'm not the only person totally ignorant of modern
SJT> programming language theory on this list. Is that assumption
Nope, as far as I am concerned this assumption pretty much applies to
Why people hate using Lisp:
"Are people suffering from parenthophobia-by-proxy, mistaking
`parens' for `parents'?" - Erik Naggum in comp.emacs.xemacs