Why not Profiles? (was: Bringing setTimeout to ECMAScript)

Brian Kardell bkardell at gmail.com
Sun Mar 20 11:55:43 PDT 2011


Im not a member of any group, but I follow closely and fwiw, I would like to
offer an outside "+1" to Brendan's comments above.  Differences and
versioning problems and things are going to arise naturally no matter how
well things are planned, better to introduce as few of them upfront as
possible (preferably none is the goal).
On Mar 20, 2011 2:17 PM, "Brendan Eich" <brendan at mozilla.com> wrote:
> On Mar 20, 2011, at 9:14 AM, Mark S. Miller wrote:
>
>> On Sun, Mar 20, 2011 at 8:56 AM, David Herman <dherman at mozilla.com>
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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20110320/ce7c3a6a/attachment.html>


More information about the es-discuss mailing list