An array destructing specification choice

Andreas Rossberg rossberg at google.com
Mon Nov 7 03:04:36 PST 2011


On 5 November 2011 19:55, Brendan Eich <brendan at mozilla.com> wrote:
> On Nov 5, 2011, at 9:38 AM, Allen Wirfs-Brock wrote:
>
>> In a similar vain, what is the value of r in:
>>
>> let [z,y,...r] = {0:0, 1:1, 2:2, length: 3, 3:3,4:4};
>>
>> should it be [2] or [2,3,4]  (and if the latter how is that determined)?
>
> The inspiration for ... in the past came from (among other sources) Successor ML:
>
> http://successor-ml.org/index.php?title=Functional_record_extension_and_row_capture

Since I actually wrote half of that, I feel obliged to say that it
does not answer the questions raised here. ML is a typed language, and
contrary to popular belief, many language design problems are much
easier to solve in a typed setting.

However, there is some inspiration in the way SML treats tuples as
special cases of records, very much like arrays are a special case of
objects in JS. In particular, all of SML's pattern matching rules for
tuples follow just from the way they desugar into records with numeric
labels.

For Harmony, this kind of equivalence would imply that

  let [x, y, z] = e

is simply taken to mean

  let {0: x, 1: y, 2: z} = e

and the rest follows from there. The only problem is rest patterns.
One possible semantics could be treating

  let [x, y, z, ...r] = e

as equivalent to

  let {0: x, 1: y, 2: z, ..._r} = e
  let r = [].slice.call(_r, 3)

where I assume the "canonical" matching semantics for object rest
patterns that would make _r an ordinary object (not an array)
accumulating all properties of e not explicitly matched (even if e
itself is an array, in which case _r includes a copy of e's length
property). Of course, engines would optimize properly.

(But yes, row capture for objects introduces a form of object cloning,
as Allen points out.)

/Andreas


More information about the es-discuss mailing list