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. 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). 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. 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 es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
