Re: Elisp flet construct

[Daniel Kraft]

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

Daniel

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