October 2010 - Haskell-Cafe

profiling cabal libraries
by Tom Hawkins 19 Oct '10

19 Oct '10

How do I profile cabal libraries? I "cabal install -p" a local package I am testing, and I compile a test of the library using "-prof -auto-all". But the profiling report only lists a CAF entry for the library, but does not detail any of the library's top level functions. What am I doing wrong? -Tom

3 2

Re: [Haskell-cafe] Haskellers.com skills list moderation?
by Michael Snoyman 19 Oct '10

19 Oct '10

Hey JP, It's a tough question you're asking. I think areas directly applicable with Haskell, such as bioinformatics, games, physics simulations, are a pretty easy yes. Some more complicated things would be "related skills", such as knowing other programming languages, system administration, etc. I would like to hear the cafe's opinion on that; my gut feeling is a "yes is moderation." Having a web programming skill seems OK, but I wouldn't want to put in HTML5, Javascript, CSS 3 and so on as separate skills. Michael On Tue, Oct 19, 2010 at 3:45 PM, JP Moresmau <jpmoresmau(a)gmail.com> wrote: > Are skills only Haskell related? I mean, are they only subcategories of > "haskell programming". Because "bioinformatics" is there, and in that case > it shouldn't be. If skills include any application domain where people might > use Haskell, the list will be much bigger, and surely the Hackage categories > can be of use (for example, for me, I would request Games, Artificial > Intelligence...). > And, thanks for doing haskellers, great work! One day I want to really do a > web application in Haskell and I'll sure give a go to yesod. > JP > > On Tue, Oct 19, 2010 at 3:32 PM, Michael Snoyman <michael(a)snoyman.com> > wrote: >> >> Alright, adding skills is now only possible by an admin. In the place >> where we previously had "add a skill", we now have "request a new >> skill." That's the easy part. Now we need to determine which skills >> stay, and which ones go. I think the vast majority of them are fine, >> so I'll leave them at the end of this email. If anyone thinks I'm >> being to generous by allowing a specific still to say, just say so. >> >> There's only two skills which I think absolutely must go: >> >> Other languages I know: C# .NET, XSLT, Microsoft SQL Server, XML, SQL, >> CSS, C, C++, Java, HTML, Visual Basic Script, Pascal, Rexx, Basic and >> assembler >> tool building >> >> There are 11 skills I'm leaning towards dropping, all because they >> fall in the too vague/too general category. Your input is requested on >> these. They are: >> >> Attribute Grammar >> Cabal, packaging, build and distribution tools >> Categorical Programming >> Denotational design >> Digital Forensics >> Fault Tolerant Server Software >> Mathematics >> Programming using Arrows >> Proving observational equivalence between Haskell programs >> Transactional business applications development >> UNIX Scripting and Tool Authoring >> >> Of the remaining 32 skills, some of them fall in the "too specific" >> range just a bit (software transactional memory, property based >> testing), but I'm inclined to let it slide. These 32 are: >> >> Advanced type-level programming (GADTs, TypeFamilies, proofs, etc.) >> Algorithmic Problem Solving >> Bioinformatics >> Concurrent Haskell >> DSL Design >> Darcs internals >> Foreign Function Interface (FFI) >> Formal Verification >> Functional graphics programming (2D, 3D, GPU) >> GHC internals >> Generic Programming >> Graphical User Interfaces >> Happstack Web Framework >> Hardware Acceleration DSLs >> Haskell on embedded devices >> High Assurance Software Development >> High-performance Haskell >> Metaprogamming via Template Haskell >> Natural Language Processing (tagging, parsing, translation,...) >> Physics & Simulation >> Programming language translation >> Property based testing (QuickCheck) >> Purely functional data structures — design and implementation >> Reverse Engineering >> Robotics and Automation >> Signal Processing >> Software Transactional Memory >> Teaching Haskell >> Web development (HTML, CSS and Javascript) >> Yesod Web Framework >> >> Michael >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe(a)haskell.org >> http://www.haskell.org/mailman/listinfo/haskell-cafe > > > > -- > JP Moresmau > http://jpmoresmau.blogspot.com/ >

1 0

A State Monad Tutorial
by Artyom Kazak 19 Oct '10

19 Oct '10

Some time ago I have read A State Monad Tutorial (http://strabismicgobbledygook.wordpress.com/2010/03/06/a-state-monad-tutori…) While reading, I was fixing some minor mistakes (okay, a lot of mistakes). After all, I had an idea to create PDF with fixed version. So, here it is: http://dl.dropbox.com/u/8662438/A%20State%20Monad%20Tutorial.pdf

1 0

Re: MonadCatchIO, finally and the error monad
by Paolo Losi 19 Oct '10

19 Oct '10

Thanks for you reply, Michael. See inline ... On Mon, Oct 18, 2010 at 11:21 AM, Michael Snoyman > > > > > As an haskell newbie, I've got some questions on this matter. > > > > Is it using ErrorT instead of extensible exeptions really necessary? > > I've read your comment stating that we cannot pass function arguments > > to Exceptions because of the Show class constraint. > > But is that really limiting? Wouldn't your use case (e.g. > > HTTP redirection in Yesod) be implementable with extensible exceptions? > > > > I would guess that the rule of thumb would be not to mix > > extensible exception and ErrorT whenever it is possibile. > > > > I've quickly read your post on inverting transformer stacks > > and, from my newbie point of view, I feel that the extra complexity > > isn't worth the gain. > > I'm not sure why you think inverting the ErrorT monad is more > complicated than MonadCatchIO: they're both doing basically the same > thing. The difference is that MonadInvertIO does this generically for > a whole class of functions, and therefore does it right. I could have written MonadCatchIO, I could not have written InvertIO :-) > Anyway, it *is* theoretically possible to use extensible exceptions > anywhere you would use ErrorT, but there's always a runtime hit in > using runtime exceptions. Also, it's a difference in philosophy: > coming from a language like Python or Ruby, it may feel natural to use > exceptions for these kinds of cases. In Haskell, we try to make > exceptions respect their name, and only use them in exceptional > circumstances. Is the performance penalty of using runtime exception so high? I would sacrifice some bits of performance for a more consistent error reporting / flow control. For the argument that Exceptions are for exceptional cases I'm totally with David MacIver [1]. I perfectly see the point of using ErrorT, but not when you need to handle runtime exceptions as well. As an haskell newbie I think that _THIS_, error handling strategies, is the single most troublesome point where some consistency (at least as a best practice) is really needed. I had hopes that extensible execptions could clarify the issue raised by [2] at least in "new" code... Thank again Paolo [1] http://www.drmaciver.com/2009/03/exceptions-for-control-flow-considered-per… [2] http://www.randomhacks.net/articles/2007/03/10/haskell-8-ways-to-report-err…

3 4

Fwd: [Haskell-cafe] Happstack, RqData: (How) can I extract multiple data from form?
by Никитин Лев 18 Oct '10

18 Oct '10

-------- Пересылаемое сообщение -------- 18.10.10, 23:58, "Никитин Лев" <leon.v.nikitin(a)pravmail.ru>: -------- Пересылаемое сообщение -------- 18.10.10, 23:57, "Никитин Лев" : Well. Thanks. I've just have a look at formlets. I think is what i need. But I'm using now HSP. Are formlets integrated with HSP? (I saw olny using formlets with text.xhtml). And [after discussion of "Web" wiki page] what is props and cons of using HSP? For newbiers it will be good idia to include some comparison between web frameworks, templating systems etc. (their props and cons). > The following looks like something that you might want: > http://hackage.haskell.org/packages/archive/formlets/0.7.3/doc/html/Text-Fo… > See the source for more clues about its use: > http://hackage.haskell.org/packages/archive/formlets/0.7.3/doc/html/src/Tex… > More about the Formlets library here: > http://www.haskell.org/haskellwiki/Formlets > -------- Завершение пересылаемого сообщения -------- -------- Завершение пересылаемого сообщения --------

2 1

An interesting paper on VM-friendly GC
by Andrew Coppin 18 Oct '10

18 Oct '10

Somebody showed me this the other day, and I thought it was interesting: http://www.cs.umass.edu/~emery/pubs/f034-hertz.pdf Basically, "we designed a garbage collector which tries to avoid touching memory pages that have been swapped out to disk just because we need to do a GC sweep". Which is a pretty obvious thing to do, when you think about it, and has several obvious performance implications. Maybe we should think about how GHC handles this? On the other hand, their implementation uses a modified Linux kernel, and no sane person is going to recompile their OS kernel with a custom patch just to run Haskell applications, so we can't do quite as well as they did. But still, and interesting read...

6 7

Happstack, RqData: (How) can I extract multiple data from form?
by Никитин Лев 18 Oct '10

18 Oct '10

Hello. (How) can I query multiple data from form? Foor form ala <form> <input name="foo"/> <input name="foo"/> /form> I can use 'looks "foo"' to get array of values. Ok. But Is there any way to extract values from such form: <form> <input name="key" val="key1"/><input name="tag" val="tag11/><input name="tag" val="tag12/>... <input name="key" val="key2"/><input name="tag" val="tag21/><input name="tag" val="tag22/>... /form> to get something like [("key1", ["tag11", "tag12"]), ("key2", ["tag21", "tag22"]) ] ? One of requirement is possibility to add additionally key and tags for this key (via button, using javascript). Can I groupe such pairs using html? Maybe I have to do like this: <form> <input name="key" val="key1"/><input name="tag-key1" val="tag11/><input name="tag-key1" val="tag12/> <input name="key" val="key2"/><input name="tag-key2" val="tag21/><input name="tag-key2" val="tag22/> /form>, but i dont see any (simple) way to add dinamicly add other list of keyed tags in such manner (by user, o client side).

2 1

Make with Version
by Jonas Fager 18 Oct '10

18 Oct '10

Hi. If you use ghc --make the autodepend do all the heavy-lifting for you but what's the way to work when you have two versions of a package and you have code compatible with both version? Is it possible to combine --hide-package with --make to compile old code against old package version? //Jonke

1 0

MonadCatchIO, finally and the error monad
by Michael Snoyman 18 Oct '10

18 Oct '10

Hey all, In case anyone noticed, Haskellers occassionally dies with a "Pool exhausted exception." I've traced this to a bug in Yesod, which in turn is a bug in the neither package, which I believe is a flawed design in the MonadCatchIO-transformers package. Here are my thoughts on this and what I think needs to be done to fix it. In Control.Exception, we define a number of different ways of dealing with exceptions. All of these can be expressed in terms of block, unblock and catch. For our purposes here, I'm going to ignore block and unblock: they deal with asynchronous exceptions, which is not my point here. Keep that in mind with the code samples. Anyway, with this caveat, we can define finally as: finally :: IO a -> IO b -> IO a a `finally` sequel = do r <- a `catch` \e -> sequel >> throwIO (e :: SomeException) _ <- sequel return r The idea is simple: try to perform the action. If any exceptions get thrown, call sequel and rethrow the exception. If we ever get to line 4, it's because no exceptions were thrown. Therefore, we know that sequel has not yet been called, so we call it. Said another way: there are precisely two cases: * An exception was thrown * An exception was not thrown A downside of this finally function (and catch, for that matter) is that it requires all of the actions to live in the IO monad, when in fact we all love to let things run in complicated monad transformer stacks. So along comes MonadCatchIO-(transformers, mtl) and gives us a new magical definition of catch: catch :: (MonadCatchIO m, Exception e) => m a -> (e -> m a) -> m a Using this new, extended definition of catch, we can define a finally function with the type signature finally :: MonadCatchIO m => m a -> m b -> m a (Note that we need to replace throwIO with liftIO . throwIO.) You can try this with writers, readers, etc, and everything works just fine. You can even use an Error/Either monad transformer, throw an exception, and the finally function will correctly run your sequel function. However, things don't work out so well when you use a throwError. Let's see the code: {-# LANGUAGE PackageImports #-} import Control.Monad.Trans.Error import "MonadCatchIO-transformers" Control.Monad.CatchIO (finally) import Control.Monad.IO.Class main = runErrorT $ finally go $ liftIO $ putStrLn "sequel called" go :: ErrorT String IO String --go = return "return" --go = error "error" --go = throwError "throwError" Try running the code with each version of go uncommented. In the first two, "sequel called" gets printed. However, in the third, it does not. The reason is short-circuiting: if we remember from the definition of finally, there are two cases we account for. If an exception is called, catch addresses it. If not, we assume that the next line will be called. However, in the presence of short-circuiting monads like ErrorT, that line of code will never get called! I have a recommendation of how to fix this: the MonadCatchIO typeclass should be extended to include finally, onException and everything else. We can provide default definitions which will work for most monads, and short-circuiting monads like ErrorT (and I imagine ContT as well) will need to override them. Michael

5 12

Re: [Haskell-cafe] Bulletproof resource management
by John Lato 18 Oct '10

18 Oct '10

> > From: Florian Weimer <fw(a)deneb.enyo.de> > > * Henning Thielemann: > > > Some open/close pairs have corresponding 'with' functions, that are > > implemented using Exception.bracket. You can also use them within > > GHCi. I think using both manual resource deallocation and finalizers > > makes everything more complicated and more unreliable. > > It seems that Exception.bracket does not work in all cases, see the > recent "MonadCatchIO, finally and the error monad" thread. > > Anyway, the ability of closures (and threads) means that something > like Exception.bracket does not prevent access to closed handles, so > I still need an additional safety net. > Enumeration-based interfaces will prevent access to closed handles[1], [2], etc. You can use this style for more than just handles and sockets, e.g. Takusen uses it for database connections. I think somebody else already mentioned region-based management, which is also completely safe AFAIK. [1] http://hackage.haskell.org/package/iteratee [2] http://hackage.haskell.org/package/enumerator

2 1