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