Re: JACAL, scm

[Rob Browning]

Neil Jerram <address@hidden> writes:

> On the ()/#f issue, please ignore my naive question of a few weeks
> ago.  I've since reread Ken's and Jim's notes on the subject and
> understood the issue better.  (Note - a key part of this
> understanding, which these notes consider so obvious that they don't
> bother stating it, is the realization that conversion when passing
> values between Scheme and Elisp is not a practical option.)  My
> currently favoured approach is to:

Until and unless I have time to go back and re-read the relevant
historical information, I'm not going to participate too directly in
this topic, but on the more general level, one thing that I think is
going to be very important when addressing this issue is to clearly
outline what it is that we are trying to accomplish with respect to
elisp.  Oh, and if we have already agreed on a position, then please
let me know and just ignore the rest of this.

(When I say "guile code" below, I mean code that depends on guile's
 current behavior, i.e. '() and #f are different.  That doesn't mean
 we couldn't change that.  It's just a notational convenience.)

What are the requirements of a "correct" solution?
For example:

  - Do we require that elisp code/data be able to to coexist in the
    same process?  Will you be able to mix code? data? both?, or will
    the support be limited to a global switch you can throw at startup
    that just allows guile to behave like an elisp interpreter.

  - If we do require that the code/data be able to coexist in the same
    process, do we place any restrictions on their comingling?  Can
    elisp and scheme functions exchange data?  bidirectionally?

  - How transparent must the solution be?  Is it OK to have code
    restrictions or policies for the elisp or guile code that guile
    will be able to handle?

  - Would it be acceptable for a new emacs major version to come out
    that just doesn't support elisp anymore?  (I presume the answer is
    no, but I think we might want to publically address this question
    in our requirements since I've had people ask me why this wasn't a
    viable solution when perhaps coupled with some helper tools
    (runtime-checking or static) to aid the conversion(s).)

Until we're clear about this sort of thing, and agree on the nature of
an adequate solution, at least in broad terms, I suspect that
differing personal answers to these questions, in the absense of a
well-documented goal, may cause substantial difficulties when trying
to discuss *any* solution.

-- 
Rob Browning
rlb @defaultvalue.org, @linuxdevel.com, and @debian.org
Previously @cs.utexas.edu
GPG=1C58 8B2C FB5E 3F64 EA5C  64AE 78FE E5FE F0CB A0AD