Get rid of FutContents

[rrnewton]

Ömer (@osa1) and I have been discussing this. At one point, we wanted to be able to retain "put" functions without an Eq constraint, like the earlier monad-par library. But now I think we should look into giving up on that and requiring Eq everywhere, which lets us get rid of FutContents. I don't believe there were any other good use cases for FutContents. (A better use case for class associated constraints in LVish is probably the Map-like collections, which have various requirements on their keys.)

FutContents seems to be a good example of an over-abstracted API. It pollutes a lot of interfaces with for par computations with implementation details about what is or isn't stored in IVars internally within the algorithm.

Speak up if you have anything you must stick in a future or IVar which cannot have an Eq instance!

[osa1]

One problem with current FutContents is this: Let's say we have a ST
function, something like:

loopmpm :: Int -> (forall ls . ParST (stt ls) p e s ())
loopmpm = ...

When we run this in a ParMonad p, we have to add FutContents p ((), stt ls)
to the context, but that would mean escaping ls from it's scope, which is not
possible. So this function is useless.

I'm wondering if we could remove FutContents from some of the methods. It
seems like we only need that constraint on IVar operations, do we need to add
that constraint to ParFuture methods? If we don't, we can move FutContents
to ParIVar class. (and probably rename it) This would solve some of the
problems.

[osa1]

Update: Yesterday at the meeting we discussed this briefly, and had the idea of removing argument e from FutContents:

type FutContents m :: * -> Constraint

I just tried this but it didn't make any difference -- I'm getting exactly the same error message.

I don't fully understand how this could allow our programs to type check, as far as I can see only difference is this is less flexible, because now I can't define something like this:

type FutContents Par a = (Eq a, Ord a)

instead I have to do something like:

type FutContents Par = Eq

So I have this idea: FutContents is necessary in ParFuture because of implementation details -- ParFuture methods of Par are defined using IVar operations, which need Eq constraint on elements. If we use something else, like an MVar, to write the results, we could remove the constraint from ParFuture class and move it to ParIVar class.

@rrnewton yesterday you mentioned why we need to use IVar in ParFuture internals, but I didn't quite understand the example. Could you elaborate on this?

[rrnewton]

Yes, it's annoying not to have type-level lambda, but can't you do something like:

type FutContents Par = EqOrd
type EqOrd a = (Eq a, Ord a)

Or maybe type aliases aren't allowed in that way?

[rrnewton]

@osa1 : Well, whatever you use to implement a ParFuture instance for a given Par monad, if fork allows duplication of the forked computation, it would need to be something idempotent. (I.e. a naive putMVar would deadlock if the second task tried to put on a full MVar.)

[osa1]

OK, that makes sense. I'll try to find a workaround then.