Re: Emacs Lisp and Guile

[Ken Raeburn]

Neil Jerram <address@hidden> writes:
> - as a guide to the Guile Emacs project on how to interface to the
>   Elisp support in libguile (notably, usage of address@hidden' and 
> address@hidden')

So, why were @fop and @bind needed in libguile anyways?  I was never
clear on that.  Is it for performance, or is Scheme not up to the
task?

> - as a working translator that could help us develop our picture of
>   how we want to integrate translator usage in general with the rest
>   of Guile.

I wonder if it's the best choice.  I don't think encouraging people to
support translation by starting with writing more C code for libguile
is wise; we'll wind up with a libguile with random primitives for
supporting translated elisp and perl and tcl and python
and....  Personally, I'd rather see that support in Scheme modules.

That issue aside, yes, I think we definitely need work in this area.
Probably another language or two as well.  Real, useful languages;
inventing another programming language so that we have another
translator doesn't do us much good if no one uses that language.

Well, that's the way it used to be.  I've been focussed enough on
Emacs in what free time I've had lately that I haven't even been
following the Guile lists, just filing them away for later.  If there
are other real translators available now, then "yay!" :-)


Neil Jerram <address@hidden> writes:
>>>>>> "Richard" == Richard Stallman <address@hidden> writes:
>          I think that both these restrictions point in the same direction: the
>          way forward is to define the primitives by compiling a preprocessed
>          version of the Emacs source code, not by trying to implement them in
>          Scheme.
>
>     Richard> What precisely is "a preprocessed version"?  What I think
>     Richard> we should do is modify the code in Emacs so that it works
>     Richard> with Scheme.
>
> What you suggest would be ideal.  I only talked about a "preprocessed
> version" because I was assuming that it might not be feasible to start
> modifying the primary Emacs codebase immediately.  If this assumption
> is wrong, so much the better.  (Would you agree with this, Ken?)

I don't think I'd use the term "preprocessed", but I suppose you could
look at it that way.

I haven't looked at how easy or hard it'll be to make Emacs C DEFUNs
produce SCM primitive procedures.  If it's easy, great.  If it's hard,
and we don't want to break the existing Lisp representations right
away, we could look for a simple, regular substitution that could be
done on the C code, or write Scheme wrappers that invoke a "call this
Lisp function" Scheme primitive procedure.

One of my concerns in that area is with mixing Lisp dynamic bindings
and Guile thread support.  If we want multi-threaded Lisp, do we pass
around some sort of environment pointer, or call thread-aware routines
to fetch current environment info?  Neil, does your code try to
support multi-threaded Lisp?


> 1. The Guile reader doesn't directly handle all Elisp syntax -- e.g. [
> ] for vectors and ? for character/integers.  The translator retrofixes
> some of these discrepancies -- e.g. it turns (what it sees as) symbols
> for the obvious alphabet characters (?a, ?b etc.) into Guile integers
> -- but not all of them.

Keeping the Elisp reader may be simplest.  I vaguely recall concluding
that cases could be constructed where the Guile reader wouldn't
distinguish things in some cases where Elisp would, but I don't
remember the details.  I think it had to do with character or number
data, or maybe "?0" type constructs.

> 2. The representation of Elisp variables doesn't allow for buffer- and
> frame-local variables.

Still an open issue in my book too.

> 3. There's no byte code interpreter.

Translating to Scheme (or Guile byte codes) is another possibility.

Ken