On Mar 20, 2011, at 9:14 AM, Mark S. Miller wrote: > On Sun, Mar 20, 2011 at 8:56 AM, David Herman <[email protected]> wrote: > > But that alone should probably not stop us from moving ahead with > concurrency. If an engine wants to provide a sequential JS, they can probably > just do so and say they're conformant with everything except for the > concurrency parts. Or maybe we can highlight the concurrency parts of the > spec and say a sequential JS doesn't have to implement them. > > I like this approach, so much that I changed the subject line ;). It gets us > back into a practice that tc39 had and dropped before I joined, defining > subsets or "profiles" of the full language as normative specs one could > conform to.
Last we checked, almost no one in TC39 wanted to take this on. ES5 strict is already a dialect of ES5 that has different runtime semantics, not just syntactic restrictions (early errors). Implementors are still rolling stones uphill to get it implemented correctly and to get errant sites evangelized and fixed. Adding more "profiles" just adds to the combinatorics, even if you try to nest profiles as subsets. More to check, more to go wrong, more work in committee now and in the field later (interop bugs), more time to complete the whole ES.next. Compound that over .next.next, etc. and you get path dependencies that can paint us into corners, magnifying mistakes. This path dependency exists no matter what, but the fewer profiles or versions, the better. Harmony of my dreams is an opt-in language "close to JS today" but with a handful of incompatible changes, almost all of them caught by early errors (typeof null === "null" is the current exception requiring more aggressive static analysis than a common implementation can afford, or all-paths test coverage). > My SES work is essentially such a profile. Some CommonJS folks are > considering requiring all CommonJS modules to be compat with ES5/strict, and > treating them as such whether they say "use strict" or not. A server-side > engine that dropped support for non-strict code could be much simpler. All of > these seem like sensible profiles to give normative names to. > > So I was wondering, why has our common wisdom become to avoid standard > profiles? Do these reasons apply to such cases? See above. I've been through this over the years in many context: X, PHIGS/PEX, *GL, MPEG, NFS. We can't avoid some amount of versioning over years and decades (even HTML is versioned by doctype). But we can certainly avoud jumping in with both feet to compound the problem (quadratically, worst case). /be
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
