Separating ParFuture and ParIVar

[osa1]

Currently ParFuture is a superclass of ParIVar. We use ParFuture superclass to make Future and IVar types same(why we need this?).

But this has some problems, for example, IVar methods don't need FutContents constraints: In the implementation of alternative schedulers we may need NFData constraint in FutContents to handle lazy exceptions, but we only need Eq in IVars etc.

So we may want to remove the superclass constraint. If we decide not to change it, at least we should document why ParFuture is a superclass of ParIVar and why we want IVars and Futures to be the same.

cc @rrnewton

[rrnewton]

Originally, the idea was that these were indeed refinements of the same concept. Further, if one is writing code with IVars, it would be a pain to define a new spawn for example, which worked for IVars rather than futures, rather than just sharing the same function. (The separation vs. combination of Monad vs Applicative may serve as a point of comparison.)

The problem is that with both the IVar and Future APIs there are some choices about the semantics that we need to either decide one way or parameterize over.

• IVars: are multiple puts of the same value allowed? (This requires an Eq instance, and relates to FutContents, #108 )
• Futures -- are spawned computations that diverge or throw exceptions able to affect the parent computation if the future is ever read?

I think both of these issues can be teased out by looking at which laws we want and don't want for each class. I'll start an issue specifically for discussing those laws, and we should put the ones we agree on in the comments at least.