New private names proposal
alex at dojotoolkit.org
Tue Dec 21 22:03:04 PST 2010
On Dec 21, 2010, at 9:38 PM, Brendan Eich wrote:
> On Dec 21, 2010, at 8:17 PM, Allen Wirfs-Brock wrote:
> For safer parallelization: see, e.g., http://www.ics.uci.edu/~franz/Site/pubs-pdf/ICS-TR-07-12.pdf, or its successor: http://www.springerlink.com/content/u16t58805r879263/ (trace-trees of linear SSA, not ASTs, but no matter).
> The pattern is pretty common in compilers these days (rustc, the self-hosted Rust compiler, has an immutable AST; McPeak & Wilkerson's Elsa/Oink tools from UCB, which we at Mozilla used at the start for our C++ static analysis work over four years ago, had an immutable AST). It's not AOP.
> We're looking into data parallel extensions to JS, not anywhere near ready to propose for standardization, but plausible now given the ability to freeze.
> This is not a relevant fear in my view. It's also kind of silly given all the open source JS libraries. If someone did over-freeze, you could stop using their library, or fork and fix it. Libraries that suck tend to die fast.
That's...an *interesting* reading of recent history.
> Mark did bring up freezing primordials recently, and I know that causes some "Dr. Freeze" fear (even on this list the other year, from Arv, IIRC).
And from me right this minute.
> Nevertheless, it's simply not credible that we on TC39 will agree to freeze primordials in any ECMA-262 edition I can foresee.
> Sometimes fear is an appropriate reaction. The lamb fears the wolf. When some overwhelming force threatens you, be afraid. But there is no Freeze Force both willing and able to take over the JS world.
> We don't need to be afraid of well-used immutability for safety and parallelization. Such filter-pipeline architectures do need weak maps or better to associate filter-specific fields with shared immutable data.
So long as the application of freezing is restricted to the uses at hand and doesn't find its way into the drinking water (ice-nine style).
> This can of course be done explicitly, but the implicit "private x" or (to a lesser extent) the transposed square-bracket access of implicit soft fields, look strictly easier to use, albeit at the price that dherman pointed out: implicit side table access using property syntax is confusing, it makes for a syntax vs. mental model conflict.
> es-discuss mailing list
> es-discuss at mozilla.org
slightlyoff at google.com
slightlyoff at chromium.org
alex at dojotoolkit.org BE03 E88D EABB 2116 CC49 8259 CF78 E242 59C3 9723
More information about the es-discuss