"use subset" introductory material

[Brendan Eich]

On Jun 30, 2008, at 9:18 PM, Allen Wirfs-Brock wrote:

> 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:

That is a warning sign. Adding more switches won't make everyone  
happy, and it will make a nightmare of a testing matrix, within a  
single implementation and among implementations.


> Brendan: I don't see these subsets as "profiles", if a profile is a  
> subset of the language that an implementation is allowed to limit  
> itself to supporting.

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. Users choosing subsets from full  
implementations do not simplify the implementation space, and too  
many subsets make a mess of the spec and its implementation.

What users -- as opposed to es3.x-discuss participants who may have  
different and seemingly contradictory goals -- have asked for these  
subsets?


> Maciej: The conditions for violating the "cautious" will be part of  
> the 3.1 specification. I actually don't understand your  
> interoperability concerns.

The complexity of multiple subset modes, or whatever they are, will  
increase the odds of interoperation bugs in the wild.


> There is only one language, the full language since every valid  
> "cautious" subset program (or any other subset, for that matter)  
> must execute identically in the full language (except for possibly  
> fewer error exceptions).  The "use subset" directive is a statement  
> of voluntary self constraint on the part of the programmer.  Of  
> course, there is no particular reason for an implementation to  
> accept the programmer's assertion regarding their self constraint.   
> So the directive also acts as authorization from the programmer to  
> the implementation that it may reject or restrict a program unit  
> according to a subset definition. A wise programmer will test any  
> such constrained program on an implementation that actually  
> enforces the subset limitations.  They would also want to test it  
> without the limitations.

There goes the QA budget :-/.

This is a recipe for testing costs driving everyone away from all but  
one mode, probably the one that's web-compatible.


> Regarding whether or not ES4 is in agreement...Before anybody can  
> agree or not to anything, there first has to be a proposal on the  
> table to consider. That's what I'm trying to put on the table.

How many proposed subsets or modes are there?


> Mark: To the degree you are agreeing with Maciej about  
> interoperability concerns, I've already addressed that. I'm trying  
> to trade-off your safety objective against compatibility issues and  
> what I see as a overall lack of consensus about what is required or  
> alternatively tolerated in a "strict mode". Making enforcement  
> optional seem to increase the possible space of compromise.
>
> Personally, I would be perfectly happy to require support for "use  
> subset cautious" but I'm concerned that it could make it harder to  
> get the consensus we need.

These statements are grounds for leaving out any subset modes from a  
standard that you hope to finish this calendar year.

/be