Re: April CCXML: test case conflicts with ECMA rules - ISSUE-677

Chris and Dan:

Unfortunately this is a really nasty issue where pretty much we are damned if we do and damned if we don't say stuff one way or another. Because of the fact that EMCAScript has such a weird set of rules about var declaration when running a script in a single shot as apposed to more of a line by line execution model we pretty much end up in a spot where there will be material differences in how applications execute depending on the level of optimization done by the platform vendor. 

My current recommendation (personal, I still would need to get formal buy-in from the rest of the working group) is that we add the following text to section 3.3. 

-------------------------
NOTE: CCXML implementations MAY provide different levels of optimization in their ECMAScript interpreters. One such level of optimization could be a decision to either execute all the executable items in a transition as if they were a single script instead of processing them line by line as is the normal mode of execution. An example of this is the following bit of CCXML Code:

    <transition event="ccxml.loaded">
      <assign name="x" expr="3"/>
      <var name="x"/>
    </transition>

If executed line by line this would throw an error.semantic due to x being undeclared. However, if the CCXML implementation were to optimize this into a single ecmascript chunk you would get the following scriptlet:

    x = 3;
    var x;

Due to the way ECMAScript treats var declarations this is actually treated as valid EMCAScript and assigns the value of 3 to x meaning that the CCXML application would execute without raising an error. 

Application developers SHOULD NOT depend on this behavior and SHOULD instead assume code is executed line by line for maximum portability between implementations.
-------------------------

If we did this we would then have to update the IR test to work in this situation. 

Anyone got any thoughts about this approach? While I really get the idea of optimizing the CCXML applications to run faster introducing quirks like this gets messy fast and I do worry that this will end up causing some application developer confusion. 

	RJ

On Jun 7, 2010, at 4:08 PM, Dan Evans wrote:

> Chris,
> 
> As I said, your desire for efficiency is laudable.  The sad fact is that, as you point out, the transformation you make for efficiency reasons changes the semantics of the document (as compared to line-by-line interpretation), due to the unfortunate way ECMAScript defines the "var" statement.  In line-by-line, the var statement is never executed and thus the variable is never declared.  In the "efficient" transformation, ECMAScript will declare the variable even though the code branch containing the "var" statement is never executed.
> 
> I think the test should be changed, allowing the "efficient" transformation to pass, but if this idea is rejected, the CCXML CR should state that "line-by-line" interpretation semantics must be followed so that further confusion is avoided.  If the idea is accepted, the CCXML CR should make some other statement to indicate that such "efficient" transformations are acceptable but that var declarations at points other than the beginnings of scopes can be problematic.
> 
> Dan   
> On 6/7/2010 12:26 PM, Chris Davis wrote:
>> Everyone,
>> 
>> I'm seeking clarification for why this is "reject". I discussed this
>> w/Dan Evans and he agrees that the test
>> needs to be changed because as written it requires an inefficient ECMA
>> embed model to be used. To
>> quote Dan:
>> 
>> "After some more study of JS 1.5 and 1.8, some more reading of ECMA-262,
>> and a lot of examples, I managed to correct my misunderstanding of the
>> handling of 'var' statements. A 'var' statement, not inside a function,
>> anywhere in a compilation unit, results in a property definition on the
>> current scope object when the execution context is created (value
>> undefined), while the optional initializer is left behind at the point
>> of the 'var' statement, to be executed only if control flows through
>> that point.
>> 
>> I have always agreed with your desire for efficiency, so now I also
>> agree that the test should be changed. I don't think the CCXML standard
>> intends to preclude what you want to do (if it does, it should make a
>> statement to that effect), and the test just exposes an unintended
>> consequence of breaking a Javascript pgm up into smaller compilation
>> units. "
>> 
>> Dan - the above was from your 5/25 email to me. Please chime in.
>> 
>> Regards,
>> Chris
>> 
>> Baggia Paolo wrote:
>>> Chris,
>>> 
>>> we reviewed and discussed your comments on CCXML.1.0 scooping.
>>> 
>>> ISSUE-677:
>>> 
>>> Proposed Resolution: Reject
>>> 
>>> In our opinion ISSUE-677 on #798 in 8_4.txml, is correctly testing
>>> the scope chain of CCXML (in Sect 8.2.1.1).
>>> 
>>> Where the first 'if' is meant to see if the variable is resolved
>>> in the 'session' scope, then other scopes are tested as well.
>>> 
>>> After discussion your request is pending reject.
>>> 
>>> Please explicitly confirm that you accept the proposed resolution or
>>> after one week we will consider implicitly accepted the resolution. If
>>> you need clarification, please ask them very soon.
>>> 
>>> Regards,
>>> Paolo
>>> 
>>> 
>> 
>> 
> 
> -- 
> Dan Evans
> Invores Systems
> o. 800-795-2304
> c. 516-410-0169
> s. sip:5002@sip.invores.com:5062
>

Received on Thursday, 1 July 2010 12:37:04 UTC