ArrayArrays

[Simon Marlow]

On 27/08/2015 19:36, Edward Kmett wrote:
> On Thu, Aug 27, 2015 at 1:24 PM, Edward Z. Yang <ezyang at mit.edu
> <mailto:ezyang at mit.edu>> wrote:
>
>     It seems to me that we should take a page from OCaml's playbook
>     and add support for native mutable fields in objects, because
>     this is essentially what a mix of words and pointers is.
>
>
> That actually doesn't work as well as one might hope.
>
> We currently treat data constructor closures as so much tissue paper
> around a present. We tear them open, rip out all their contents, scatter
> them throughout our code and then we build a whole new data constructor
> closure when we're done, or we just leave them suspended in closures
> awaiting someone to demand we finally make a new data constructor.
>
> Half the time we don't even give back the data constructor closure and
> push it into update g frames and we just give back the items on the stack.
>
> With the machinery I mentioned above I get a world where every time I
> access an object I can know it is evaluated for real, so this means I'm
> not stuck 'entering an unknown closure', and getting it to give me back
> a slab of memory that we know is a real data constructor that i can bang
> away on mutable entries in.
>
> In a world where things in * could hold mutable pointers we have to care
> a lot more about object identity in deeply uncomfortable ways.
>
> With what I've implemented I only care about object identity between
> things in # that are gcptrs. The garbage collector may move them around,
> but it doesn't put in thunks anywhere.

Yeah, I've actually thought about whether we could have mutable fields 
in constructors a couple of times, and it's far from easy for the 
reasons you describe.  A constructor with mutable fields would need to 
be an object with identity, with precise control over when it is 
created.  This is nothing like an ordinary constructor.

I like the alternative approach in this thread, which is to attack the 
problem from the other end: start with a primitive object and make it 
more like a constructor.

I don't see any reason why we shouldn't add primops to read/write 
SmallArray# and other primitive objects in an ArrayArray#.  Will someone 
make a patch?  It should be pretty straightforward.

Cheers,
Simon