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.hud...@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@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
--
Cheers,
--MarkM
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
