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

Hello Paolo,
I'll try my best not to delay.
-Serguei
On Jul 7, 2010, at 10:02 AM, Baggia Paolo wrote:

> Hi,
>
> in attachment is an updated version of 8_4/8_4_A.txml as a resolution
> of ISSUE-677.
>
> May I gently ask a quick review? We are close to publish again CCXML- 
> IR
> after the resolution of all the IR ISSUES.
>
> Regards,
> Paolo Baggia
> Author of CCXML-IR Plan
> -----Original Message-----
> From: w3c-voice-wg-request@w3.org [mailto:w3c-voice-wg- 
> request@w3.org] On Behalf Of RJ Auburn
> Sent: giovedì 1 luglio 2010 18.08
> To: Dan Evans; www-voice; W3C Voice Browser Working Group
> Subject: Re: April CCXML: test case conflicts with ECMA rules -  
> ISSUE-677
>
> Folks:
>
> We discussed this on todays call and the working group would be  
> willing to approve additional text below in section 3.3  if it's  
> acceptable to the others on the list list.
>
> Quick question for Chris and Dan, what was the exact section in the  
> EMCA262 spec that defined this behavior? I would like to include a  
> reference into the spec here.
>
> -------------------------
> 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:
>
> 	<if cond="id==session.id">
> 		<assign name="application.id" expr="'1'"/>
> 		<if cond="id=='1'">
> 			<var name="id" expr="'2'"/>
>
> If executed line by line this would end executing every line in the  
> script. However, if the CCXML implementation were to optimize this  
> into a single ecmascript chunk you would get the following scriptlet:
>
> 	if(id==session.id) { // will always show as undefined
> 		application.id = '1';
> 		if( id=='1' ) {
> 			var id = '2';
> 		}
> 	}
>
> Due to the way ECMAScript treats var declarations the initial ID  
> will evaluate as undefined.
>
> Application developers SHOULD NOT depend on this behavior and SHOULD  
> instead assume code is executed line by line for maximum portability  
> between implementations.
> -------------------------
>
>
> Regarding the IR test we will send out a modified version of the  
> session scope test that should work around this issue for review  
> later today or tomorrow.
>
> 	RJ
>
> On Jul 1, 2010, at 8:34 AM, RJ Auburn wrote:
>
>> 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
>>>
>>
>>
>
>
> <8_4_A.txml>

Received on Wednesday, 7 July 2010 14:10:14 UTC