- Haskell-Cafe - Haskell.org

Tutorial on Haskell
by dfeustel＠mindspring.com 18 Apr '07

18 Apr '07

What would be really useful is a Haskell Cookbook that shows how to do in Haskell things that are so easily done in imperative languages. How to solve simultaneous equations using Gaussian elimination comes to mind. Lots of examples would be great. Dave Feustel

2 1

Haskell job
by Lennart Augustsson 18 Apr '07

18 Apr '07

Hi all, Credit Suisse has started using Haskell within GMAG, the group that provides financial analytics for the bank. The main use of Haskell is for a Domain Specific Embedded Language that is being used by the people writing the financial analytics (these people typically have a PhD in mathematics or physics). We are looking to extend our Haskell group (which currently is me and Ganesh Sittampalam), so if you're an experienced Haskell person take the chance! Here's a URL to the Credit Suisse job ad: https://creditsuisse.taleo.net/servlets/CareerSection? art_ip_action=FlowDispatcher&flowTypeNo=13&pageSeq=2&reqNo=53820&art_ser vlet_language=en&selected_language=en&csNo=10020#topOfCsPage If you have any questions email Howard Mansell, howard.mansell@credit- suisse.com, or me. -- Lennart

1 0

Re: Release plans
by Brandon Michael Moore 18 Apr '07

18 Apr '07

On Tue, Apr 17, 2007 at 12:50:48PM +0200, Doaitse Swierstra wrote: > Just to show what kind of problems we are currently facing. The > following type checks in our EHC compiler and in Hugs, but not in the > GHC: > > module Test where > > data T s = forall x. T (s -> (x -> s) -> (x, s, Int)) > > run :: (forall s . T s) -> Int > run ts = case ts of > T g -> let (x,_, b) = g x id > in b Consider this additional code which also typechecks in Hugs: v :: forall s . T s v = T f f :: s -> ([s] -> s) -> ([s], s, Int) f v g = let x = [v] in (x, g x, 0) due to parametricity, run v can't depend on x or g x. Apparently id has type [x] -> x. Are EHC and Hugs supposed to support equirecursive types? Brandon

1 1

unsafeInerleaveIO and randomIO
by Marc Weber 17 Apr '07

17 Apr '07

stefan has pointed me a nice version: ============= ======================================================= randomInts :: IO [Int] randomInts = randoms `fmap` newStdGen main = do ints <- randomInts print $ take 5 ints =========== ========================================================= Anyway I'm curious why ============= ======================================================= module Main where import Data.Char import Control.Monad import Random import System.IO.Unsafe randomInts :: IO [Int] randomInts = unsafeInterleaveIO $ sequence $ cycle [unsafeInterleaveIO randomIO] main = do ints <- unsafeInterleaveIO randomInts print $ take 5 ints ============= ======================================================= doesn't return. Where did I miss another unsafeInerleaveIO to make it lazy enough? I still need a hint. Marc

3 3

implementing try for RWST ?
by oleg＠pobox.com 17 Apr '07

17 Apr '07

The examples presented so far seem to show that the computation will eventually run in the IO monad. One may wonder then why do we need RWST transformer, given that the IO monad can implement both the state and writer. At the very least me need the reader transformer, which is the least demanding monad. We can do away with the reader as well, depending on the circumstances (e.g., one may use implicit parameters or implicit configurations, or just pass IORefs). The pure IO or ReaderIO solution has, besides simplicity, the advantage of being more expressive. Monad transformers, besides inefficiency, impose the rigid layering of effects, and so cannot express some useful computations. The drawbacks of monad transformers and their limited expressivity are not often discussed, unfortunately. The following code shows Jeremy Shaw's example, with both persistent and backed out state. The combinator tryC handles the exception and preserves the state accumulated at the point of exception. In contrast, tryBC undoes the changes to the state in case of exception. Both combinators have their uses. module T where import Control.Monad.Reader import Data.IORef import Control.Exception import Prelude hiding (catch) type ReaderIO a v = ReaderT a IO v type StateIO a v = ReaderIO (IORef a) v type Counter = Integer -- |Increment the counter by 1 incIO :: StateIO Counter () incIO = do cref <- ask c <- liftIO $ readIORef cref let c' = c + 1 liftIO $ writeIORef cref c' liftIO $ putStrLn ("Incrementing counter to: " ++ show c') -- get the current value of the counter getC :: StateIO Counter Counter getC = ask >>= liftIO . readIORef -- Try that preserves the state tryC :: ReaderIO a v -> (Exception -> ReaderIO a v) -> ReaderIO a v tryC action onerr = do r <- ask liftIO $ catch (runReaderT action r) (\e -> runReaderT (onerr e) r) -- Try that backs up the state tryBC :: StateIO a v -> (Exception -> StateIO a v) -> StateIO a v tryBC action onerr = do r <- ask oldstate <- liftIO $ readIORef r liftIO $ catch (runReaderT action r) (\e -> do writeIORef r oldstate runReaderT (onerr e) r) -- The run function runC :: Counter -> StateIO Counter v -> IO v runC v a = newIORef v >>= runReaderT a test = runC 0 (do incIO v <- tryC (die >> (return $ Right "ok")) (return . Left . show) c <- getC -- get the resulting counter liftIO $ print (v,c)) where -- |increment the counter by one and then die die = incIO >> error "die!" {- *T> test Incrementing counter to: 1 Incrementing counter to: 2 (Left "die!",2) -} -- the same but with backtrackable state test2 = runC 0 (do incIO v <- tryBC (die >> (return $ Right "ok")) (return . Left . show) c <- getC liftIO $ print (v,c)) where -- |increment the counter by one and then die die = incIO >> error "die!" {- *T> test2 Incrementing counter to: 1 Incrementing counter to: 2 (Left "die!",1) -}

3 2

GHC 6.7 and Associated Types
by Maxime Henrion 17 Apr '07

17 Apr '07

Hello guys, I've been documenting myself on associated types, which look like a very nice way to deal with the problems that arise with multi-parameter type classes. As an exercise, I am trying to rewrite the MonadState type class from the mtl package without functional dependencies. Here is my (probably very naive) approach : class MonadState m where type StateType m :: * get :: m StateType put :: m StateType -> m () As for instances: instance MonadState (State s) where type StateType = s -- this is line 22 get = State $ \s -> (s, s) put s = State $ \_ -> ((), s) I think I'm probably doing some very stupid thing and missing important points. In any case, here's the error I get : State.hs:22:19: Not in scope: type variable `s' Failed, modules loaded: none. I'd be happy to be explained why this doesn't make sense, and how I should proceed to implement this correctly. I have tried various other approaches with no luck yet. Thanks, Maxime

3 6

>> and sequencing [newbie]
by David Powers 17 Apr '07

17 Apr '07

so... this is likely a question based on serious misunderstandings, but can anyone help me understand the exact mechanism by which monads enforce sequencing? Specifically, I'm confused by the >> operator. If I understand things properly f a >> g expands to something like: f >>= \_ -> g What I'm missing is how the expansion of f is ever forced under lazy evaluation. Since the result is never used, doesn't it just stay as a completely unevaluated thunk? Come to think of it... how is it that some IO actions sequence completely, while others manage to work in a lazy manner? My suspicion is that somehow the order of evaluation in Haskell gives the outermost expression a "first crack" at evaluation in all circumstances (e.g. http://users.aber.ac.uk/afc/stricthaskell.html#cps) , but that it somehow stops short of a forced deep sequencing... Which is all to say, I have no idea how the magic happens. -David

5 7

Efficient use of ByteString and type classes in template system
by Johan Tibell 17 Apr '07

17 Apr '07

Hi Haskell Café! I'm writing a perl/python like string templating system which I plan to release soon: darcs get http://darcs.johantibell.com/template The goal is to provide simple string templating; no inline code, etc.. An alternative to printf and ++. Example usage: > import qualified Data.ByteString as B > import Text.Template > > helloTemplate = "Hello, $name! Would you like some ${fruit}s?" > helloContext = [("name", "Johan"), ("fruit", "banana")] > > test1 = B.putStrLn $ substitute (B.pack helloTemplate) helloContext I want to make it perform well, especially when creating a template once and then rendering it multiple times. "Compiling" the template is a separate step from rendering in this use case: > compiledTemplate = template $ B.pack helloTemplate > > test2 = B.putStrLn $ render compiledTemplate helloContext A template is represented by a list of template fragments, each fragment is either a ByteString literal or a variable which is looked up in the "context" when rendered. > data Frag = Lit ByteString | Var ByteString > newtype Template = Template [Frag] This leads me to my first question. Would a lazy ByteString be better or worse here? The templates are of limited length. I would say the length is usually between one paragraph and a whole HTML page. The Template data type already acts a bit like a lazy ByteString since it consists of several chunks (although the chunck size is not adjusted to the CPU cache size like with the lazy ByteString). Currently the context in which a template is rendered is represented by a type class. > class Context c where > lookup :: ByteString -> c -> Maybe ByteString > > instance Context (Map String String) where > lookup k c = liftM B.pack (Map.lookup (B.unpack k) c) > > instance Context (Map ByteString ByteString) where > lookup = Map.lookup > > -- More instance, for [(String, String)], etc. I added this as a convenience for the user, mainly to work around the problem of not having ByteString literals. A typical usage would have the keys in the context being literals and the values some variables: > someContext = Map.fromList [("name", name), ("fruit", fruit)] I'm not sure if this was a good decision, With this I'm halfway to the (in)famous Stringable class and it seems like many smarter people than me have avoided introducing such a class. How will this affect performace? Take for example the rendering function: > render :: Context c => Template -> c -> ByteString > render (Template frags) ctx = B.concat $ map (renderFrag ctx) frags > > renderFrag :: Context c => c -> Frag -> ByteString > renderFrag ctx (Lit s) = s > renderFrag ctx (Var x) = case Text.Template.lookup x ctx of > Just v -> v > Nothing -> error $ "Key not found: " ++ (B.unpack x) How will the type dictionary 'c' hurt performance here? Would specializing the function directly in render help? > render (Template frags) ctx = B.concat $ map (renderFrag f) frags > where f = flip Text.Template.lookup ctx > > renderFrag f (Var x) = case f x of I can see the implementation taking one of the following routes: - Go full Stringable, including for the Template - Revert to Context = Map ByteString ByteString which was the original implementation. - Some middle road, without MPTC, for example: > class Context c where > lookup :: ByteString -> c ByteString ByteString -> Maybe ByteString This would allow the user to supply some more efficient data type for lookup but not change the string type. Having a type class would allow me to provide things like the possibility to create a Context from a record where each record accessor function would server as key. Something like: > data Person { personName :: String, personAge :: Int } would get converted (using Data?) to: > personContext = [("personName", show $ personName aPerson), > ("personAge", show $ personAge aPerson)] but not actually using a Map but the record itself. I guess my more general question is: how do I reason about the performance of my code or any code like this? Are there any other performance improvements that could be made? Also, I would be grateful if someone could provide some feedback on the implementation, anything goes! I still have some known TODOs: - Import error messages for invalid uses of "$". - Improve the regex usage overall. - Add some more functions; the plan is to add those function which could be expressed in efficiently with the current interface. An example is things like renderAndWrite, when writing doing a B.concat first is unnecessary. Cheers, Johan Tibell

3 3

multithreading speedup
by Fawzi Mohamed 17 Apr '07

17 Apr '07

I was trying to speed up a program that I wrote and so I thought about using multiple threads. I have a quite easy parallel program and I did the following do subRes <- MVar.newMVar [] putStrLn "starting threads" subV <- flip mapM [0 .. (nThreads - 1)] $ ( \i -> do subR <- MVar.newEmptyMVar let writeRes r = do { MVar.putMVar subR r } forkOS (do let r=eval (startData !! i) writeRes $! r putStr $ "writtenRes") return subR ) putStrLn "started threads" toFold <- mapM MVar.takeMVar subV putStrLn "about to fold" return $ foldl1 mergeRes toFold I know that the threads really calculate what I want, and as soon as they are finished I get the result. The problem is that I have no speed up, the time is basically the sum of the time for the two threads. I thought that ghc now would take advantage of the two cpus if I compiled with -threaded. Am I wrong, do I need some special flag, a newer version of the compiler (I have 6.6.20070129), or it is just normal? Thanks Fawzi

4 7

Partial parsers in Happy
by Juan Carlos Arevalo Baeza 17 Apr '07

17 Apr '07

Hi! I'm trying to use a partial monadic parser with Happy (using %partial %monad and %lexer). The problem is that the parser function always seems to eat up one token beyond the matched sequence regardless of what I do. So I can't, for instance, call the parser multiple times to parse a series of blocks, because after the first block is done, it misses the first token of the second block. I'm sure this has to have come up for someone before, but I've been unable to find any references. JCAB

2 2