[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: Unnecessary New Closures
- From: "Evan DeMond" <evan.demond@...>
- Date: Thu, 6 Sep 2007 11:36:55 -0400
Sorry, to clarify my point - that is to say that creation of a new closure here seems like a reasonable behavior to me, and it's what I would have expected.
Evan DeMond <email@example.com> wrote:
On 9/6/07, Thomas Harning Jr. <firstname.lastname@example.org
> wrote:Unless I'm missing the point, wouldn't the simple solution here be just to use a named comparison function, bound earlier - resulting in the creation of only one closure - rather than an anonymous one?
On 9/6/07, Roberto Ierusalimschy <email@example.com> wrote:
> > I'm curious about a problem I encountered with this:
> > table.sort
(sometable, function(a, b) return a < b end);
> > If this is executed repeatedly this creates a new closure every time.
> > Because, as I understand it, this function is compiled as a prototype
> > with no upvalues, why is a new closure created every time? Seems
> > unnecessary, let alone inefficient. Would it not be possible for the
> > lua compiler to just get the reference to the function (closure) and
> > pass it?
> Unfortunately not :( The compiler has no way to know whether the
> closure is "escaping" through 'table.sort' (e.g., being stored in
> global variables), and each new closure may have its own independent
To clarify... someone could do a setfenv on the function causing its
environment to be different, even though there's no upvalues. Even if
the function/closure itself doesn't touch the environment, it can
still be used by external functions. Perhaps a method to mark a
function as being 'locked' and disable changing its environment or
using upvalues could be an option... However that is probably much
more work than its worth...
Thomas Harning Jr.