Make array creation friendlier to worker-wrapper

[treeowl]

Closes #102

[treeowl]

The Core looks rather better, IMO (see, e.g., what this does to fmap). I don't have benchmarks to prove it's good, but I think we should merge this anyway.

[treeowl]

Another option is to write runArray in this manner (which is smaller and simpler), and use that to implement createArray. The inlining decisions end up a little different; I'm not sure which would really be better. But we likely should export runArray anyway.

[RyanGlScott]

Forgive me for being dense, but I'm still a bit unclear (from the comments, at least) how this is improving the interaction w.r.t. worker-wrapper. Can you expand on the comments a bit to clarify?

Also, if I understand correctly, this will make creating empty arrays slightly slower, yes? If so, is there an alternative way to create an empty array that is faster? We should point in out in the Haddocks if so.

[cartazio]

i guess another way of stating Ryan's question is:

what is a small example of what worker wrapper will facilitate here?

An important detail to keep in mind with Primitive is that its foremost a toolkit for mutable data structures, and fusion-y optimizations tend to be very low ROI in those cases. We should provide all the right primitives for supporting easy optimization in client libraries (like vector), but that doesn't mean we should push fusion into this layer?

I'm open to being educated / convinced about this, but could you help Ryan and Myself understand the goal / code improvements this will facilitate and some toy example where the change is high impact/measurable?

[treeowl]

The fact that immutable arrays aren't the prime directive doesn't mean they should get short shrift! I'm not really doing anything fancy here. Suppose I write f (fmap g ary), where f is strict (it's not just sticking the array in an array or something silly like that). We don't generally want fmap to actually produce an Array here. We want to produce an Array# and pass that straight to the worker for f. The problem with the current implementation is that it applies the Array constructor inside an ST action. runRW# doesn't inline till Core Prep, when it's too late to unbox anything. By moving the Array constructor application outside runRW#, we let GHC erase it.

[treeowl]

To be clear,

1. I have absolutely no desire to try to add any fusion framework to Array.
2. That doesn't mean there shouldn't be any fusion rules.
3. Nothing in this PR is very fusiony, except in the sense that GHC "fuses" away wrappers when it can.

[treeowl]

@RyanGlScott, yes, this will make creating empty arrays with createArray a bit slower. Instead of pointing to the same Array, separate invocations will point to different Arrays that all point to the same Array#. Since createArray is internal, I don't think there's anything to be gained from an extra empty export.

[RyanGlScott]

Since createArray is internal

Oops, I missed that part, so that makes that concern pretty much moot :)