"Stephen J. Turnbull" <turnbull(a)sk.tsukuba.ac.jp> writes:
Hrvoje> Lots of elisp code can run under Common Lisp almost
Hrvoje> unchanged. This is not true for Scheme.
I thought you had agreed that translators for porting old elisp can
I did, and still do.
The question is "how hard will it be for developers to change
mindsets", and from a brief review of some Scheme code I don't think
this will be that hard for me personally. XE-Scheme is going to look
an awful lot like elisp as far as I can tell, except for some changes
in conventions (like using `?' instead of `p' as the "predicate
True. This is one more area where Common Lisp is closer to elisp than
Scheme is. Of course, even with Common Lisp, *some* change of mindset
is required. For examples, global variables might have to be included
in asterisks, the language will become case-insensitive by default,
etc. I'm aware of that.
One thing that we have banged up against a couple of times recently
is the "global option-variable vs. function argument" thing. This
is especially annoying in the Mule modules, since the FSF
implementation keeps changing and it's useful to keep synch in many
cases. It would be nice to have CL-like keyword arguments. Is this
doable in a robust way in Scheme?
Probably yes, with an extension library. I don't think it has been
Would it be efficient, especially when compiled?
You must have some thoughts about that. Or are you assuming that an
eventual adoption of Guile by the FSF will make an XE-scheme a
positive advantage in porting FSF code?
This is one more problem with Michael's proposal. If we were choosing
Scheme, I would probably vote for Guile, to be compatible with many
other free software project. But Michael doesn't like Guile.
Hrvoje Niksic <hniksic(a)srce.hr> | Student at FER Zagreb, Croatia
Nostalgia isn't what it used to be.