ES3.1 questions and issues

Allen Wirfs-Brock Allen.Wirfs-Brock at microsoft.com
Wed Mar 18 13:16:41 PDT 2009


What I'm going to put on the table is that we add the following paragraph to the end of the introduction to section 15:

Functions in this section are generally defined using algorithms that are intended to describe the result produced by each function in the absence of any implicit error conditions. These algorithms are not intended to imply the use of any specific implementation technique. The each algorithm produces its results by using a specific sequence of calls to internal methods and abstract operations.  Implementation may use other algorithms that use a different sequencing of these calls as long as an identical result is obtained in the absence of errors conditions that are not explicitly handled by the specified algorithm. If any internal method call invokes a get or set function of an accessor property that has side-effects or if an implicit error occurs the observable side-effects of a function are implementation dependent but are restricted to those that would be produced by some sequence of the internal method and abstract operation calls that would be made by the specified algorithm.

We can decide at next week's meeting whether we want to carry through with this change.

>-----Original Message-----
>From: Mark S. Miller [mailto:erights at google.com]
>Sent: Wednesday, March 18, 2009 12:36 PM
>To: Allen Wirfs-Brock
>Cc: es3.x-discuss at mozilla.org x-discuss; es-discuss
>Subject: Re: ES3.1 questions and issues
>
>Excellent! +1! That captures my concern precisely. Thanks!
>
>On Wed, Mar 18, 2009 at 12:31 PM, Allen Wirfs-Brock
><Allen.Wirfs-Brock at microsoft.com> wrote:
>>>-----Original Message-----
>>>From: Mark S. Miller [mailto:erights at google.com]
>>>Sent: Wednesday, March 18, 2009 10:27 AM
>> ...
>>>See again the language I propose for sort. While leaving the choice of
>>>sorting algorithm unspecified, I place bounds on the range of side
>>>effects it may cause even under uncooperative conditions. If we really
>>>wish to leave the precise algorithm unspecified for these others, the
>>>same qualifying language could still be applied.
>>>
>>
>> The only thing that I see in the language in your previous message
>that may not be already covered is "[if any of the [[Get]], [[Put]], or
>[[Delete]] operations fail,] the only side effects sort would cause
>would be that brought about by calling these other operations."
>>
>> Personally, I think this concept is already implicit in the sort
>algorithm and most other algorithms in the specification. However, I
>wouldn't mind making it explicit for the other array methods if we could
>also made it explicit that implementation may use alternative algorithms
>that apply [Get]], [[Put]], or [[Delete]] in possibly different
>orderings.
>>
>> Here is my first cut at a generic version of language that might
>accomplish that:
>>
>> The above algorithm is intended to describe the result produced by
>this function in the absence of any error conditions. It is not intended
>to imply the use of any specific implementation technique. The above
>algorithm produces its results by using a specific sequence of calls to
>internal methods and abstract operations.  Implementation may use other
>algorithms that use a different sequencing of these calls as long as an
>identical results is obtained in the absence of errors conditions. If
>any internal method call invokes a get or set function of an accessor
>property that has side-effects or if an error occurs the observable
>side-effects of this function are implementation defined but are
>restricted to those that would be produced by some sequence of the
>internal method and abstract operation calls in the above algorithm.
>>
>> Allen
>>
>
>
>
>--
>    Cheers,
>    --MarkM



More information about the Es-discuss mailing list