guile-devel
[Top][All Lists]
Advanced

[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




reply via email to

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