On Dec 21, 2010, at 9:38 PM, Brendan Eich wrote: > On Dec 21, 2010, at 8:17 PM, Allen Wirfs-Brock wrote: > >> However, why would you bother freezing your AST nodes in the first place. >> JavaScript has a great mechanism for "soft fields" -- it's called >> properties. You can even make your base properties non-configurable if you >> want to. But why make them non-extensible in this situation. > > 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. > > >> My sense that this is a great fear of an important segment of the JavaScript >> usage community. That people will start arbitrarily freezing or otherwise >> locking down objects resulting in systems that are much less "elastic" then >> they are today. > > 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). Regards > 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. > > /be > _______________________________________________ > es-discuss mailing list > [email protected] > https://mail.mozilla.org/listinfo/es-discuss -- Alex Russell [email protected] [email protected] [email protected] BE03 E88D EABB 2116 CC49 8259 CF78 E242 59C3 9723 _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
