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
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.
The relationship between ADsafe and Cajita is complex and evolving,
and should be discussed in a separate thread.
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.
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" ;).
[+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
[+es4-discuss]
On Wed, Feb 20, 2008 at 4:59 PM, Mike Samuel wrote:
People who know Unicode are dangerous ;). How did you type that?
Syntactic subsetting is implied but is not the main intent.
We need to consider each individually. Ideally, once relationships are repaired
The relationship between ADsafe and Cajita is complex and evolving, and should be discussed in a separate thread.
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.
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" ;).
[+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