"use subset" introductory material

[Mark S. Miller]

On Mon, Jun 30, 2008 at 11:49 PM, Brendan Eich <brendan at mozilla.org> wrote:
> 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.

I agree with this. While there are many ideas for possible subsets
floating around (Caja, Cajita, ADsafe, Jacaranda, Capsol), I think it
is *really important* to reduce the number the standardized subsets
down to the absolute minimum we can agree on. Within the ES3.1/ES4
timeframe, the subsets we're talking about standardizing are exactly
the same as those we have been discussing. We are only proposing a
trivial renaming to clarify the distinctions we've all already been
discussing, and to leave room open for the future definition of other
subsets.

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. 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?

Of the above desired subset relationships, the problematic one is the
last bullet above. 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.



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

Aren't you, Crock, and the rest of us vigorously agreeing? The point
of these subsets isn't "profiles". It is the benefits that following
from knowing (or enforcing) that the execution of particular program
units are constrained to be within useful subsets of the language. The
motivation should be clear: The language as a whole is a mess.
However, various subsets of the language, like ES4 strict for example,
have much better properties. For code constrained to execute according
to one of these subsets, the semantics of this code can often
explained using a simpler theory than needed to explain the semantics
of the full unconstrained language. For example, scoping in ES4 strict
without "with" could be explained in terms of static scope analysis
without the concept of a dynamic scope chain. Simpler formalism
enables better metaprogramming tools.


> Users choosing subsets from full
> implementations do not simplify the implementation space,

Agreed. That's not the point.


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


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


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

Agreed.


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

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.


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

Until/unless we resolve the strict vs cautious incompatiblities, there's:

* ES3.1 < ES4
* ES3.1 cautious < ES3.1
* ES4 strict < ES4
* ES4 cautious < ES4
* ES3.1 cautious < ES4 cautious

If we do resolve these incompatibilities, then it reduces to the
earlier four-bullet list above.

But for the outer parens and the subset declaration itself, JSON is in
fact a subset of all the above languages. Whether the "use subset X"
directive is able to express this or not, I don't really care. But it
remains a vivid example of the utility of knowing that code is
constrained to a subset of the language with a simpler and less
dangerous semantics.



-- 
    Cheers,
    --MarkM