- Haskell-Cafe - Haskell.org

Re: [Haskell-cafe] specifying using type class
by Patrick Browne 23 Jul '12

23 Jul '12

2 3

Need help with learning Parsec
by C K Kashyap 23 Jul '12

23 Jul '12

Dear gentle Haskellers, I was trying to whet my Haskell by trying out Parsec today to try and parse out XML. Here's the code I cam up with - I wanted some help with the "gettext" parser that I've written. I had to do a dummy "char ' ') in there just to satisfy the "many" used in the xml parser. I'd appreciate it very much if someone could give me some feedback. data XML = Node String [XML] | Body String deriving Show gettext = do x <- many (letter <|> digit ) if (length x) > 0 then return (Body x) else (char ' ' >> (return $ Body "")) xml :: Parser XML xml = do { name <- openTag ; innerXML <- many innerXML ; endTag name ; return (Node name innerXML) } innerXML = do x <- (try xml <|> gettext) return x openTag :: Parser String openTag = do char '<' content <- many (noneOf ">") char '>' return content endTag :: String -> Parser String endTag str = do char '<' char '/' string str char '>' return str h1 = parse xml "" "<a>A</a>" h2 = parse xml "" "<a>A</a>" h3 = parse xml "" "<a><c></c></a>" h4 = parse xml "" "<a><c></c></a>" Regards, Kashyap

5 17

Re: [Haskell-cafe] Haskell's type inference considered harmful
by oleg＠okmij.org 23 Jul '12

23 Jul '12

> 1. Haskell's type inference is NON-COMPOSITIONAL! Yes, it is -- and there are many examples of it. Here is an example which has nothing to do with MonomorphismRestriction or numeric literals {-# LANGUAGE ExtendedDefaultRules #-} class C a where m :: a -> Int instance C () where m _ = 1 instance C Bool where m _ = 2 main = do x <- return undefined let y = x print . fst $ (m x, show x) -- let dead = if False then not y else True return () The program prints 1. If you uncomment the (really) dead code, it will print 2. Why? The dead code doesn't even mention x, and it appears after the printing! What is the role of show x, which doesn't do anything? Exercises: what is the significance of the monadic bind to x? Why can't we replace it with "let x = undefined"? [Significant hint, don't look at it] Such a behavior always occurs when we have HM polymorphism restriction and some sort of non-parametricity -- coupled with default rules or overlapping instances or some other ways of resolving overloading. All these features are essential (type-classes are significant, defaulting is part of the standard and is being used more and more).

3 4

System.Win32.Registry... Help?
by Anonymous Void 22 Jul '12

22 Jul '12

Hi, I'm working on a project that will require me to create and possibly set registry keys. I don't have much experience with programming on Windows either, but I'm having to learn as you don't get many *nix PCs at a computer repair shop, lol. I found a mailing list post showing how to read registry keys and was able to make a function based off of it, but I have no idea what to put into some of the arguments for regSetValueEx or regCreateKeyEx, so I'm stuck. Also, what's the best way to recursively traverse trees in the registry, are there any functions for it? Can someone please help me out with this? Thank you. {-# LANGUAGE ForeignFunctionInterface #-} import System.Win32.Types import System.Win32.Registry import Foreign.Ptr (castPtr) import Foreign.Marshal.Alloc (allocaBytes) import Foreign.C.String (peekCWString, withCWString) import Control.Exception (bracket, throwIO) -- // parse a string from a registry value of certain type parseRegString :: RegValueType -> LPBYTE -> IO String parseRegString ty mem | ty == rEG_SZ = peekCWString (castPtr mem) | ty == rEG_EXPAND_SZ = peekCWString (castPtr mem) >>= expandEnvironmentStrings | otherwise = ioError (userError "Invalid registry value type") -- // FFI import of the ExpandEnvironmentStrings function needed -- // to make use of the registry values expandEnvironmentStrings :: String -> IO String expandEnvironmentStrings toexpand = withCWString toexpand $ \input -> allocaBytes 512 $ \output -> do c_ExpandEnvironmentStrings input output 256 peekCWString output foreign import stdcall unsafe "windows.h ExpandEnvironmentStringsW" c_ExpandEnvironmentStrings :: LPCTSTR -> LPTSTR -> DWORD -> IO DWORD ---- get_key :: HKEY -> String -> String -> IO String get_key cat loc key = bracket op regCloseKey $ \x -> allocaBytes 512 $ \mem -> do ty <- regQueryValueEx x key mem 512 parseRegString ty mem where op = regOpenKeyEx cat loc kEY_QUERY_VALUE set_key :: HKEY -> String -> String -> IO () set_key cat loc key = regSetValueEx cat loc rEG_SZ??? "LPTSTR? What do I put here?" magic_win32_number_here? where op = regOpenKeyEx cat loc kEY_SET_VALUE main = get_key hKEY_CURRENT_USER loc key >>= print where loc = "Software\\7-Zip" key = "Test"

2 3

How do I marshall a pointer over SendMessage LPARAM or WPARAM?
by Simon Peter Nicholls 22 Jul '12

22 Jul '12

Cross-posted from Haskell-beginners. Apologies for not posting in the right place (though I am a beginner and have probably made a simpleton error). I'm new to Haskell, and have had some good success with FFI so far, but using Win32's sendMessage to send a pointer in LPARAM or WPARAM is resulting in access violations at the other end. Is there some issue with my pointer conversions? Am I hitting some restriction, or missing some compiler options? It's driving me pretty crazy, after a very nice start to using Haskell. Some "sending" code: Foreign.C.String.withCWString "frustrator" $ \s -> do let wParam = System.Win32.Types.castPtrToUINT s :: System.Win32.Types.WPARAM Graphics.Win32.sendMessage wnd Graphics.Win32.wM_APP wParam 0 wndProc "receiving" code: | wmsg == Graphics.Win32.wM_APP = do s <- peekCWString $ System.Win32.Types.castUINTToPtr wParam putStrLn s return 0 The string will not be seen. Some extra notes: I can get wndProc messages and integral data generally. The pointer values match textually at both ends when "shown" to stdout. At the sending side I can pass the CWString to a regular FFI function call just fine, and castUINTToPtr will give me back a functioning Ptr for that call. I have also tried sending to & receiving from a working C++ program, without success. Access violations are reported when receiving, though again the address matches up. Silence from Haskell as before, when C++ is sending. I found someone else having an issue here: http://osdir.com/ml/haskell-cafe@haskell.org/2009-11/msg00731.html but no solution unfortunately. UPDATE since prior posting: Seems if I call out via FFI on the sending side, and set the WPARAM to L"hardcoding FTW" in a wrapper C function, the SendMessage I then invoke will work. The C code sees both the original string and the new one, but only the second works when used. I must be missing something obvious, but have toasted my grey cells at this point!

2 2

System.Win32.Registry... Help?
by Dave Buznik 22 Jul '12

22 Jul '12

---------- Forwarded message ---------- From: Anonymous Void <bitsofchaos(a)gmail.com> Date: Sun, Jul 22, 2012 at 2:10 AM Subject: Re: [Haskell-cafe] System.Win32.Registry... Help? To: Tim Matthews <tim.matthews7(a)gmail.com> I've looked into their docs, but I can't for the life of me figure out how to convert a string to lptstr, for example: set_key :: HKEY -> String -> String -> IO () set_key cat loc key = do foo <- okey regSetValueEx foo "foo" rEG_SZ "foo" 0 where okey = regOpenKeyEx cat loc kEY_ALL_ACCESS will give me an error about it expecting LPTSTR and not [char] for "foo", but I have no idea how to convert the c/win32 types using Haskell, and msdn docs aren't helping any... I know in Python the following works, but I don't want to use Python for this app... key = OpenKey(HKEY_CURRENT_USER, "Software\\7-Zip", 0, KEY_ALL_ACCESS) SetValueEx(key, "test", 0, REG_SZ, "foobar") CloseKey(key) but that's basically where I'm stuck at right now, I've searched but wasn't able to find one single use case of regSetValueEx in Haskell, otherwise I'd be done already... I've been stuck on this for days and it's a two-hour app... I'm ashamed. LOL. On Sun, Jul 22, 2012 at 1:44 AM, Tim Matthews <tim.matthews7(a)gmail.com> wrote: > > > On Sun, Jul 22, 2012 at 5:43 PM, Tim Matthews <tim.matthews7(a)gmail.com> > wrote: >> >> >> >> On Sun, Jul 22, 2012 at 5:11 PM, Anonymous Void <bitsofchaos(a)gmail.com> >> wrote: >>> >>> >>> but I have no idea what to put into some of the arguments for >>> regSetValueEx or regCreateKeyEx, >> >> >> Those are just plain bindings to windows function so refer to msdn > > -- mysql> insert into female (vagina) select male.penis from male where penis='sperm'; Query OK, 1 row affected (0.02 sec) Records: 1 Duplicates: 0 Warnings: 0 mysql> select * from female; +--------+ | vagina | +--------+ | sperm | +--------+ 1 row in set (0.00 sec) mysql> ... N' that's how programmers make babies.

2 1

Re: [Haskell-cafe] System.Win32.Registry... Help?
by Tim Matthews 22 Jul '12

22 Jul '12

On Sun, Jul 22, 2012 at 5:43 PM, Tim Matthews <tim.matthews7(a)gmail.com>wrote: > > > On Sun, Jul 22, 2012 at 5:11 PM, Anonymous Void <bitsofchaos(a)gmail.com>wrote: > >> >> but I have no idea what to put into some of the arguments for >> regSetValueEx or regCreateKeyEx, >> > > Those are just plain bindings to windows function so refer to msdn > <http://msdn.microsoft.com/en-us/library/windows/desktop/ms724923%28v=vs.85%…> >

1 0

Darcs / ByteString optimisation
by Luke Worth 22 Jul '12

22 Jul '12

Hi, I'm currently investigating darcs' performance issues. The first thing I looked at was ByteString.concat, which seems to allocate a lot of extra objects. Here is the standard definition: >concat :: [ByteString] -> ByteString >concat [] = empty >concat [ps] = ps >concat xs = unsafeCreate len $ \ptr -> go xs ptr > where len = P.sum . P.map length $ xs > go a b | a `seq` b `seq` False = undefined > go [] _ = return () > go (PS p s l:ps) ptr = do > withForeignPtr p $ \fp -> memcpy ptr (fp `plusPtr` s) (fromIntegral l) > go ps (ptr `plusPtr` l) I had a bad feeling about (sum . map) inside len, so I replaced it (inside darcs) with a stricter-looking one: >myconcat :: [B.ByteString] -> B.ByteString >myconcat [] = B.empty >myconcat [ps] = ps >myconcat xs = BI.unsafeCreate len $ \ptr -> go xs ptr > where len = foldl' (\a b -> a + B.length b) 0 xs > go a b | a `seq` b `seq` False = undefined > go [] _ = return () > go (BI.PS p s l:ps) ptr = do > withForeignPtr p $ \fp -> BI.memcpy ptr (fp `plusPtr` s) (fromIntegral l) > go ps (ptr `plusPtr` l) Profiling the original one gives me 2,042,215,624 bytes allocated in the heap 3,131,672,496 bytes copied during GC 363,380,328 bytes maximum residency (43 sample(s)) 2,517,336 bytes maximum slop 643 MB total memory in use (50 MB lost due to fragmentation) while the second, with no other changes, gives 1,774,403,640 bytes allocated in the heap 2,656,774,296 bytes copied during GC 358,131,264 bytes maximum residency (42 sample(s)) 1,577,080 bytes maximum slop 614 MB total memory in use (50 MB lost due to fragmentation) Is it possible that the code using ByteString.concat is preventing the compiler from doing this optimisation? Thankyou, Luke Worth

1 0

Re: [Haskell-cafe] Monads with "The" contexts?
by oleg＠okmij.org 21 Jul '12

21 Jul '12

The bad news is that indeed you don't seem to be able to do what you want. The good news: yes, you can. The enclosed code does exactly what you wanted: > sunPerMars :: NonDet Double > sunPerMars = (/) <$> sunMass <*> marsMass > > sunPerMars_run = runShare sunPerMars > sunPerMars_run_len = length sunPerMars_run > -- 27 where earthMass, sunMass, marsMass are all top-level bindings, which can be defined in separate and separately-compiled modules. Let's start with the bad news however. Recall the original problem: > earthMass, sunMass, marsMass :: [Double] > earthMass = [5.96e24, 5.97e24, 5.98e24] > sunMass = (*) <$> [2.5e5, 3e5, 4e5] <*> earthMass > marsMass = (*) <$> [0.01, 0.1, 1.0] <*> earthMass The problem was that the computation sunPerMars = (/) <$> sunMass <*> marsMass produces too many answers, because earthMass in sunMass and earthMass in marsMass were independent non-deterministic computations. Thus the code says: we measure the earthMass to compute sunMass, and we measure earthMass again to compute marsMass. Each earthMass measurement is independent and gives us, in general, a different value. However, we wanted the code to behave differently. We wanted to measure earthMass only once, and use the same measured value to compute masses of other bodies. There does not seem to be a way to do that in Haskell. Haskell is pure, so we can substitute equals for equals. earthMass is equal to [5.96e24, 5.97e24, 5.98e24]. Thus the meaning of program should not change if we write > sunMass = (*) <$> [2.5e5, 3e5, 4e5] <*> [5.96e24, 5.97e24, 5.98e24] > marsMass = (*) <$> [0.01, 0.1, 1.0] <*> [5.96e24, 5.97e24, 5.98e24] which gives exactly the wrong behavior (and 81 answers for sunPerMars, as easy to see). Thus there is no hope that the original code should behave any differently. > I don't know if memo can solve this problem. I have to test. Is the > `memo` in your JFP paper section 4.2 Memoization, a psuedo-code? (What > is type `Thunk` ?) and seems like it's not in explicit-sharing > hackage. BTW, the memo in Hansei is different from the memo in the JFP paper. In JFP, memo is a restricted version of share: memo_jfp :: m a -> m (m a) In Hansei, memo is a generalization of share: memo_hansei :: (a -> m b) -> m (a -> m b) You will soon need that generalization (which is not mention in the JFP paper). Given such a let-down, is there any hope at all? Recall, if Haskell doesn't do what you want, embed a language that does. The solution becomes straightforward then. (Please see the enclosed code). Exercise: how does the approach in the code relate to the approaches to sharing explained in http://okmij.org/ftp/tagless-final/sharing/sharing.html Good luck with the contest! {-# LANGUAGE FlexibleContexts, DeriveDataTypeable #-} -- Sharing of top-level bindings -- Solving Takayuki Muranushi's problem -- http://www.haskell.org/pipermail/haskell-cafe/2012-July/102287.html module TopSharing where import qualified Data.Map as M import Control.Monad.State import Data.Dynamic import Control.Applicative -- Let's pretend this is one separate module. -- It exports earthMass, the mass of the Earth, which -- is a non-deterministic computation producing Double. -- The non-determinism reflects our uncertainty about the mass. -- Exercise: why do we need the seemingly redundant EarthMass -- and deriving Typeable? -- Could we use TemplateHaskell instead? data EarthMass deriving Typeable earthMass :: NonDet Double earthMass = memoSta (typeOf (undefined::EarthMass)) $ msum $ map return [5.96e24, 5.97e24, 5.98e24] -- Let's pretend this is another separate module -- It imports earthMass and exports sunMass -- Muranushi: ``Let's also pretend that we can measure the other -- bodies' masses only by their ratio to the Earth mass, and -- the measurements have large uncertainties.'' data SunMass deriving Typeable sunMass :: NonDet Double sunMass = memoSta (typeOf (undefined::SunMass)) mass where mass = (*) <$> proportion <*> earthMass proportion = msum $ map return [2.5e5, 3e5, 4e5] -- Let's pretend this is yet another separate module -- It imports earthMass and exports marsMass data MarsMass deriving Typeable marsMass :: NonDet Double marsMass = memoSta (typeOf (undefined::MarsMass)) mass where mass = (*) <$> proportion <*> earthMass proportion = msum $ map return [0.01, 0.1, 1.0] -- This is the main module, importing the masses of the three bodies -- It computes ``how many Mars mass object can we create -- by taking the sun apart?'' -- This code is exactly the same as in Takayuki Muranushi's message -- His question: ``Is there a way to represent this? -- For example, can we define earthMass'' , sunMass'' , marsMass'' all -- in separate modules, and yet have (length $ sunPerMars'' == 27) ? sunPerMars :: NonDet Double sunPerMars = (/) <$> sunMass <*> marsMass sunPerMars_run = runShare sunPerMars sunPerMars_run_len = length sunPerMars_run -- 27 -- The following is essentially Control.Monad.Sharing.Memoization -- with one important addition -- Can you spot the important addition? type NonDet a = StateT FirstClassStore [] a data Key = KeyDyn Int | KeySta TypeRep deriving (Show, Ord, Eq) -- I wish TypeRep were in Ord by default. The implementation permits that! instance Ord TypeRep where compare x y = compare (show x) (show y) data FirstClassStore = FirstClassStore { freshKey :: Int, store :: M.Map Key Dynamic } emptyStore :: FirstClassStore emptyStore = FirstClassStore { freshKey = 1, store = M.empty } getFreshKey :: MonadState FirstClassStore m => m Key getFreshKey = do key <- gets freshKey modify (\s -> s { freshKey = succ key }) return (KeyDyn key) insertVal :: (Typeable a, MonadState FirstClassStore m) => Key -> a -> m () insertVal key val = modify (\s -> s { store = M.insert key (toDyn val) (store s) }) lookupVal :: (Typeable a, MonadState FirstClassStore m) => Key -> m (Maybe a) lookupVal key = liftM (liftM (flip fromDyn err) . M.lookup key) (gets store) where err = error $ "lookupVal: bad key " ++ show key memo :: (Typeable a, MonadState FirstClassStore m) => m a -> m (m a) memo a = getFreshKey >>= \key -> return (memoKey key a) memoSta :: (Typeable a, MonadState FirstClassStore m) => TypeRep -> m a -> m a memoSta trep a = memoKey (KeySta trep) a memoKey :: (Typeable a, MonadState FirstClassStore m) => Key -> m a -> m a memoKey key a = do valM <- lookupVal key case valM of Just x -> return x Nothing -> do x <- a insertVal key $! x return x runShare :: Monad m => StateT FirstClassStore m a -> m a runShare m = evalStateT m emptyStore -- In My GHC, StateT is still not an Applicative. More bolierplate instance Monad m => Applicative (StateT s m) where pure = return (<*>) = liftM2 ($)

2 5

Cloud Haskell Appetiser: a taste of distributed programming in Haskell
by Eric Kow 21 Jul '12

21 Jul '12

HTML version: http://www.well-typed.com/blog/68 # Cloud Haskell Appetiser: (part 2 of Parallel Haskell Digest 11) Hello Haskellers! We mentioned in the [last digest][phd-11] that we'd have just a tiny bit more to say about Parallel Haskell. As promised, here is the completed word of month on *actors* and their use in Cloud Haskell. It so happens — what a coincidence! — that Well-Typed's Edsko de Vries has recently published a beta version of the new [distributed-process][dp-announce] implementation on Hackage. We'd love it if you could give it a try let us know any trouble you ran into or ways we could improve things. To help push things along a bit, this word of month will be using the new distributed-process implementation. Also, have you had a chance to fill out the Parallel Haskell Digest Survey? It's collecting data for another couple of weeks. Anything you can tell us in the survey will inform future efforts in building the Haskell community, so if you've got a couple of minutes before Cloud Haskell Time, head over to [Parallel Haskell Digest Survey](http://goo.gl/bP2fn) Many thanks! ## Word of the month The word of the month series has given us a chance to survey the arsenal of Haskell parallelism and concurrency constructs: * some low level foundations (sparks and threads), * three ways to do parallelism (parallel arrays, strategies, dataflow), * and some concurrency abstractions (locks, transactions, channels) The Haskell approach has been to explicitly recognise the vastness of the parallelism/concurrency space, in other words, to provide a multitude of right tools for a multitude of right jobs. Better still, the tools we have are largely interoperable, should we find ourselves with jobs that don't neatly fit into a single category. The Haskell of 2012 may be in a great place for parallelism and concurrency, but don't think this is the end of the story! What we've seen so far is only a snapshot of the technology as it hurtles through the twenty-tens (How quaint are we, Future Haskeller?). While we can't say what exactly the future will bring, we can look at one of the directions that Haskell might branch into in the coming decade. The series so far has focused on things you might do with a single computer, using parallelism to speed up your software, or using concurrency abstractions to preserve your sanity in the face of non-determinism. But now what if you have more than one computer? ### Actors Our final word of the month is *actor*. Actors are not specific to distributed programming; they are really more of a low level concurrency abstraction on a par with threads. And they certainly aren't new either. The actor model has been around since the 70s at least, and has been seriously used for distributed programming since the late 80s with Erlang. So what makes an actor an actor? Let's compare with threads +----------------------------------+---------------------------------+ | **Actor** | **Thread** | +==================================+=================================+ | can create more actors | can create more threads | +----------------------------------+---------------------------------+ | can have private local state | can have private local state | +----------------------------------+---------------------------------+ | has NO shared state | has limited shared state | | (isolated from other actors!) | | +----------------------------------+---------------------------------+ | communicates with other actors | communicates with other | | via asynchronous message passing | threads via shared variables | +----------------------------------+---------------------------------+ The essential difference between actors and threads is the isolation and message passing. There aren't any holes punched into lids here, but you can always shine a message from one jam jar to another, perhaps hoping they send you one of their own. The appeal of actors is thus a kind of simplicity, where avoiding shared state eliminates a class of concurrency bugs by definition, and where each actor can be reasoned about in isolation of its brethren. This sort of thing may perhaps strike a chord with us functional programmers, and actually, there is quite a bit of actor-related work in Haskell: a handful of packages offering the actor as concurrency primitive, Martin Sulzmann's [multi-headed twist][mh-actors] on the model; [Communicating Haskell Processes][chp] exploring an actor-ish cousin known as CSP. Finally, there's [Cloud Haskell][ch-pdf], which in explicit homage to Erlang, applies the actor model to distributed programming. ### Glimpse of Cloud Haskell We'll be taking a quick look at Cloud Haskell in this word of the month, unfortunately with only the most fleeting of glimpses. If squirting money between bank accounts is the transactional hello world, playing ping pong must surely be its distributed counterpart. Before working up to that, we first start with half a hello. The following example creates three processes — “process” is the Erlang-inspired word for the actor here — one which receives `Ping` messages and just prints them to screen, one which sends a single `Ping` message, and finally one which fires up the first two processes: {-# LANGUAGE DeriveDataTypeable #-} module Main where import Control.Concurrent ( threadDelay ) import Data.Binary import Data.Typeable import Control.Distributed.Process import Control.Distributed.Process.Node import Network.Transport.TCP -- Serializable (= Binary + Typeable) data Ping = Ping deriving (Typeable) instance Binary Ping where put Ping = putWord8 0 get = do { getWord8; return Ping } server :: ReceivePort Ping -> Process () server rPing = do Ping <- receiveChan rPing liftIO $ putStrLn "Got a ping!" client :: SendPort Ping -> Process () client sPing = sendChan sPing Ping ignition :: Process () ignition = do -- start the server sPing <- spawnChannelLocal server -- start the client spawnLocal $ client sPing liftIO $ threadDelay 100000 -- wait a while main :: IO () main = do Right transport <- createTransport "127.0.0.1" "8080" defaultTCPParameters node <- newLocalNode transport initRemoteTable runProcess node ignition This little package gives us a chance to look at three big pieces of Cloud Haskell, the `Serializable` typeclass, the `Process` monad, and channels. #### Serializable Actors send messages to each other. As programmers, we see the messages in nice high-level form (eg. `Ping`), but somewhere along the way, these messages are going to have to be encoded to something we can ship around on a network. Cloud Haskell makes this encoding explicit, but reasonably convenient at the same time. Things can be messages if they implement the `Serializable` typeclass, which is done indirectly by implementing `Binary` and deriving `Typeable`. You won't be starting from scratch, as implementations are already provided for primitives and some commonly used data structures. Things which don't make sense as messages are deliberately left unserializable, for example `MVar` and `TVar`, which are only meaningful in the context of threads with a shared memory. Our Cloud Haskell program is perfectly free to use these constructs within processes (or within processes on the same machine; a bit more on that below), just not to ship them around. #### Process We use “process” to mean “actor” in a similar fashion as Erlang, in other words nothing nearly so heavy as an operating system process. One different with Erlang, however, is that Cloud Haskell allows for both actor style concurrency and the thread-based approach. The infrastructure gears you towards using the actor model when talking across machines, but on the same machine, you could also conveniently do things the old way. Want to use STM to pass notes between processes? Fine, just spawn them locally via `spawnLocal` and give them a common `TVar`. As for the `Process` monad, we see again the idea of special monad either for special kinds of sequencing. Here the idea is that things like sending/receiving messages or spawning other processes only makes sense for processes, and so you can only do these things in a “process context”. `Process` implements `MonadIO`, though, so any input/output you'd like to do within a process is merely a `liftIO` away. Going the other way, running a process from IO, you would do with the `runProcess` function. #### Channels Cloud Haskell provides a notion of channels (somewhat similar to those we introduced in the last word of the month), typed unidirectional pipelines that go from one process to another. Using them is optional (there are simpler ways to bop messages back and forth), but worth trying out for the promise of sending messages only to processes that will understand them. Below is a quick glance at channels in action: data SendPort a -- Serializable data ReceivePort a -- NOT Serializable newChan :: Serializable a => Process (SendPort a, ReceivePort a) sendChan :: Serializable a => SendPort a -> a -> Process () receiveChan :: Serializable a => ReceivePort a -> Process a A channel comes with a send and receive port, both of which are parameterised on the same type variable. Creating a `Ping` channel thus gives a `ReceivePort Ping` out of which only `Ping`'s will ever emerge, and a `SendPort Ping` into which we can only put `Ping`'s. This looks a lot more attractive when you work with multiple channels. Replying to pings with pongs, for example, would require us to create a second channel with a send a receive port of its own, which means we have now 4 ports to juggle! Having the type distinctions makes things a bit clearer: `SendPort Ping` vs `ReceivePort Ping` vs `SendPort Pong`, vs `ReceivePort Pong`. Finally, it's worth noticing that `SendPort`'s are themselves Serializable, meaning that they can be copied and shipped around to other processes possibly on other computers. This allows a channel to accept data from more than one place, and also makes for idioms like including a reply-to `SendPort` in your messages. `ReceivePort`'s on the other hand are (deliberately) left unserializable which leaves them tied to single computer. ### Ping? What happened to Pong? Our little example was more “hello wo” than “hello world”; we'd only managed to send a `Ping` without even thinking about sending `Pong`'s back. Want to try your hand at Cloud Haskell? Here's a great opportunity! 1. **[Easy]** Start with a `cabal install distributed-process` and make sure you can run this example. Note that you'll need GHC 7.4.1 and up for this 2. **[Less easy]** Next, add a new `Pong` message (as a separate data type), extending the server to send this message back, and the client to receive that reply. There are some puzzle pieces to work through here. How does the server know where to send its replies? Moreover, how do we keep the server nice and decoupled from the client? We want it to receive pings from any client, and send a reply back to the ping'er (and not just some hard-coded client). Hint: you can solve this without touching `ignition` or `main`. Remember that `SendPort` is `Serializable`! 3. **[Easy]** You now have a single ping/pong interaction. Can you make the game go back and forth indefinitely (or until the `threadDelay` ends)? Hint: have a look at `Control.Monad`; it's not essential, but it's a bit nicer. ### Conclusion Stepping back from the technology a bit, we have introduced the notion of actors as a concurrency abstraction on a par with threads. While there's nothing that makes them specific to distributed programming, they do seem to fit nicely to the problem and have been used to great effect before. Cloud Haskell is one attempt to apply this actor model, taking some of the ideas from Erlang, and combining them with Haskell's purity and type system. You might notice that in a word of the month about distributed programming, we've kept things on a single machine, alas! Indeed, we have not been able to do Cloud Haskell justice in this article, but we have hopefully laid some foundations by introducing some of the basic layers, `Serializable` messages, processes, and channels. To escape from one-machine-island, we would need to get to grips with two more concepts, nodes and closures. Nodes can basically be thought of as separate machines (you could run multiple nodes on the same machine if you wanted to, say for development purposes). This makes for three layers: nodes (machines), which contain processes (actors), which can run any number of threads they wanted. We saw how processes can communicate by sending each other messages across channels; what we've left out is the crucial detail of what happens when the processes live on different nodes. The good news here is “nothing special”, still messages across channels. The bad news is a bit of infrastructural fiddliness setting up the nodes in the first place, assigning them to roles, and spawning remote processes… for which we need to know about closures. The basic story with closures is that we need to be able send functions back and forth in order to do anything really useful with Cloud Haskell, and to send functions we need to say how they are `Serializable`. This would be easy enough — assume for now that all nodes are running the same code and just send “run function `foo`” style instructions — were it not for the fact that Haskellers do all sorts of crazy things with functions all the time (partially applying them, returning them from other function…), crazy things that introduce free variables. Expressing the serializability of function-and-its-free-variables was a source of furious head-scratching for a while until somebody hit on the old Henry T. Ford idea: You can have any free variables you want so long as they are a ByteString. Where to from here? If you're looking for more introductory stuff and have not already seen, try Simon Peyton Jones's presentation of Cloud Haskell to the Scala community ([1h video][ch-skills]). Edsko has been hard at work at the [distributed-process Haddock][dp-haddock], so it's worth checking out when you're ready to roll up your sleeves and get hacking. It'd be a very good idea to have a look at the [simplelocalnet backend][simple], which will help you get started with the nitty gritty node management issues when you start yearning to go distributed. That's the practical stuff, but don't forget to read the [Cloud Haskell paper][ch-pdf] either! The API has some slight differences (for example, `ProcessM` has since been renamed to `Process`), but it should be fairly straightforwardly transferable to the new package. It's likely we'll need a wider spectrum of documentation to bring more Cloud Haskellers into the fold (early days, eh?). Hopefully this word of the month will help you get started, and maybe in turn write a blog post of your own? Happy Distributed Haskell'ing! [ch-github]: https://github.com/jepst/CloudHaskell [ch-pdf]: http://research.microsoft.com/en-us/um/people/simonpj/papers/parallel/remot… [ch-skills]: http://skillsmatter.com/podcast/home/haskell-cloud/js-4179 [chp]: http://www.cs.kent.ac.uk/projects/ofa/chp/ [dist-p]: https://github.com/haskell-distributed/distributed-process [dp-announce]: https://groups.google.com/d/topic/parallel-haskell/dw5UPEg1ePI/discussion [dp-haddock]: http://hackage.haskell.org/packages/archive/distributed-process/latest/doc/… [mh-actors]: http://sulzmann.blogspot.co.uk/2008/10/actors-with-multi-headed-receive.html [phd-11]: http://www.well-typed.com/blog/67 [simple]: http://hackage.haskell.org/packages/archive/distributed-process-simplelocal… [survey]: http://goo.gl/bP2fn -- Eric Kow <http://erickow.com>

1 0