[Top][All Lists]

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

Re: Elisp flet construct

From: Daniel Kraft
Subject: Re: Elisp flet construct
Date: Fri, 24 Jul 2009 08:38:54 +0200
User-agent: Thunderbird (X11/20070425)

Andy Wingo wrote:
On Tue 21 Jul 2009 15:10, Daniel Kraft <address@hidden> writes:

Just a little addition to the subject of extensions:  I'd very much like
to add lexical-let and lexical-let* as another set of extensions,
because this gives the possibility to use "fast" lexical variables
without the dynamic-scoping-fluid-pain.

Yes, yes. I totally agree. This allows stack allocation of the variables
as well, which can be a significant speed win (because of not making so
much garbage).

Ok, cool! And yes, if you believe there might be some code depending on the exact semantics of the cl implementation, I will implement our lexical-let with the same semantics.

I think we can't just treat inner let's like lexical-let's, because they might also bind variables for which no lexical binding is established. And those need still get their dynamic binding (tests confirmed); but that is of course not much of a problem, either.

And BTW, inner lambda expressions still bind their arguments dynamically; this special semantics is just with let, and might be some problem with its implementation and not really designed as such? Well, anyways, just do it :)

Currently, I did implement some control constructs that could be done as
macros still in the compiler directly (like prog1 or dolist) because
there I can make use of lexical helper variables; lexical-let would
allow using this feature directly from elisp (and implementing these
constructs equivalently as macros).

So, what do you think about this extension?

I think it sounds great!

Actually, there's one more advantage of implementing those control structures directly from the compiler over macros I did not think about, namely not just the dynamic binding but also that I don't do the check for void value when I know it can't be void. I'm getting suspicious that the main performance hit with elisp variables is not the fluids but rather this check, and here lexical-let does not help, unfortunatly. We would need another extension that disables this check for some variables, but I'm not sure if we should keep on adding just extensions like crazy.

But more on this later, and maybe I can supply real timings soon, too, so we really know where the most time is spent (fluids vs. void).


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]