Static local variables

Fabrício Matté ultcombo at gmail.com
Mon Aug 10 16:43:33 UTC 2015


What you've described seems very similar to PHP's static variables
<http://php.net/manual/en/language.variables.scope.php#language.variables.scope.static>.
They are very nice syntactic sugar, in my opinion.
I'm just not sure if this is worth adding new syntax to the language, as
there is already a pretty standard approach:

```js
var tmp;
function intersect_vector() {
    tmp = tmp || new Vector();
    // ...
}
```

Or with CoffeeScript:

```cs
tmp = null;
intersect_vector = ->
    tmp ?= new Vector();
    # ...
```

Though, static variables would remove this boilerplate and make it easier
to reason about a given binding's scope. I believe they would be a nice
addition to the language.

/fm

On Mon, Aug 10, 2015 at 1:16 PM, joe <joeedh at gmail.com> wrote:

> 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
>
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20150810/7fc8bbab/attachment.html>


More information about the es-discuss mailing list