Personal tools

Cloud Haskell

From HaskellWiki

(Difference between revisions)
Jump to: navigation, search
m (Videos and Blog Posts: add link to part 4)
Line 61: Line 61:
   
 
<tt>binary-generic</tt> and <tt>derive</tt> have been confirmed to work with Cloud Haskell; the status of the other packages is unknown -- YMMV (please feel free to update this wiki page if you have more information).
 
<tt>binary-generic</tt> and <tt>derive</tt> have been confirmed to work with Cloud Haskell; the status of the other packages is unknown -- YMMV (please feel free to update this wiki page if you have more information).
  +
  +
== Migration from <tt>remote</tt> ==
  +
  +
Here are some suggestions that might ease the migration from the Cloud Haskell prototype <tt>remote</tt> to <tt>distributed-process</tt>.
  +
  +
* The "implicit" type of mkClosure has changed (implicit because mkClosure is a Template Haskell function). In <tt>distributed-process</tt> mkClosure takes a function of type <tt>T1 -> T2</tt> and returns a function of type <tt>T1 -> Closure T2</tt>. In other words, the first argument to your function becomes the closure environment; if you want two items in your closure environment, create a function of type <tt>(T1, T2) -> T3</tt>; if you want none, create a function of type <tt>() -> T1</tt>.
  +
  +
* <tt>distributed-process</tt> follows the naming conventions in ''Towards Haskell in the Cloud'' rather than in <tt>remote</tt> so the functions that deal with typed channels are called <tt>sendChan</tt>, <tt>receiveChan</tt> and <tt>newChan</tt> instead of <tt>sendChannel</tt>, <tt>receiveChannel</tt> and <tt>newChannel</tt>.
  +
  +
* <tt>sendChan</tt>, <tt>receiveChan</tt> (and <tt>send</tt>) never fail in <tt>distributed-process</tt> (in <tt>remote</tt> they might throw a <tt>TransmitException</tt>). Instead, if you want to be notified of communication failure, you need to use <tt>monitor</tt> or <tt>link</tt>.
  +
  +
* The function <tt>forkProcess</tt> in <tt>remote</tt> is called <tt>spawnLocal</tt> in <tt>distributed-process</tt>
  +
  +
* The <tt>Process</tt> monad is called <tt>Process</tt> in <tt>distributed-process</tt> (rather than <tt>ProcessM</tt>)
  +
  +
* Initialization is different. See the documentation of of the [http://hackage.haskell.org/packages/archive/distributed-process-simplelocalnet/latest/doc/html/Control-Distributed-Process-Backend-SimpleLocalnet.html Control.Distributed.Process.SimpleLocalnet] to get started (note that the master/slave distinction in SimpleLocalnet is optional and does not need to be used).
  +
  +
* Peer discovery is different. The functions <tt>getPeers</tt> and <tt>nameQuery</tt> are no longer available. The function <tt>findPeers</tt> from <tt>SimpleLocalnet</tt> replaces some, but not all, of the functionality of <tt>getPeers</tt>. You can use <tt>whereisRemoteAsync</tt> to find processes that have been registered by name.

Revision as of 14:38, 23 October 2012

Cloud Haskell is a domain-specific language for developing programs for a distributed computing environment. Implemented as a shallow embedding in Haskell, it provides a message passing communication model, inspired by Erlang, without introducing incompatibility with Haskell’s established shared-memory concurrency.

Contents

1 Availability

Cloud Haskell is available from Hackage as distributed-process. You might also want to install distributed-process-simplelocalnet. The cutting edge development version is on github.

There is also the older prototype implementation remote (also available from github).

2 Documentation

For an overview of Cloud Haskell it's probably a good idea to read Towards Haskell in the Cloud (details below). The relevant documentation (in order of importance is)

and

If you want to know more details about Closure or Static (without the Template Haskell magic on top) you might want to read

3 Videos and Blog Posts

Cloud Haskell intros

  • blog: A Cloud Haskell Appetiser (Parallel Haskell Digest 11)
  • video: (1hr) Cloud Haskell: a general introduction and tutorial, focusing on what it does and how to use it. It also covers some details about the current implementation.
  • video: (1hr) Towards Haskell in the Cloud: an older but more detailed introduction by Simon Peyton Jones about the problem area and the design decisions and internals of Cloud Haskell. In particular it covers the details of how sending functions over the wire really works.

Well-Typed have a series of blog posts "Communication Patterns in Cloud Haskell"

Alen Ribic has a series of blog posts about (Cloud) Haskell on the Raspberry Pi

4 Papers

5 Other Useful Packages

5.1 Serializable

A core concept in Cloud Haskell is that of serializable values. The Serializable type class combines Typeable and Binary. ghc can automatically derive Typeable instances for custom data types, but you need a package to derive Binary. There are various packages available that assist with this:

binary-generic and derive have been confirmed to work with Cloud Haskell; the status of the other packages is unknown -- YMMV (please feel free to update this wiki page if you have more information).

6 Migration from remote

Here are some suggestions that might ease the migration from the Cloud Haskell prototype remote to distributed-process.

  • The "implicit" type of mkClosure has changed (implicit because mkClosure is a Template Haskell function). In distributed-process mkClosure takes a function of type T1 -> T2 and returns a function of type T1 -> Closure T2. In other words, the first argument to your function becomes the closure environment; if you want two items in your closure environment, create a function of type (T1, T2) -> T3; if you want none, create a function of type () -> T1.
  • distributed-process follows the naming conventions in Towards Haskell in the Cloud rather than in remote so the functions that deal with typed channels are called sendChan, receiveChan and newChan instead of sendChannel, receiveChannel and newChannel.
  • sendChan, receiveChan (and send) never fail in distributed-process (in remote they might throw a TransmitException). Instead, if you want to be notified of communication failure, you need to use monitor or link.
  • The function forkProcess in remote is called spawnLocal in distributed-process
  • The Process monad is called Process in distributed-process (rather than ProcessM)
  • Initialization is different. See the documentation of of the Control.Distributed.Process.SimpleLocalnet to get started (note that the master/slave distinction in SimpleLocalnet is optional and does not need to be used).
  • Peer discovery is different. The functions getPeers and nameQuery are no longer available. The function findPeers from SimpleLocalnet replaces some, but not all, of the functionality of getPeers. You can use whereisRemoteAsync to find processes that have been registered by name.