>>>>> "Reggie" == Reggie Perry <Reggie.Perry(a)digital.com> writes:
Reggie> I am confused about your comment about DEFVAR. Since in elisp
Reggie> all variables are dynamic and get shadowed by let, it is not
Reggie> clear to me how this is different from how common lisp treats
Reggie> special variables.
I'll try to elaborate, even though I don't know the full story:
The argument Hrvoje and I were having was about how hard it is to
migrate code to a Lisp where let bindings work lexically. Since in
Common Lisp bindings are lexical by default, there's a clear dichotomy
between Elisp and Common Lisp. The dichotomy is the same between
Elisp and Scheme, even though the pragmatics of the migration are
somewhat different. (In Scheme, you would actually replace the
binding and use of dynamically bound variables rather than adding a
Someone (Hrvoje?) proposed that we change the semantics of let to work
like in Common Lisp, with DEFVAR functioning as the "special"
declaration for dynamic binding. This would entail changing existing
Emacs Lisp code in an incompatible fashion. The change has not been
done or scheduled yet, if I understand correctly.
The way I understood your comment was that you claimed that Common
Lisp works "just like it happens in elisp now". This is clearly not
Reggie> Also I didn't know XEmacs had any read macros at all so I am
Reggie> really confused that they have the #+ and #- read macros.
We do, we do, but they're bad juju, mainly because we must be able to
distribute compiled code. #+ and #- encourages people to write code
that compiles differently on different configurations and
architectures. However, we want the same compiled code to work across
that. (Note this is not part of the language discussion at all. #+
and #- are implementable in Scheme as well, but would be an equally
bad idea there.)
Reggie> While I agree with your arguments about scheme48, note that it
Reggie> does not run on Alpha, and seems to be a non-trivial port
Reggie> since there are still some 32 bit assumptions hanging
Actually, these two issues are intimately connected, and Richard
Kelsey is working on addressing both of them. It is currently a
problem, however, no question.
Reggie> Also the module system is a little obscure unless one is
Reggie> comfortable with SML.
Also, the Common Lisp module system is a little obscure unless one is
comfortable with Common Lisp :-)
Reggie> I was sort of hoping that it would be easy to point to
Reggie> Graham's common lisp book and Keene's CLOS book or Dybvig's
Reggie> scheme book and say that the base language looks just like
The only case where we won't be able to do this is if we provide a
stripped-down Common Lisp, which I consider a bad idea.
In any case, XEmacs hackers will need to refer to libraries not in the
base language anyway to achieve anything remotely useful. The
trade-offs are different in both cases, of course.
Reggie> The scheme48 module system complicates that some, but if
Reggie> your plan is to attempt to use scheme48 as the XEmacs engine,
Reggie> I certainly would not complain. Its a great system.
I'm glad we agree that both existing Scheme engines and existing
Common Lisp engines would make viable substrates for XEmacs. The fact
that we have a choice between two good systems means that the end
result will be an improvement, no matter what we do. (At least as
long as we actually do do it.)
Reggie> I would note though that if you look at extended scheme48, it
Reggie> certainly has a lot of features in it that are in common lisp.
I would argue that its features are usually a significant improvement
over Common Lisp. I'll write about module systems in a separate
Reggie> The only thing missing is CLOS. This is part of the reason I
Reggie> chose to study the genuine article (common lisp) more. :-)
CLOS is definitely neat. However, there are numerous object systems
for Scheme, one called TinyCLOS. I'll send a reference if I stumble
upon it ... (I find myself in need or want for OOP very rarely.)
Reggie> [2 <application/ms-tnef>]
What's this, BTW?
Cheers =8-} Chipsy
Friede, Völkerverständigung und überhaupt blabla