lua-users home
lua-l archive

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


Christian Vogler wrote:
> Reuben Thomas wrote:
> > > I have speculated, too, about the reasons why lua does not do it, and
> > > I suspect that it is a tradeoff for speed. You would need to allocate
> > > such environments on the heap, and that can be very costly.
> >
> > What's the difference between doing this in Lua and Pascal? The latter is
> > supposed to be a fairly lightweight language...
> I don't get your point. AFAIK, in Pascal, nested scopes are resolved
> at compile-time, not at runtime. The compiler can take all the time it
> wants.

Ehh... No *g*  Lua also has compile time binding.  The difference is
that Lua has function objects and locals have to live longer than the
enclosed function.

For example in: (note the lifetime of x and i)
    function mkgen(s,i)
        local x=s
        return function() x=x+i return x end

> It is not a problem of environment size and copying variables into
> it. The costs of heap allocation are primarily the time it takes to
> traverse the free list, find an appropriate chunk, split it up, and
> return the rest to the free list. If you have to do that on every
> function invocation, the costs quickly become prohibitive.

As I wrote in an earlier post, full lexical scoping with shared locals
would be cheaper than the upvalue-mechanism in 4.0a.

> In addition, I think that identifying the variables that a nested
> function actually uses would add a lot of complexity to lua. Maybe
> enough to counter its goal of keeping things simple.

I guess that's the reason (not exactly the identifying but the manage-
ment of them).  It would require some major changes in the parser and
the virtual machine (though IMHO not as much as the new code generator).

Ciao, ET.