I think it's worth considering biting the bullet, and changing all
elisp code. Surely one could write code to do much of the work? I'm
sure there are lots of idiomatic uses of () for false that could be
changed automatically. And then one would simply run an emacs for a
while with debugging features to report () if it ever got used as a
truth value, and #f if it ever got used in a list context. It would
probably take a few person-weeks to do.
That ignores user-written code, of course, but you could provide all
the tools to users too. The advantages of a Guile infested emacs
(packages, some kind of object system, dynamic loading, the ability to
create and fiddle with X widgets) would surely make up for the
inconvenience?
I don't know, maybe I'm underestimating the magnitude of the task, but
I think there are advantages in keeping Guile R4RS in this respect. I
can't see anybody caring much about case-sensitivity, but some things
are more obviously important. I like the single-namespaceness of
Scheme, for example---I can never remember what I should do in elisp if
I want to make another symbol operate as an existing function.
I agree it's a bad idea to force lots of users to change code, but
others have got away with it. Tcl/Tk between Tk3.* and Tk4.* strikes
me as a good comparison: just about all scripts needed to be changed,
but only minimally, and the improvements in Tk4.* made the change
worthwhile.
-- Bruce Stephens | email: B.Stephens@math.ruu.nl Utrecht University | telephone: +31 30 2534630 Department of Mathematics | telefax: +31 30 2518394 P.O. Box 80010, 3508 TA Utrecht | The Netherlands |