[Caja] Re: Fwd: proposed relationships of Secure EcmaScript, ES3.1, and ES4.

Mark Miller erights at gmail.com
Wed Feb 20 17:34:30 PST 2008


[+es4-discuss]

On Wed, Feb 20, 2008 at 4:59 PM, Mike Samuel wrote:
> On 20/02/2008, Mark Miller wrote:
> Since a language is commonly defined as the set of strings produced by a
> particular grammar, is this equivalent to
>
>     JSON ⊂ ADsafe ⊂ Cajita ⊂ Caja ⊂ ES3 ⊂ ES4

People who know Unicode are dangerous ;). How did you type that?

Syntactic subsetting is implied but is not the main intent.


>  or does your inequality imply some semantic relationship such as:
>     The same string evaluated in an expression context produces an
> "equivalent" result assuming no exceptions thrown.
>     The same string evaluated in a statement context has "equivalent"
> side-effects assuming no exceptions thrown.
>  ?

We need to consider each individually. Ideally, once relationships are repaired

1) Any legal JSON text can be evaluated as a program in any of the
languages to its right.
* This had not been the case for JSON / ADsafe because of the severity
of the ADsafe blacklist, which Crock has now repaired.
* This is not the case for JSON / (Cajita or Caja) because of Caja's
current prohibition on names ending in double underbar. However,
Caja's restriction is an implementation artifact of the need to
translate Caja to ES3. Given appropriate changes in ES3.1, we may be
able to remove that restriction from Caja/Cajita-on-ES3.1/ES4.
* Could you explain the difference in Unicode newline rules that
prevents JSON from being syntactically a subset of ES*? Thanks.
* There is currently a conflict between JSON and ES3 regarding Unicode
Cf characters. I believe this is repaired by ES4. I do not know, but I
hope that this is repaired in ES3.1 as well. If so, then Caja and
Cajita will inherit this repair.
* The legal JSON string '{"__proto__": 3}' cannot be correctly
evaluated as a JavaScript program on Firefox. In fact, it cannot even
be correctly unserialized by a JSON library. I don't think this can be
repaired. This is an example of a subset gotcha in theory that
probably makes no practical difference to anyone.

2) The relationship between ADsafe and Cajita is complex and evolving,
and should be discussed in a separate thread.

3) Cajita is, and should remain, a statically checkable subset of
Caja. Given a Caja program, one can statically determine whether it is
a Cajita program. Any valid Cajita program is a valid Caja program of
the same meaning. Cajita uses the Caja runtime.

4) Caja is (ideally) a fail-stop subset of ES3. The "ideally" is
modulo the gotchas listed in the Caja spec, some of which will
hopefully be repaired as Caja and ES3.1 evolve. As the Caja spec
explains, "fail-stop" is a bit broader than "assuming no exceptions
thrown". It is "assuming no failures are reported". The difference is
exactly that, in order to support the JavaScript feature-test pattern,
reading an absent property reports failure by returning undefined
rather than throwing an exception. Properties not enabled by the Caja
whitelist can thus be considered absent to Caja without violating
either the fail-stop notion or normal JavaScript expectations.

As for the subsetting relationship between ES3.1 and ES4, I believe
that everyone involved in both efforts intends this relationship to
hold. I hope they succeed. Hmmm. I suppose "they" is now "we" ;).

-- 
Text by me above is hereby placed in the public domain

 Cheers,
 --MarkM



More information about the Es4-discuss mailing list