Static local variables

[joe]

I've been hesitant to bring up this idea, because even though I use it
extensively as a language extension in my transpiler I'm not sure it is
normatively correct.

When I started my first major JS project four or five years ago, I noticed
I was doing this a lot:

    var intersect_vector_tmp = new Vector();

    function intersect_vector(v1, v2) {
        var tmp = intersect_vector_tmp .load(v1).sub(v2);
        //do something
        v1.add(tmp);
    }

Basically, I was doing the following transform:

*  For each static local variable...
    1. Build unique name from hash of lexical scope chain
    2. Rename variable (along with references to it in the local hoisted
scope).
    3. Move it to module/global namespace.

I ended up implemented this in my compiler as a sort of C-style static
local variable.  Thus, the example above became:

    function intersect_vector(v1, v2) {

        static tmp = new Vector();

        tmp.load(v1).sub(v2);
        //do something
        v1.add(tmp);
    }

There are, obviously, a great many problems here, starting with the fact
that the variable's initializers are being evaluated outside of the scope
they were declared in.  Unfortunately this pattern can be hard to avoid for
high-performance code, so much so that if the transformation is done by
hand you end up with a great deal of clutter.  This is especially annoying
when dealing with classes, as the following file (with the statics
transpiled out) illustrates:

https://github.com/joeedh/fairmotion/blob/master/examples/vectormath_static_illustration.js

This becomes a real pain after a while.  At one point I tried using shared
object pools, but found that this didn't remove very much clutter because,
in practice, each function had to have its own pool (usually one for each
type of temporary object it uses).  This really does boil down to a lack of
support for local stack allocation of temporary objects.

Anyway, I just thought I'd put this out there. Who knows, maybe someone
will invent perfect escape analysis for temporary const objects, and we
won't need hackish language extensions such as this.

What do people think? Too many normative problems?

Best,
Joe
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20150810/76e1b496/attachment-0001.html>