April 2007 - Haskell-Cafe

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

Re: [Haskell-cafe] implementing try for RWST ?
by tpledger＠ihug.co.nz 16 Apr '07

16 Apr '07

Jeremy Shaw wrote: : | However, I think this is buggy, because changes | to 's' and 'w' will be lost if 'm' raises an | exception. : That's determined by the way you stack your monad transformers when declaring the type: adding error handling to a writer monad, or adding writing to an error handling monad. For a concrete example, see the result types in the following. The first has the Either inside the tuple, and the second has the tuple inside the Either. Prelude> :t Control.Monad.Writer.runWriter . Control.Monad.Error.runErrorT Control.Monad.Writer.runWriter . Control.Monad.Error.runErrorT :: Control.Monad.Error.ErrorT e (Control.Monad.Writer.Writer w) a -> (Either e a, w) Prelude> :t either Left Right . Control.Monad.Writer.runWriterT either Left Right . Control.Monad.Writer.runWriterT :: Control.Monad.Writer.WriterT w (Either a) a1 -> Either a (a1, w) Regards, Tom

2 1

Re: [web-devel] A light-weight web framework
by Ricardo Herrmann 16 Apr '07

16 Apr '07

The maintenance nightmare happens when someone uses the embedded language to specify business logic, and that's entirely the web-{developer,designer}'s fault. Thus, the problem is not that these languages shouldn't be powerful enough. IMHO, a safe approach would be simply not allowing I/O inside templates (hey, sounds familiar ;-) On 4/5/07, Maurice Codik <maurice.codik(a)gmail.com> wrote: > > A few things, some of which I sort of mentioned in my previous email: > > - If I'm already going to commit some time to learn a templating language, > why dont I just spend that same amount of time learning the little bit of > haskell I need to make the template work? If thats too much to ask, I can > just spit out HTML, and have the programmer put in the dynamic parts for me. > Both of these scenarios seem to be a more efficient use of time. > > - Who is the target audience? If its a big organization where there are > multiple designers and multiple devs, then your approach may work just fine. > If its the single developer, then something like what David suggested would > work even better. If its a small team (which may or may not include a > full-time designer), then something like what I suggested would work best. > For a web framework for haskell, I would guess that the latter two are much > more likely. > > - Embedding a real programming language in a template already gives you > power to do what ever you need to do. What if you need to implement some > logic that the template language doesnt support? In those cases, you're > usually out of luck and have to move that logic into a controller, where it > doesnt really belong (assuming its actual display logic, not business > logic). > > - It's really just a matter of taste. Any web framework thats worth using > should be flexible in its support of view technologies, but come with one > thats a sensible default. > > Maurice > > On 4/5/07, Joel Reymont <joelr1(a)gmail.com> wrote: > > > > Do you see anything wrong with the approach I suggested, though? > > > > On Apr 5, 2007, at 6:16 PM, Maurice Codik wrote: > > > > > That's not necesarily true. Templates where there is mostly markup, > > > but let you embed code into them using special tags (ex, <% code % > > > >) are extremely popular and work fairly well. They also keep the > > > template language simple because there is already a full-powered > > > programming language thats embedded into it. Good examples of this > > > method are ERB templates in Rails, JSPs, Perl Mason templates, etc. > > > > -- > > http://wagerlabs.com/ > > > > > > > > > > > > > > > -- > http://blog.mauricecodik.com > _______________________________________________ > web-devel mailing list > web-devel(a)haskell.org > http://www.haskell.org/mailman/listinfo/web-devel > > -- Ricardo Guimarães Herrmann "Any sufficiently complicated C or Fortran program contains an ad hoc, informally specified, bug-ridden, slow implementation of half of Common Lisp" "Any sufficiently complicated Lisp or Ruby program contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of Haskell"

5 5

Fwd: [Haskell-cafe] Tutorial on Haskell
by Ryan Dickie 16 Apr '07

16 Apr '07

Blast.. i didn't hit "reply all" so here's a forward of my mail to the group... --ryan ---------- Forwarded message ---------- From: Ryan Dickie <goalieca(a)gmail.com> Date: Apr 16, 2007 4:24 PM Subject: Re: [Haskell-cafe] Tutorial on Haskell To: Simon Peyton-Jones <simonpj(a)microsoft.com> I can tell you what me and my colleagues would be interested in (though none of us are actually going). We code a lot of math. You may call it scientific computing. Haskell seems like a natural fit for the task. In particular we are interested in: 1) the type system 2) concurrency (can these be set to run on a large system) 3) simple relation between what equations we write on paper, and what equations we write in haskell. I'm still a n00b to Haskell. For us languages like matlab, maple, etc. do not fit the job very well and run too slowly. C/C++ is usually what i use but it can be a pain. Python, etc... well its good for the glue i suppose. Haskell might fit that niche. On 4/16/07, Simon Peyton-Jones <simonpj(a)microsoft.com> wrote: > > Friends > > I have agreed to give a 3-hr tutorial on Haskell at the Open Source > Convention 2007 > http://conferences.oreillynet.com/os2007/ > > I'm quite excited about this: it is a great opportunity to expose Haskell > to a bunch of smart folk, many of whom won't know much about Haskell. My > guess is that they'll be Linux/Perl/Ruby types, and they'll be practitioners > rather than pointy-headed academics. > > One possibility is to do a tutorial along the lines of "here's how to > reverse a list", "here's what a type is" etc; you know the kind of > thing. But instead, I'd prefer to show them programs that they might > consider *useful* rather than cute, and introduce the language along the > way, as it were. > > So this message is to ask you for your advice. Many of you are exactly > the kind of folk that come to OSCON --- except that you know Haskell. So > help me out: > > Suggest concrete examples of programs that are > * small > * useful > * demonstrate Haskell's power > * preferably something that might be a bit > tricky in another language > > For example, a possible unifying theme would be this: > http://haskell.org/haskellwiki/Simple_unix_tools > > Another might be Don's cpu-scaling example > http://cgi.cse.unsw.edu.au/~dons/blog/2007/03/10<http://cgi.cse.unsw.edu.au/%7Edons/blog/2007/03/10> > > But there must be lots of others. For example, there are lots in the blog > entries that Don collects for the Haskell Weekly Newsletter. But I'd like > to use you as a filter: tell me your favourites, the examples you find > compelling. (It doesn't have to be *your* program... a URL to a great blog > entry is just fine.) Of course I'll give credit to the author. > > Remember, the goal is _not_ "explain monads". It's "Haskell is a great > way to Get The Job Done". > > Thanks! > > Simon > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe(a)haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe >

1 0

Re: `Expect'-like lazy reading/Parsec matching on TCP sockets
by Scott Bell 16 Apr '07

16 Apr '07

Ooops! It seems that this doesn't behave well with a -threaded RTS. I get an EOF on handles that I know for a fact shouldn't be receiving them. It still works well without -threaded, but does anyone know why I'm getting this behavior? hGetContentsTimeout :: Handle -> Int -> IO String hGetContentsTimeout h t = do hSetBuffering stdin NoBuffering ready <- hWaitForInput h t if (not ready) then return [] else do c <- hGetChar h s <- unsafeInterleaveIO (hGetContentsTimeout h t) return (c:s) (I did add EOF checking, but all that did was return the end of the list earlier than I wanted)

3 4