[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: GSoC: Emacs Lisp support for GNU Guile
From: |
Neil Jerram |
Subject: |
Re: GSoC: Emacs Lisp support for GNU Guile |
Date: |
Tue, 31 Mar 2009 23:34:48 +0100 |
User-agent: |
Gnus/5.11 (Gnus v5.11) Emacs/22.2 (gnu/linux) |
This email is going to be about Guile details that the Emacs crowd
probably won't be interested in, so I've removed emacs-devel.
Clinton Ebadi <address@hidden> writes:
> There is already a working elisp->scheme translator for the interpeter
> in lang/elisp. I've poked about in it and it would be fairly
> straightfoward to port it to the VM by retargetting it to GHIL and
> replacing the @fop and @bind operators in the interpeter with a bit of
> GHIL implementing the same behavior.
>
> As a general implemention order I suggest:
>
> - Replace @fop and @bind with a GHIL fragment implementing the same
> behavior
> - Integrate the elisp->scheme translator into the VM compiler framework
> - Retarget the elisp translator from Scheme to GHIL
Agreed with all that. Also I think there is still some support in
Guile's reader code for Elisp stuff such as [...] vectors. That
should probably be removed and replaced by a proper Elisp parser
written in Scheme.
> If there is time left (the above tasks should take maybe a month,
> perhaps more) then a few more tasks would be useful as far as cleaning
> up the implementation of Guile:
>
> - Remove handling of NIL in Scheme. This special casing is, in my
> opinion, distressingly unclean. This would require adding a new
> ELISP-IF form that accepts #f/nil as false values
I'm not clear what you mean here. Can you expand on this?
> - Reimplement the basic elisp list operators in elisp/ghil rather than
> using the existing Scheme implementations
Sounds right, but do you have a specific reason?
> - [Potentially] Remove value/function slots from Guile's symbol type
> and implement the Lisp-2ness of elisp in another way
That sounds too dull for GSoC! More a matter of API continuity than
of anything technically interesting. Or am I missing something?
> - [Assuming the above is done; if not ((fref SYMBOL) ...) works
> already] Implement a convenient way to call elisp functions from
> Scheme. Something like (funcall SYMBOL ...)
I thought that was already possible... yes, using elisp-function,
use-elisp-file or use-elisp-library.
Regards,
Neil