[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: JACAL, scm

From: Neil Jerram
Subject: Re: JACAL, scm
Date: 01 Oct 2001 20:54:46 +0100
User-agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.5

>>>>> "Thien-Thi" == Thien-Thi Nguyen <address@hidden> writes:

    Thien-Thi> obguile: i encourage anyone interested in reader
    Thien-Thi> extensions to read the archives and coordinate efforts
    Thien-Thi> w/ Daniel Skarda.  see, too, recent work by Neil Jerram
    Thien-Thi> on an elisp transformer.

Thanks for the mention.  I'm sorry to say that my elisp effort has
been slightly set back by my laptop not liking the sea air on holiday,
but I hope to be able to recreate the lost work soon (and commit it
this time!).

Perhaps I'm over optimistic, but I think that, by putting together Ken
Raeburn's, Keisuke's and my/Mikael's work we could make a Guile-based
Emacs quite soon (say, by the end of next year).  I also like the idea
of providing bits of emacs function in modularized form in Guile,
which perhaps chimes with Tom's application framework angle.  The
tricky issues here IMO are to do with code and release cycle

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:

- read `()' and `nil' as #f if the reader is currently reading Elisp
  (but not in the Scheme case, of course)

- make the evaluator, when evaluating Elisp, immediately convert any
  naked #eol result value to #f

[I use `#eol' to denote the value that Guile Scheme reads for `()'.]

- make the Elisp `cons' understand #f as its second argument (er..,
  which it does anyway, so I guess this last point doesn't really

I think this is simpler than Jim's proposal, and has the advantages

- there is no need to complicate `eq?' and `eq'

- proper Scheme and Elisp lists have the same underlying structure,
  and are always terminated with #eol.

This doesn't solve the problem of the Elisp that wants to call a
Scheme proc and distinguish between the proc returning #f and the proc
returning #eol, but I don't think that's a very important problem.
You can always wrap the Scheme proc in Scheme to give it an interface
that is useful for Elisp.

(I don't have the URL for Jim's notes here, but you can find them by
starting from and going via Ken Raeburn's

Best regards,

reply via email to

[Prev in Thread] Current Thread [Next in Thread]