[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Status Update, Elisp Compiler

From: Daniel Kraft
Subject: Re: Status Update, Elisp Compiler
Date: Sun, 06 Sep 2009 18:24:40 +0200
User-agent: Thunderbird (X11/20070425)

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

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 ;)


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

reply via email to

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