[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Elisp flet construct
Re: Elisp flet construct
Fri, 24 Jul 2009 08:38:54 +0200
Thunderbird 126.96.36.199 (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
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
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).
To go: Hea-Kni-Mon-Pri
Re: Elisp flet construct, Andy Wingo, 2009/07/23