Elisp questions

[Neil Jerram]

1. You're probably familiar with the `nil == #f or empty list' issue
   (which is not actually that hard; just needs a bit of special
   handling in the functions that expect or return nil).  But what do
   you think about nil/t needing to be distinct from #f/#t?

   In our current elisp support, nil and t are symbols that evaluate
   to themselves, and so different from #f and #t.  In my view this
   distinction unnecessarily complicates interoperation between elisp
   and scheme code, and I would prefer nil/t to be equivalent to #f/#t
   when reading elisp code.

   We can't make this equivalence unconditionally, as it would violate
   R5RS, which requires `nil' and `t' to be acceptable symbol syntax
   for Scheme code.  So what I propose is a new reader option
   `language', such that

        (read-set 'language 'elisp)

   causes nil and t to be read as #f and #t.  The default value of
   this option corresponds to (read-set 'language 'scheme), of course.


2. In the same area (the reader), two other elisp reading differences
   are vectors - `#[a b c]' rather than `#(a b c)' - and characters -
   `?a' rather than `#\a'.  I think it makes sense to make these also
   dependent on (read-set 'language 'elisp).  Do you agree?


3. While working on elisp translation, I've realized that it is
   difficult (or at least not very useful) to separate the syntactic
   and language aspects of elisp from the collection of primitives
   provided by Emacs.

   In this light, what - if anything - do you expect an elisp
   translation facility to provide, apart from stuff that is aimed
   specifically at a full blown Guile-based Emacs?

   (When thinking about this, please bear in mind that elisp
   function definitions are fundamentally global - i.e. not
   module-based like Scheme procedures.)

   I think my elisp language translator now works; what is missing,
   though, is most of the primitives that Emacs provides.  Hence
   answers to this question will inform the directions that we can
   move in next.


All input gratefully received!

        Neil