"use subset" introductory material

[Brendan Eich]

On Jul 1, 2008, at 10:55 AM, Mark S. Miller wrote:

> If the ES4 and ES3.1 folks can agree on their respective meanings of
> the subset named "strict", such that
>
> * ES3.1 < ES4
> * ES3.1 strict < ES3.1
> * ES4 strict < ES4
> * ES3.1 strict < ES4 strict
>
> then we'd only need the two subset names needed for these
> distinctions. Even then, making the syntax change from
>
>    "use strict";
>
> to
>
>    "use subset strict";
>
> still seems like a good idea to me.

I'm not in favor of uniformity over usability, especially if for  
whatever reason we do not add subsets to future standards. 'use  
strict' is short and sweet, familiar from Perl and other languages,  
and IMHO much better than the pedantic (sorry, but it fits :-P) 'use  
subset strict'.

If we do standardize more subsets, we can cross the longer bridge then.

This is a small point, but it highlights tension between usability  
("read" as well as "write", I claim) and "completeness" (for want of  
a better word). Anyway the ES4 pragma syntax prefers one-word terms,  
although there have been ad-hoc two-word forms.


> At the last F2F, Lars and Brendan
> raised the possibility that they might like to define stricter modes
> in successors of ES4. The notion of named subsets would seem to
> accommodate that. Brendan & Lars, in the absence of named subsets, how
> would you introduce such stricter modes in that future? What would you
> propose?

Mainly what I recall we talked about at that meeting was simply the  
idea that (ESn+1 strict could be < ESn strict) -- that one could make  
strict mode stricter over time. Adding 'use stricter' was not a  
serious proposal, IIRC.

I recall also we did not want strict mode to be part of the MIME- 
typed version parameter, or the version to be selectable by a pragma.  
So the only issue was upgrading from ESn to ESn+1 and facing a  
stricter strict mode. Standard mode would be highly backward  
compatible, with unpredictable and slow obsolescence leading to some  
amount of deadwood shedding over time -- maybe.


> Of the above desired subset relationships, the problematic one is the
> last bullet above.

To wit:

* ES3.1 strict < ES4 strict

Agreed.


> The outstanding disagreements are variable arity
> strict functions and "with". Hopefully we can resolve these in Oslo.
> In the meantime, to avoid stepping on each other's toes, we've renamed
> "ES3.1 strict" to "cautious". That's all that's going on. I'm
> surprised there's such a fuss.

Probably you are right, and there's too much fuss. On the other hand,  
we now have a straw "cautious" mode to argue about. It would be  
better to get agreement on strict before expending the effort and  
seeming to up the "subset violation" ante (not entirely a matter of  
perception; every documented and jargonized change tends to take on a  
life of its own, and fight for survival).


>> That's my point -- profiled standards may pretend that
>> implementations can pick and choose among profiles to support, but on
>> the web's winner-take-all network effects force every implementation
>> to agree on the full standard.
>
> Aren't you, Crock, and the rest of us vigorously agreeing?

I am pretty sure we agree on a lot -- more than you might think ;-).  
But let's be clear on what I am arguing against: multiple subsets  
taking precious standards-making bandwidth, adding to the complexity  
(even temporarily) of the work within ES3.1 and ES4, and of course  
between them.

Yes, subsets are useful -- so useful there are a great many out  
there. No, we should not try to standardize them all, or invent  
overlong syntax with which to select them, if we are only talking  
about strict mode.


>> Users choosing subsets from full
>> implementations do not simplify the implementation space,
>
> Agreed. That's not the point.

But that's my point, one of them: the specs are in large part for the  
benefit of implementors, to make interoperation a more likely  
outcome. Since web browser implementations have to handle the whole  
language (and then some: quirks and deprecated features may remain  
for a long while), the spec should not overreach for subsets at the  
expense of clarity, compatibility, and completeness.

Complexity due to unnecessary subset additions, or mooting, or future- 
proofing, is therefore not welcome, all else equal -- IMHO.


>> and too
>> many subsets make a mess of the spec and its implementation.
>
> Agreed. Let's continue to try to reconcile "strict" and "cautious".
> And let's avoid adding any more choices to the menu in the ES3.1/ES4
> timeframe.

I agree completely -- good to read this.


>> What users -- as opposed to es3.x-discuss participants who may have
>> different and seemingly contradictory goals -- have asked for these
>> subsets?
>
> To my ears, I've been quite amazed at how convergent our thinking has
> been on these matters. What disagreements and contradictions do you
> see among the es3.x-discuss participants?

I was quoting Allen there. He wrote (two messages up on this thread):  
"This is an interesting exercise because I'm trying to find a path  
that is tolerable for a number of different individuals who seem to  
have different and sometimes seemingly contradictory goals: ...." I  
didn't think he was writing only about ES4 participants. Among ES3  
participants, is there strong agreement on disabling automatic  
semicolon insertion in 3.1's strict mode?


>> This is a recipe for testing costs driving everyone away from all but
>> one mode, probably the one that's web-compatible.
>
> Anyone interested in software quality is horrified by the current
> state of JavaScript, and should welcome the constraints enforced by a
> strict or cautious subset.

I hope we can standardize a strict mode that increases software  
quality. That's why I'm concerned, along with Lars, about strict mode  
ruling out syntax (such as automatic semicolon insertion) that much  
JS on the web relies on without noticeable quality problems. We want  
a strict mode that will be both useful and usable at low incremental  
('use strict' per block or script) cost.

BTW, we've had arguments in the past with Ajax library authors, who  
write high quality code, about things like Firefox 1's "deprecated  
with" warnings. Not everyone agrees with your idea of what is  
horrible, and observed software quality problems do not correlate so  
clearly to all those 3.1-unstrict bêtes noires.

/be

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.mozilla.org/pipermail/es-discuss/attachments/20080702/34d866f4/attachment-0002.html