Re: API differences that need to be added to the strawman

[Niko Matsakis]

I don't care to argue this point extensively, but it seems like we might
as well make *some* effort to have toString() be useful for debugging.
I can imagine it being quite frustrating while debugging to have a
toString() method that for a matrix like [[1, 2], [3, 4]] that yielded
"1, 2, 3, 4", just because that's what Array.toString() would have
yielded if you had a two-dimensional array-of-arrays.

Also, have you all subscribed to the RT mailing list? It'd be nice to
start using that instead. I added it to the To: line. =)


Niko

> David Herman <mailto:dhe...@mozilla.com>
> October 3, 2012 3:07 PM
>
> As stupid as the JS precedent is, I think we should just stick with
> it. toString is traditionally lossy, so it can't be generally used to
> reconstruct the contents of a data structure. (Of course, in a sick,
> ironic twist of fate, one major exception to this rule is functions,
> which actually can in practice be used to reconstruct functions --
> free variables and native code notwithstanding. *blink* *blink*
> *blink* *siiiigh*)
>
> I guess I can see how multi-dimensional arrays are a less common use
> case for Array than they are for PA, which is all about
> n-dimensionality. Meh, I'm a little torn too, but I'm still leaning
> towards saying consistency trumps correctness.
>
> Dave
>
> Herhut, Stephan A <mailto:stephan....@intel.com>
> October 3, 2012 2:14 PM
> I am somewhat torn on the toString issue. On the one hand, being compatible with Array seems to be a reasonable thing and probably what users expect. On the other hand, I really don't like the fact that nested Arrays turn into a string that hides this structural property. Also, for debugging (and that is what I mostly use toString for) it would be nice to be able to differentiate Arrays from ParallelArray objects. However, using delimiters on PA objects alone does not suffice here:
>
> new ParallelArray([[1,2],[3,4]]).toString() yields (proposed)<1,2,3,4>
>
> We cannot 'fix' Array, so using delimiters is of little use here.
>
> I still like that you see the structure of a PA when using delimiters:
>
> new ParallelArray([2,3], f) yields<<1,2,3>,<4,5,6>>
>
> Very helpful to understand structure.
>
> One thing I noticed when playing: what is our story with toSource? Currently, we get a generic object back:
>
> new ParallelArray([1,2,3]).toSource() yields "({1:1, 2:2, 3:3})"
>
> So eval(ParallelArray([1,2,3]).toSource()) loses all ParallelArray properties. Is this desirable form a semantics perspective? Or should it yield:
>
> new ParallelArray([1,2,3]).toSource() yields "(new ParallelArray([1,2,3]))"
>
> I will work on folding the other things back into the strawman on the wiki.
>
> Stephan
>
>> -----Original Message-----
>> From: Hudson, Rick
>> Sent: Wednesday, October 03, 2012 7:01 AM
>> To: Shu-yu Guo; Herhut, Stephan A
>> Cc: Sreeram, Jaswanth; Niko Matsakis; David Herman
>> Subject: RE: API differences that need to be added to the strawman
>>
>> toString:
>> - '<' and'>' are used as delimiters
>> - An empty array is '', not '<>'
>>
>> In review currently JavaScript (tested on FF and Chrome) does the following.
>>
>> (new Array(1,2,3)).toString()
>> "1,2,3"
>>
>> (new Int32Array(1,2,3)).toString()
>> "[object Int32Array]"
>>
>> (new Array()).toString()
>> ""
>>
>> (new Array(new Array(1,2), new Array(10,20), new Array(100,
>> 200))).toString() "1,2,10,20,100,200"
>>
>> We probable should just do the same as Array and not include the delimiters.
>>
>> (new ParallelArray(new ParallelArray(1,2), new ParallelArray(10,20), new
>> ParallelArray(100, 200))).toString() "1,2,10,20,100,200"
>>
>> (new ParallelArray()).toString()
>> ""
>>
>> - Rick
>>
>> I agree with the rest, though I can't speak with any authority on the [[own]]
>> issues of the shape and length getters.
>>
>> - Rick
>>
>>
>> -----Original Message-----
>> From: Shu-yu Guo [mailto:s...@rfrn.org]
>> Sent: Tuesday, October 02, 2012 7:03 PM
>> To: Herhut, Stephan A
>> Cc: Sreeram, Jaswanth; Niko Matsakis; Hudson, Rick; David Herman
>> Subject: API differences that need to be added to the strawman
>>
>> In no particular order, these are semantic differences from the strawman. *I*
>> think they're all noncontroversial, but I wouldn't be surprised by pitchforks.
>>
>> Frozen instead of ad-hoc immutability:
>> - ParallelArray objects are created frozen in the Object.isFrozen sense.
>> - This means that warnings/errors are thrown in the same fashion as for
>> normal frozen JS objects: silently fail when not in strict mode, else throw.
>>
>> No holes:
>> - Index property accesses cannot be "holes".
>> - All in-bounds values exist. Passing a regular JS array with holes to a
>> ParallelArray constructor results in those indices being undefined.
>> - Out-of-bounds values are undefined and *do not* chase the prototype
>> chain but return undefined immediately.
>> - Enumeration respects this lack of prototype chaining on index properties.
>>
>> .length/.shape getters:
>> - In the same vein as TypedArray, .length and .shape are non-configurable
>> getters on the prototype. This avoids having to define .length and .shape as
>> "magical" properties like they are on JS arrays. It also means that .length and
>> .shape are *not* [[Own]] on ParallelArray objects.
>> - .shape rewraps each invocation, i.e. for a ParallelArray pa, pa.shape !==
>> pa.shape
>>
>> Overflow checking:
>> - All cases where a length property controls allocation (the constructors and
>> scatter) need to be checked for well-formedness. A TypeError is thrown if it is
>> not a number (+/-Infinity or NaN). A RangeError is thrown if the value passed
>> is a negative number or overflows uint32.
>> - Currently the comprehension form throws on each individual dimension
>> being malformed *as well as* their product being malformed.
> > From the discussion today we agreed it would be better to create nested
>> arrays in this case, but this behavior is not implemented.
>>
>> toString:
>> - '<' and'>' are used as delimiters
>> - An empty array is '', not '<>'
>>
>> Returning empty rows:
>> - An array of shape [d_0, ..., d_n, 0, ...], when indexed at the n-th dimension,
>> returns empty ParallelArray objects instead of undefined, even though the
>> scalar length of such an array is 0. This is to maintain the unobservability of
>> packed vs non-packed representations.
>> --
>> shu
> Hudson, Rick <mailto:rick....@intel.com>
> October 3, 2012 7:00 AM
> toString:
> - '<' and '>' are used as delimiters
> - An empty array is '', not '<>'
>
> In review currently JavaScript (tested on FF and Chrome) does the
> following.
>
> (new Array(1,2,3)).toString()
> "1,2,3"
>
> (new Int32Array(1,2,3)).toString()
> "[object Int32Array]"
>
> (new Array()).toString()
> ""
>
> (new Array(new Array(1,2), new Array(10,20), new Array(100,
> 200))).toString()
> "1,2,10,20,100,200"
>
> We probable should just do the same as Array and not include the
> delimiters.
>
> (new ParallelArray(new ParallelArray(1,2), new ParallelArray(10,20),
> new ParallelArray(100, 200))).toString()
> "1,2,10,20,100,200"
>
> (new ParallelArray()).toString()
> ""
>
> - Rick
>
> I agree with the rest, though I can't speak with any authority on the
> [[own]] issues of the shape and length getters.
>
> - Rick
>
>
> -----Original Message-----
> From: Shu-yu Guo [mailto:s...@rfrn.org]
> Sent: Tuesday, October 02, 2012 7:03 PM
> To: Herhut, Stephan A
> Cc: Sreeram, Jaswanth; Niko Matsakis; Hudson, Rick; David Herman
> Subject: API differences that need to be added to the strawman
>
> In no particular order, these are semantic differences from the
> strawman. *I* think they're all noncontroversial, but I wouldn't be
> surprised by pitchforks.
>
> Frozen instead of ad-hoc immutability:
> - ParallelArray objects are created frozen in the Object.isFrozen sense.
> - This means that warnings/errors are thrown in the same fashion as
> for normal frozen JS objects: silently fail when not in strict mode,
> else throw.
>
> No holes:
> - Index property accesses cannot be "holes".
> - All in-bounds values exist. Passing a regular JS array with holes
> to a ParallelArray constructor results in those indices being
> undefined.
> - Out-of-bounds values are undefined and *do not* chase the
> prototype chain but return undefined immediately.
> - Enumeration respects this lack of prototype chaining on index
> properties.
>
> .length/.shape getters:
> - In the same vein as TypedArray, .length and .shape are
> non-configurable getters on the prototype. This avoids having to
> define .length and .shape as "magical" properties like they are on JS
> arrays. It also means that .length and .shape are *not* [[Own]] on
> ParallelArray objects.
> - .shape rewraps each invocation, i.e. for a ParallelArray pa,
> pa.shape !== pa.shape
>
> Overflow checking:
> - All cases where a length property controls allocation (the
> constructors and scatter) need to be checked for well-formedness. A
> TypeError is thrown if it is not a number (+/-Infinity or NaN). A
> RangeError is thrown if the value passed is a negative number or
> overflows uint32.
> - Currently the comprehension form throws on each individual
> dimension being malformed *as well as* their product being malformed.
> From the discussion today we agreed it would be better to create
> nested arrays in this case, but this behavior is not implemented.
>
> toString:
> - '<' and '>' are used as delimiters
> - An empty array is '', not '<>'
>
> Returning empty rows:
> - An array of shape [d_0, ..., d_n, 0, ...], when indexed at the
> n-th dimension, returns empty ParallelArray objects instead of
> undefined, even though the scalar length of such an array is 0. This
> is to maintain the unobservability of packed vs non-packed
> representations.
> Shu-yu Guo <mailto:s...@rfrn.org>
> October 2, 2012 4:02 PM
> In no particular order, these are semantic differences from the
> strawman. *I* think they're all noncontroversial, but I wouldn't be
> surprised by pitchforks.
>
> Frozen instead of ad-hoc immutability:
> - ParallelArray objects are created frozen in the Object.isFrozen sense.
> - This means that warnings/errors are thrown in the same fashion as
> for normal frozen JS objects: silently fail when not in strict mode,
> else throw.
>
> No holes:
> - Index property accesses cannot be "holes".
> - All in-bounds values exist. Passing a regular JS array with holes
> to a ParallelArray constructor results in those indices being
> undefined.
> - Out-of-bounds values are undefined and *do not* chase the
> prototype chain but return undefined immediately.
> - Enumeration respects this lack of prototype chaining on index
> properties.
>
> .length/.shape getters:
> - In the same vein as TypedArray, .length and .shape are
> non-configurable getters on the prototype. This avoids having to
> define .length and .shape as "magical" properties like they are on JS
> arrays. It also means that .length and .shape are *not* [[Own]] on
> ParallelArray objects.
> - .shape rewraps each invocation, i.e. for a ParallelArray pa,
> pa.shape !== pa.shape
>
> Overflow checking:
> - All cases where a length property controls allocation (the
> constructors and scatter) need to be checked for well-formedness. A
> TypeError is thrown if it is not a number (+/-Infinity or NaN). A
> RangeError is thrown if the value passed is a negative number or
> overflows uint32.
> - Currently the comprehension form throws on each individual
> dimension being malformed *as well as* their product being malformed.
> From the discussion today we agreed it would be better to create
> nested arrays in this case, but this behavior is not implemented.
>
> toString:
> - '<' and '>' are used as delimiters
> - An empty array is '', not '<>'
>
> Returning empty rows:
> - An array of shape [d_0, ..., d_n, 0, ...], when indexed at the
> n-th dimension, returns empty ParallelArray objects instead of
> undefined, even though the scalar length of such an array is 0. This
> is to maintain the unobservability of packed vs non-packed
> representations.