Resending after adding myself to es4-discuss.<br><br><br><div><div><span class="e" id="q_11839b9a6e554722_1"><span class="gmail_quote">On 20/02/2008, <b class="gmail_sendername">Mark Miller</b> &lt;<a href="mailto:erights@gmail.com" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">erights@gmail.com</a>&gt; wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">

<br> [+es4-discuss]<br> <br><br> On Wed, Feb 20, 2008 at 4:59 PM, Mike Samuel wrote:<br> &gt; On 20/02/2008, Mark Miller wrote:<br> &gt; Since a language is commonly defined as the set of strings produced by a<br> &gt; particular grammar, is this equivalent to<br>

 &gt;<br> &gt;&nbsp;&nbsp;&nbsp;&nbsp; JSON ⊂ ADsafe ⊂ Cajita ⊂ Caja ⊂ ES3 ⊂ ES4<br> <br> <br>People who know Unicode are dangerous ;). How did you type that?<br> <br> Syntactic subsetting is implied but is not the main intent.<br> <br><br>
 <br>
 &gt;&nbsp;&nbsp;or does your inequality imply some semantic relationship such as:<br> &gt;&nbsp;&nbsp;&nbsp;&nbsp; The same string evaluated in an expression context produces an<br> &gt; &quot;equivalent&quot; result assuming no exceptions thrown.<br>

 &gt;&nbsp;&nbsp;&nbsp;&nbsp; The same string evaluated in a statement context has &quot;equivalent&quot;<br> &gt; side-effects assuming no exceptions thrown.<br> &gt;&nbsp;&nbsp;?<br> <br> <br>We need to consider each individually. Ideally, once relationships are repaired<br>

 <br> 1) Any legal JSON text can be evaluated as a program in any of the<br> languages to its right.<br> * This had not been the case for JSON / ADsafe because of the severity<br> of the ADsafe blacklist, which Crock has now repaired.<br>

 * This is not the case for JSON / (Cajita or Caja) because of Caja&#39;s<br> current prohibition on names ending in double underbar. However,<br> Caja&#39;s restriction is an implementation artifact of the need to<br> translate Caja to ES3. Given appropriate changes in ES3.1, we may be<br>

 able to remove that restriction from Caja/Cajita-on-ES3.1/ES4.<br> * Could you explain the difference in Unicode newline rules that<br> prevents JSON from being syntactically a subset of ES*? Thanks.</blockquote></span></div>
<div><br>
There&#39;s three problems according to my reading of <a href="http://www.ietf.org/rfc/rfc4627.txt" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">http://www.ietf.org/rfc/rfc4627.txt</a> but only the first is directly related to syntax:<br>
<br>(1) There are JSON programs that are not valid ES programs.<br>
The JSON program [ &quot;\u2028&quot; ] where the unicode escape is replaced with its literal equivalent is valid according to JSON since the set of characters that can appear in a string unescaped is<br><pre style="margin-left: 40px;">
unescaped = %x20-21 / %x23-5B / %x5D-10FFFF</pre>but ES does not allow codepoint 0x2028 or 0x2029 to appear unescaped in a string since they are newline characters.<br><br>(2) There are JSON programs that have the same text as ES programs but different meaning.<br>

ES262 says that all format control codepoints, such as 0x200C, should be stripped out of the program in a pre-lex phase.&nbsp; This is not consistently implemented:<br>&nbsp;&nbsp;&nbsp; eval(&quot;&#39;\u200c&#39;.length&quot;) == 0 on SpiderMonkey, and 1 on most other interpreters<br>

JSON does not strip these characters out, so they are treated as significant.<br><br>(3) There are JSON programs that can be parsed to ES but that cannot be serialized back to JSON without losing track of where info was lost.<br>

JSON does not put any limits on numbers, but ES does.&nbsp; ES will treat 1e1000 as Infinity.&nbsp; Since JSON does not have a value Infinity, it is unclear how to implement toJSON(fromJSON(&quot;[1e1000]&quot;)).<br><br>cheers,<br>
<span class="sg">
mike<br>&nbsp;</span></div><div><span class="e" id="q_11839b9a6e554722_5"><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> * There is currently a conflict between JSON and ES3 regarding Unicode<br>

 Cf characters. I believe this is repaired by ES4. I do not know, but I<br> hope that this is repaired in ES3.1 as well. If so, then Caja and<br> Cajita will inherit this repair.&nbsp;</blockquote><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">

 * The legal JSON string &#39;{&quot;__proto__&quot;: 3}&#39; cannot be correctly<br> evaluated as a JavaScript program on Firefox. In fact, it cannot even<br> be correctly unserialized by a JSON library. I don&#39;t think this can be<br>

 repaired. This is an example of a subset gotcha in theory that<br> probably makes no practical difference to anyone.<br> <br> 2) The relationship between ADsafe and Cajita is complex and evolving,<br> and should be discussed in a separate thread.<br>

 <br> 3) Cajita is, and should remain, a statically checkable subset of<br> Caja. Given a Caja program, one can statically determine whether it is<br> a Cajita program. Any valid Cajita program is a valid Caja program of<br>

 the same meaning. Cajita uses the Caja runtime.<br> <br> 4) Caja is (ideally) a fail-stop subset of ES3. The &quot;ideally&quot; is<br> modulo the gotchas listed in the Caja spec, some of which will<br> hopefully be repaired as Caja and ES3.1 evolve. As the Caja spec<br>

 explains, &quot;fail-stop&quot; is a bit broader than &quot;assuming no exceptions<br> thrown&quot;. It is &quot;assuming no failures are reported&quot;. The difference is<br> exactly that, in order to support the JavaScript feature-test pattern,<br>

 reading an absent property reports failure by returning undefined<br> rather than throwing an exception. Properties not enabled by the Caja<br> whitelist can thus be considered absent to Caja without violating<br> either the fail-stop notion or normal JavaScript expectations.<br>

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

 <br><br> --<br> <br>Text by me above is hereby placed in the public domain<br> <br>&nbsp;&nbsp;Cheers,<br>&nbsp;&nbsp;--MarkM<br> <br> --~--~---------~--~----~------------~-------~--~----~<br> You received this message because you are subscribed to <a href="http://groups.google.com/group/google-caja-discuss" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">http://groups.google.com/group/google-caja-discuss</a><br>

 To unsubscribe, email <a href="mailto:google-caja-discuss-unsubscribe@googlegroups.com" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">google-caja-discuss-unsubscribe@googlegroups.com</a><br> -~----------~----~----~----~------~----~------~--~---<br>
 <br> </blockquote>
</span></div></div><br>