Implement MonadPar and MonadRace

[garyb]

Will resolve #60.

So this definitely seems straightforward enough, apart from the minor problem of needing to move AVar into the main Aff module, unless we want to implement a load of stuff in the FFI. We end up with a circular dependency between the Aff and AVar modules otherwise, as the instances have to be defined in Aff, and the AVar module depends on the Aff module.

Another thought, while we're at it, does there actually need to be an AVAR effect? It doesn't really tell you much about what might occur, other than there's some "advanced" async behaviour going on, but Aff implies async anyway. I ask as apart from it being common that AVAR appears in every Aff effect row for non-trivial uses, it actually has to be hidden for MonadPar and MonadRace as we can't specify it in the instance head, no rows are allowed there. Hence the eraseAVar usage here.

This isn't ready for merge yet, as I just dumped the AVar stuff into Aff, it's not sorted out properly yet.

[jdegoes]

@garyb There does have to be an AVAR, although it could be REF or something, as combined with Aff, it has the right connotation (mutable variable).

[garyb]

Ah true, I forgot about that as we mostly use the takeVar for waiting behaviour. I guess in the case of MonadPar/MonadRace it's safe enough to erase, since we know that it's only being used for that purpose... that and we have no choice if we want to use that in the implementation.

How do you feel about moving AVar into Aff? Probably better than duplicating a load of FFI code I guess?

[jdegoes]

I don't terribly mind moving AVar into Aff, though it will clutter the namespace somewhat.

�Can't one FFI module import another FFI module?

[garyb]

We can indeed pull in cross-FFI-module dependencies, but we still need to replicate some of the AVar interface in Aff. It's not exported though, so maybe that's fine?

[garyb]

It's pretty neat that I could just swap Par for Parallel in the tests and everything still worked! (I know that's the whole point, but still...) 😄

[natefaubion]

Won't this break if you are using psc-bundle without browserify?

[garyb]

I don't think pulp test uses browserify, and it succeeds there, so no, I think it's ok. I was concerned about that too... I'm still a little suspicious, but it seemed to work for the cases I tested. I'll try with psc-bundle directly to ensure there isn't some magic in pulp.

[natefaubion]

I think pulp test just runs it in node (no bundling), so it would work. But I don't think psc-bundle will follow this reference, and you'll end up with a stray require for it.

[garyb]

Hmm, it doesn't exactly work. It works in node if the planets align correctly, as the require is resolved by node instead... but the bundle isn't browser-safe at that point, so yeah, this probably isn't going to work.

[garyb]

I've just pushed another set of changes that should address the FFI problems. This time we have an Internal module that has most of the AVar stuff in it, but using a placeholder foreign type for Aff that is then coerced as necessary in the Aff and AVar modules.

[natefaubion]

I think this looks good. You could also push the Aff/AVAR foreign declarations into an Internal.Types module, and just reexport them rather than coercing.

[garyb]

We'd end up with the orphan instance issue I'm trying to avoid again there though! Unless we made Aff a newtype around an internal foreign aff or something. The AVar type is re-exported from the internal module now though.

[natefaubion]

Oh, right! Then I think what you've done is fine.

[jdegoes]

@garyb This looks pretty good. Any breaking (public) API changes?

[garyb]

I think the removal of Par is the only breaking change here - the AVar module still exports everything it used to, although the AVar type itself is a re-export now, and the Aff exports haven't changed at all.

I could reinstate Par if you like, so prevent it being another breaking change? But if #52 is going to result in a breaking changes we could wait to release this until that is merged too.

[jdegoes]

@garyb I'm fine with that breakage. I do want #52 in the next release too.