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

[Herhut, Stephan A]

Hi Mark, Rick.

Apart from offering a cleaner mental model, which can be discussed at great length, I believe there are practical advantages to having an index free model, e.g., code reuse: 

A minimal example: adding two vectors. Assume you already have a convenient addition function on scalar elements like

function add (a,b) { return a+b;}

How do we go to vectors from here? The current map allows you to write

vecA.map(add, vecB);

Note here that all extra arguments to map are implicitly indexed in the same way that the source array vecA is and both values are passed to the elemental function. So the above applies add to all pairs of elements from vecA and vecB (the usual JS semantics for [] applies to implicit selections also).

If we add index and array to the mix, we have to build an adapter for the differing interfaces:

vecA.map((a, ignore, ignore2, b) => add(a, b), vecB)

Maybe just about bearable with fat arrows, plain horrible with function:

vecA.map( function(a, ignore, ignore2, b) { return add(a,b); }, vecB)

Stephan

>-----Original Message-----
>From: es-discuss-bounces at mozilla.org [mailto:es-discuss-
>bounces at mozilla.org] On Behalf Of Hudson, Rick
>Sent: Friday, June 22, 2012 5:14 AM
>To: Mark S. Miller
>Cc: es-discuss
>Subject: RE: [[strawman:data_parallelism]] |this| and fat arrows
>
>Hey Mark,
>
>You asked "How/why might including index and the array itself distract the
>programmer from parallel thinking?"
>If we present index as a location and not as the nth invocation of kernel
>function then we are fine. Array.map overloads index to serve both purposes.
>My concern is that if we are too close to Array then programmers will assume
>we are the same and the same sequential semantics will hold. There is
>nothing inherently non-parallel about a location.
>
>You are correct that we are talking more about programmer psychology, art,
>and pedagogy and there is no formal technical reason to go either way. While
>passing 3 arguments might be more expensive than passing one in today's
>implementations there are probably compiler optimizations that can
>ameliorate the effects.
>
>Let's look closely at the change you are suggesting on a very simple map
>invocation.
>
>function add1(element) {return element+1;} strawmanPA.map(add1);
>alternatePA.map(add1);
>
>OK, JavaScript's argument passing semantics mean no difference for the
>common case where the result is dependent upon just the element. The
>alternate is even upwardly compatible.
>
>Now let's consider a typical geometric decomposition function like a vector
>blur.
>
>function blurStrawman(index, array) {
>  if (index < 1) return array[index];
>  return (array[index]+array[index-1])/2; } function blurAlternate(element,
>index, array) {
>  if (index < 1) return element;
>  return (element+array[index-1])/2;
>}
>
>strawmanPA.combine(blurStrawman);
>strawmanPA.map(blurAlternate);
>
>OK, blurAlternate again seems reasonable.
>
>I've played with other codes and I'm finding it increasingly hard to argue
>against your suggestions for arrays. Future proofing the cases where we might
>want to extend ParallelArray to objects seems fine since JavaScript blurs field
>names and indices allowing for index to have a reasonable meaning in the
>context of objects.
>
>Unless someone else speaks up I'll drop combine and change map and filter so
>the kernel function takes element, index, array.
>
>Cheers,
>- Rick
>
>-----Original Message-----
>From: Mark S. Miller [mailto:erights at google.com]
>Sent: Friday, June 15, 2012 6:06 PM
>To: Hudson, Rick
>Cc: es-discuss
>Subject: Re: [[strawman:data_parallelism]] |this| and fat arrows
>
>On Fri, Jun 15, 2012 at 11:35 PM, Hudson, Rick <rick.hudson at intel.com>
>wrote:
>> 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.
>
>Hi Rick, the claim made in the paragraph above seems to be the core
>argument. I respect the kind of argument you're making -- programmer
>psychology is important, and it is our responsibility as language designers to
>take it into account, and to help steer programmers towards certain ways of
>thinking about the problem and away from others. Sometimes these
>psychological issues have no corresponding formal basis, but are still
>important nevertheless. Arguments by non-psychologists like us about
>psychology can often be fuzzy, but this does not relieve us of responsibility of
>taking these into account.
>
>However, I don't have any intuition that supports the specific claim.
>Let's take "map" specifically. How/why might including index and the array
>itself distract the programmer from parallel thinking? First, do we agree that
>there's no formal problem, and the issue is only psychology? If so, perhaps
>you could provide some examples that would help illustrate the psychological
>issue you have in mind? At this point, I just don't get it.
>
>--
>    Cheers,
>    --MarkM
>_______________________________________________
>es-discuss mailing list
>es-discuss at mozilla.org
>https://mail.mozilla.org/listinfo/es-discuss