[[strawman:data_parallelism]] |this| and fat arrows

Hudson, Rick rick.hudson at intel.com
Fri Jun 15 08:35:09 PDT 2012

Hey Mark,
ParallelArray and index are left out because of our desire to provide a few good methods that help/force programmers to think about parallel algorithms and not just speeding up sequential algorithms. Array map is really just syntactic sugar for for loops and invites thinking that depends on order. For ParallelArray map we felt that the value was the semantically important thing and the user should not be distracted by the index. Not having index available is one step towards thinking in more parallel ways.

In situations where index is more semantically important than the value we provide the method combine.  Here we pass the ParallelArray and the index and not the value to the kernel function. A blur function that averages the values surrounding some location would naturally use combine. The documentation encourages the programmer to think of index as the _destination_ of the value the kernel function returns. Again the intent is to try and break away from sequential thinking. 

Filter is like combine, it gets the ParallelArray and the index and allows filtering based on location. If one accepts the above map/combine arguments then one could make a reasonable argument that there should be a filter based on value and a filter based on location. (Thanks you've forced me to think about this again.)

The other methods have less use for index. 
Reduce) we agree that passing in the index doesn't make sense.
Scan) has the same problems with index that reduce has.
Scatter) takes an array of destination indices and a 2 arg conflict function. The index of both of the source elements isn't always available so it doesn't make sense here either.

Not passing in the ParallelArray was a tougher decision. We really liked the way we had |this| bound to the ParallelArray since it made composition / nested parallelism straight forward and natural. With the exception of combine and filter the programmer has to arrange for the ParallelArray to be available in order to do composition.

I think a clean break from high order Array methods is the way to go here, syntactically similar forms with semantically different meaning is worth avoiding.

- Rick
Guy Steele "Language design is as much the art of what to leave out as what to put in."

-----Original Message-----
From: Mark S. Miller [mailto:erights at google.com] 
Sent: Thursday, June 14, 2012 7:32 PM
To: Hudson, Rick
Cc: es-discuss
Subject: Re: [[strawman:data_parallelism]] |this| and fat arrows

Hi Rick,

Even without =>, I think this is an improvement to the API overall, as
it makes it more similar to the corresponding array methods. However,
I do not see the problem with making it much more similar. I agree
regarding reduce and reduceRight, but fortunately, these already
violate the general pattern for the other higher order array methods
-- in that they call their callbackfn with "this" always bound to
undefined. In retrospect, I wish we had called the existing function
"reduceLeft" so yours could be called simply "reduce" and have the
name difference suggest the lack of order.

Regarding the others, the general pattern from the ho array methods is

    array.foo(callbackfn, possible-other-args, optional-this-arg)

calls back

    callbackfn(value, index, array, this-arg-or-undefined)

I wish that the optional-this-arg had been omitted from ES5, but for
the sake of compat with the Prototype library and other
implementations of these methods, I lost that argument. In retrospect
I agree with that decision, even though I still believe that the
this-arg has net negative value. By the same reasoning, I think you
should follow this pattern as well except when there's a good argument
not to. For "reduce" you make a good argument.

Further comments inline below.

On Fri, Jun 15, 2012 at 4:27 AM, Hudson, Rick <rick.hudson at intel.com> wrote:
> Proposed change to [[strawman:data_parallelism]]
> The ParallelArray methods map, combine, reduce, scan, scatter, and filter,
> each take a kernel function as an argument. Within this kernel function
> |this| is currently bound to the ParallelArray. This was natural and
> non-controversial

I disagree that it was non-controversial -- I argued against it on
compat grounds at the time. But I agree with your point that => makes
that old design even less viable.

> as long as we used the function(){..} form which did not
> restrict how |this| was bound and explaining the semantics in terms of call
> or apply was perfectly reasonable. => is likely to change that.  =>, as
> proposed, enforces a lexical |this| and is semantically different than the
> function () {..} form. Going forward we expect folks to use the => form more
> than the function form. For the most part we will be leaving the kernel
> signatures as they are except that we will no longer bind |this| to the
> ParalleArray is inside a kernel function. Instead |this| will be bound in
> accordance to existing JavaScript specifications and
> [[strawman:data_parallelism]] will no longer refer to |this|. For the
> combine method which currently gets only an index as an argument we will now
> also pass the ParallelArray in. If the programmer wants the ParallelArray in
> methods like reduce or map then it will have to be passed in as a free
> variable.
> We considered and decided not to mimic Array's function (element, index,
> array) { ... } form. We felt that it causes intellectual confusion about
> parallel programming since passing in index and array force the programmer
> to think about things like order and location when using methods like map.

This seems to be your key point, and I don't understand it at all.
Since you single out map, could you please explain how this causes any
confusion when using map? Thanks.

> It is even more intellectually confusing when using reduce since in a
> parallel world both of the values passed in may be the results of previous
> kernel invocations and as such not have an index in any reasonable sense.
> For combine and filter we pass the ParallelArray in as the second argument.
> For the other methods one can pass the ParallelArray in using a free
> variable.
> - Rick
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss


More information about the es-discuss mailing list