A few Remote packaging concerns to address

[Ryan Newton]

I am finding out through experience that putting everything in one
aggregated module can be a hassle down the road. (After we initially
lumped them in I removed extra combinators from Control.Monad.Par only
to find that that would break the statistics package.)

For that reason I worry about having such a big API exposed through
"Remote" (which is also a top-level identifier). I counted 87
occurrences of "::".

For example, since the Task layer is higher level and implemented in
terms of Process couldn't it stay in a separate namespace (or even go
in a separate package).

I just though I'd bring it up; but none of this is a big deal and it's
great to have Remote by any name[space]!

-Ryan

[Dylan Lukes]

Yes, I agree. I don't think Remote is so generic that like Network it should be both a top level namespace and a library. It would probably be better to move the entire thing down a layer. Maybe use Cloud as a top level namespace, and put it this in Cloud.Remote?

- Dylan

P.S. I'm forwarding this to the new parallel-haskell group as well.

[Ryan Newton]

> Yes, I agree. I don't think Remote is so generic that like Network it should
> be both a top level namespace and a library. It would probably be better to
> move the entire thing down a layer. Maybe use Cloud as a top level
> namespace, and put it this in Cloud.Remote?

Personally I would vote for those flipped. "Remote.CloudHaskell".
There could be other packages providing "Remote" functionality.
(Though perhaps most of those are already under Network --
Network.CloudHaskell vs. Remote.CloudHaskell?)

-Ryan

[Dylan Lukes]

Yeah. I think Network already contains most stuff that would be in a Remote toplevel. Maybe Network.CloudHaskell.* for these packages?

I was always under the impression that "CloudHaskell" was the concept, and Remote was one specific implementation with an odd name. So, I vote for Network.CloudHaskell I guess.

Dylan

-----Original message-----