Re: JACAL, scm

[Tom Lord]

Making '() and #f should be a one-line change to guile-core.  Has that
changed?  I think an interesting question is:

        How much existing Guile Scheme code would be broken by making
        '() and #f, once again, the same?  How difficult would it be
        to fix that code?





  rlb asks:

  1) Is guile really still planning to be an emacs engine that can
     handle guile and elisp code simultaneously and allow tight
     interactions between the two?  To know this we need to know if
     that's something the primary emacs developers are even interested
     in these days.

The interop issue is larger than just Emacs.  For example, there are
some serious, Free Software, Common Lisp implementations to consider
as well.

There is also the issue of whether R5RS made the change to '() for any
good reasons, or whether it just happened.  The experience of most
lisp dialects is that making '() and #f the same works out nicely.
You can see that experience reflected in Scheme `and' and `or' (that
they are defined to accept and return non-booleans).  I think the
authors committee was simply out to lunch on this one.






  2) If the answer to (1) is yes, then what is really involved in
     supporting elisp, above and beyond the #f/'() issue?  Can we
     really be that emacs engine without sacrificing other things we
     care about?  For example, what effect will accomodating elisp's
     different language semantics have on potential performance
     improvements like agressive compilation.

Compilation goals are a complete red herring.  As an extension
language, Guile needs dynamic features, elisp or no elisp.  For each
compiler that is actually developed, restricted subsets of Guile can
be identified which that compiler is able to optimize.

-t