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

[Hudson, Rick]

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