Status Update, Elisp Compiler

Status Update, Elisp Compiler

[Daniel Kraft]

Hi Andy,

I'm off from tomorrow until Sunday, and as GSoC seems to 'officially' 
have ended, I wanted to give you a brief update on my status and plans:

Well, as to the status of the elisp compiler, you probably know -- it 
basically works, just missing are a lot of built-ins and some special stuff.

I do of course plan to continue working on it, though, no matter if GSoC 
is officially finished (hey, I did start late, so its just fair :D).  My 
definite plans to when I'm back are

1) Working further on the elisp reader I've just started (but nothing 
useful so far) to work on, as Ludo suggested I'll do it in Scheme and 
look into SILex / (text parse/lalr), but am not sure what of these I'll 
use or just hand-write.

2) Creating some kind of documentation that is more than my current, 
vague README-file (and the comments in the source code).

3) Implementing some more advanced stuff, advicing functions comes to 
mind (I've just never cared so far, I think this should be not too hard 
by creating some lambdas on the fly or the like).

4) I've not done anything yet regarding converting '() -> %nil in lists 
that are seen from elisp; I think the final conclusion was that we want 
such a conversion, and so I will do that.  But maybe I can try if it is 
reasonably possible to allow switching it off to regain performance 
without?  Maybe also allow switching off the #f -> %nil conversion for 
booleans (t = #t).

5) Other stuff that may come up at some time, like fixing bugs (of 
course), working on performance improvements (I bet a lot are still 
possible without going far) or helping with conversion to guile-emacs 
from the guile side.  This of course depends on the time I'll have to 
spend at the respective time and that might be not much during the 
autumn/winter because of university, but we'll see.  And at least a 
little should always be possible ;)

Yours,
Daniel

PS: I just remembered that the Elisp compiler still uses #f as %nil, 
although it can be switched easily at a single place.  What's the status 
of the patch fixing %nil false-ness?

-- 
Done:  Arc-Bar-Cav-Ran-Rog-Sam-Tou-Val-Wiz
To go: Hea-Kni-Mon-Pri

Re: Status Update, Elisp Compiler

[Mark H Weaver]

Daniel Kraft wrote:
> 4) I've not done anything yet regarding converting '() -> %nil in lists  
> that are seen from elisp; I think the final conclusion was that we want  
> such a conversion, and so I will do that.  But maybe I can try if it is  
> reasonably possible to allow switching it off to regain performance  
> without?  Maybe also allow switching off the #f -> %nil conversion for  
> booleans (t = #t).

I thought the point of the %nil work was to avoid the need for such
conversions.  My %nil patch (in progress) includes a fast macro for
boolean testing from lisp, which considers (), #f, and %nil to all be
false.

If it is common to test for %nil using eq, then we could provide a
special eq which treats (), #f, and %nil as equal, part of the same
equivalence class.

> PS: I just remembered that the Elisp compiler still uses #f as %nil,  
> although it can be switched easily at a single place.  What's the status  
> of the patch fixing %nil false-ness?

I'm working on an updated version of it.

     Mark

Re: Status Update, Elisp Compiler

[Daniel Kraft]

Mark H Weaver wrote:
> Daniel Kraft wrote:
>> 4) I've not done anything yet regarding converting '() -> %nil in lists  
>> that are seen from elisp; I think the final conclusion was that we want  
>> such a conversion, and so I will do that.  But maybe I can try if it is  
>> reasonably possible to allow switching it off to regain performance  
>> without?  Maybe also allow switching off the #f -> %nil conversion for  
>> booleans (t = #t).
> 
> I thought the point of the %nil work was to avoid the need for such
> conversions.  My %nil patch (in progress) includes a fast macro for
> boolean testing from lisp, which considers (), #f, and %nil to all be
> false.

Yes, of course.  I remember we discussed those issues, but think the 
last I heard of was to do, at least partially or in "some cases", a 
translation.  For booleans this is done at the moment (but only those 
that are seen from elisp, i.e. not when some boolean expression is only 
generated by the compiler).  But once again I'm open to discussion on 
this subject, and how to solve that best.

In my opinion, there are two sides to look at seperately:  One is from 
elisp to scheme, i.e. that (if nil 1 2) can be compiled directly to a 
guile internal if construct without need to add a elisp->scheme boolean 
translation.  That's what your patch will do and what's in any case a 
good idea (in my opinion).

The other side is changing back booleans from Guile internals (like = or 
others) that are seen directly from elisp.  I.e., that (= 1 2) is 
wrapped into a translator so it returns nil for false instead of #f. 
Here, for booleans translation is done at the moment, but for 
end-of-lists it is not.  I've no real opinion on if we should do 
translation here or not...

> If it is common to test for %nil using eq, then we could provide a
> special eq which treats (), #f, and %nil as equal, part of the same
> equivalence class.

See above, but I think if real-world code does not depend on that and we 
don't strive for "100% compatibility" with emacs/elisp, we could really 
just go without the scheme->elisp translation and try directly.

But as I said, I'd be happy to get other opinions again before I either 
remove the boolean translation or add one for lists.

Thanks a lot for your comments and thoughts, though!  And your patch of 
course ;)

Yours,
Daniel


-- 
Done:  Arc-Bar-Cav-Ran-Rog-Sam-Tou-Val-Wiz
To go: Hea-Kni-Mon-Pri