- Haskell-Cafe - Haskell.org

Auto elimination of MVars using a monad or monad transformer.
by Chris Dew 26 Feb '11

26 Feb '11

Hello, just like everyone else, I have a question about monads. I've read the tutorials, written one monad myself (not in this email), but I still consider myself a Haskell beginner. * Does GHC eliminate unneeded MVars during compilation? I'm expecting that it doesn't, as that would mean optimising away ForkIOs, which would be quite a thing to do. I've included example code below. * Is there a monad which allows their automatic elimination of MVars (or their creation only when necessary)? This would be similar to how the IO monad allows you to do purely functional things with a do block, using let. I've had a go at a lifting function, which wraps a pure function into an IO action which forever reads from one MVar and writes to another. What I'm looking for is some form of Monadic context in which many pure functions, MVar fillers and MVar consumers could be linked together, where only the necessary MVars remain (or were created) at compilation time. * Would this be a monad, or a monad transformer? * Can you specialise a monad transformer on a single base (in this case IO) so that you can use forkIO in the bind or return? Thanks, Chris. module Main ( main ) where import Control.Concurrent (forkIO, MVar, newEmptyMVar, putMVar, takeMVar, ThreadId, threadDelay) import Control.Monad (forever) stepA :: MVar String -> IO () stepA boxa = forever $ do line <- getLine putMVar boxa line stepB :: MVar String -> IO () stepB boxb = forever $ do line <- takeMVar boxb putStrLn line -- This simply wraps a string in brackets. bracket :: String -> String bracket x = "(" ++ x ++ ")" -- This lifts a function into an action which forever performs the function -- between the two MVars given. lft :: (a -> b) -> MVar a -> MVar b -> IO () lft f c d = forever $ do x <- takeMVar c putMVar d (f x) -- Just like C's main. main :: IO () main = do box <- newEmptyMVar box2 <- newEmptyMVar forkIO $ stepA box forkIO $ lft bracket box box2 forkIO $ stepB box2 threadDelay 10000000 -- Sleep for at least 10 seconds before exiting.

2 1

Haskell platform installation failure on OS X 10.6.6 (intel)
by Eugene Kirpichov 26 Feb '11

26 Feb '11

Hello, Below is an experience report from Artem (cc'd) on a failed installation of Haskell platform on a Mac. OS: OS X 10.6.6 CPU: Intel Core i5 Platform downloaded from: http://lambda.haskell.org/hp-tmp/2010.2.0.0/haskell-platform-2010.2.0.0.i38… Sequence of actions: Downloaded the file, mounted the image, ran "Install new GHC", pressed OK until the following screen appeared http://i.imgur.com/GGdbg.png - there the Install button was disabled; pressing "change install location" did not help since only 1 option was available there, and it was already selected. After that, Artem tried to uninstall GHC, but unsuccessfully, since OS told that it was not installed. Then he tried to install the platform, and eventually got the following error around "moving files into place": http://i.imgur.com/YHb22.png I've also heard somewhat similar problem reports on installing haskell-platform on OS X from other people (I myself don't have it) - like being unable to install it without first installing XCode, etc. Can anyone help resolve this issue? I'm sure this is not expected behavior. What further information would help find the cause? -- Eugene Kirpichov Senior Software Engineer, Mirantis Inc. http://www.mirantis.com/

3 4

Haskell Platform install instructions
by Michael Snoyman 26 Feb '11

26 Feb '11

Hi everyone, Some of the dependencies for Yesod (such as haskell-src) require happy. For the "Yesod in Five Minutes" page[1], I've given instructions to cabal install happy and then cabal install yesod. However, as Xavier Shay pointed out to me, this won't actually work on a vanilla install, since happy gets installed in the cabal bin folder, which is not by default on the PATH. Two questions: * Should we document this somewhere in the Haskell Platform install process? I'm sure many old-time users of cabal are well aware that they need ~/.cabal/bin in the PATH, but new users will not be. I would also like to update Yesod's documentation; does anyone have standard phrasing that is applicable to all operating systems? * Should we consider modifying the build tools to automatically look for build dependencies in the cabal bin folder? Michael [1] http://docs.yesodweb.com/five-minutes

3 2

FFI: C-side object not destructed
by Yves Parès 26 Feb '11

26 Feb '11

Hello, I'm trying to use a C++ class in Haskell through C exports. It works all very well, except that when I call the function that deletes the object, it is still valid, I can still call methods on it. Here is my Haskell code: {-# LANGUAGE ForeignFunctionInterface #-} import Foreign import Foreign.C.Types newtype PKlass = PKlass (Ptr PKlass) foreign import ccall unsafe "Klass_Create" kCreate :: CInt -> CInt -> IO PKlass foreign import ccall unsafe "Klass_Destroy" kDestroy :: PKlass -> IO () foreign import ccall unsafe "Klass_GetX" kGetX :: PKlass -> IO CInt foreign import ccall unsafe "Klass_GetY" kGetY :: PKlass -> IO CInt foreign import ccall unsafe "Klass_AddKlass" kAdd :: PKlass -> PKlass -> IO PKlass main = do k <- kCreate 4 5 kDestroy k *kGetY k >>= print -- This shouldn't work* k' <- kCreate 2 8 k'' <- k `kAdd` k' kDestroy k'' *kGetY k'' >>= print -- This neither* So it is very basic, and I can't understand why the supposedly destroyed objects are still here. Enclosed is all the source code (C++ class, C exportation and the Haskell main hereabove). I compile it this way: ghc --make main.hs *.cpp -lstdc++

4 4

Either instance of Monad?
by Yves Parès 26 Feb '11

26 Feb '11

Hello, When importing Control.Monad.Error, it shows me that (Either e) is an instance of MonadFix, but not an instance of Monad. Isn't there a problem?

2 9

Fun with the ST monad
by Andrew Coppin 26 Feb '11

26 Feb '11

OK, so I had a function that looks like transform :: [Word8] -> [Word16] It works nicely, but I'd like to use mutable state inside. No problem! Use the ST monad. Something like transform :: [Word8] -> [Word16] transform xs = runST (work xs) where work :: [Word8] -> ST s [Word16] Ah, yes, well there is one *small* problem... If you do that, the function becomes too strict. The input list is being read from disk by lazy I/O. With the original implementation, the input file gets read at the same time as the output file is written. But runST returns nothing until the *entire* input has been compressed. So writing to disk doesn't start until the entire file has been slurped up into memory. Anybody have any hints on how to get around this? My first thought was to break the ST computation into several seperate pieces. But, /by design/, you cannot do this. And here's why: main = do let r = runST $ newSTRef 0 let x = runST $ n <- readSTRef r; writeSTRef r (n+1); return n let y = runST $ n <- readSTRef r; writeSTRef r (n*2); return n print x print y Now what the hell does this print out? Because it appears, logically, that it ought to vary depending on the order in which x and y are accessed - a clear violation of referential integrity. Fortunately of course, by a clever dodge, this code doesn't actually type-check. That's great, because it has undefined semantics. But it's also a problem, since it's exactly the sort of thing I'd like to do. Come to think of it, how the heck does lazy I/O manage this trick? How come accessing the elements of the list in the wrong order doesn't cause the wrong data to end up in each cell, if each cell is just using unsafePerformIO to read the next byte from a normal file handle?

8 13

best way to deal with #defines when developing ffi's
by briand＠aracnet.com 26 Feb '11

26 Feb '11

Hi all, I'm working on an FFI and as usual there are lots of defines in the header files. What's the best way to make these available to the haskell code ? Ideally it could be done automagically, or at least pseudo-magically so that keeping up with changes to the .h wouldn't be too painful. I'm talking about simple constant defines, nothing tricky like structures or similar. Thanks, Brian

4 3

Proxy for cabal
by Hauschild, Klaus (EXT) 25 Feb '11

25 Feb '11

Hi, Is it possible to configure a proxy server for cabal? When yes, how I configure it? Thanks.

1 1

ANNOUNCE: htime-0.1
by José Pedro Magalhães 25 Feb '11

25 Feb '11

Hello all, I kept being annoyed at the fact that Windows doesn't come with anything similar to the unix "time" utility, so I created a small Haskell program that does something similar. I thought this could perhaps be useful to others, so it's now available on Hackage: http://hackage.haskell.org/package/htime-0.1 Cheers, Pedro

1 0

Re: [Haskell-cafe] HANSEI in Haskell?
by oleg＠okmij.org 25 Feb '11

25 Feb '11

The topic of HANSEI in Haskell does come up from time to time. In fact, there was a Haskell edition of the first version of Hansei: http://okmij.org/ftp/kakuritu/probM.hs It was written to see how the code would look in Haskell, and how memoization (inherent in lazy evaluation of GHC) may help. The code contains some of the tests from the HANSEI distribution. The experience showed that lazy evaluation hurts -- a lot. The problem is not in lack of seq -- adding seq would make things even worse. There is a bit of explanation at the end of probM.hs. The gist of the problem is that approximate inference (sampling, to be precise) trades space for time. The search tree is way too large to fit into memory. Therefore, it is better to recompute the values (the branches of the tree) than to keep storing them. That is precisely the opposite to the trade-off of lazy evaluation. The end result is attempting to allocate gigabytes (really!), even for toy problems. We can get around the problem by using thunks explicitly. But then we lose the remaining benefits of Haskell syntax (the ones that are left after we have to switch to the monadic notation). OCaml becomes quite compelling then. It must be stressed that laziness in general is _crucial_ for solving even moderately complex problems. However, the needed laziness is NOT of the kind provided by GHC. We need memoization specific to a possible world, rather than the one that affects all possible worlds. GHC gives only the latter. The sort of laziness needed for non-deterministic programming calls for first-class store. It can be emulated, albeit imperfectly, for example, as was described in the ICFP09 paper. Hansei uses a quite similar idea. Ideally first-class memory is provided as built-in, since it requires interaction with garbage collection. Greg Morrisett has written extensively on this topic and done a few implementations; see for example, http://www.eecs.harvard.edu/~greg/papers/jgmorris-callcs.ps Sadly, the topic has been forgotten.

4 5