- Haskell-Cafe - Haskell.org

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

ANNOUNCE: Haskell XML Toolbox Version 9.0.0
by Uwe Schmidt 18 Oct '10

18 Oct '10

Haskell XML Toolbox 9.0.0 I would like to announce a new version of the Haskell XML Toolbox. HXT has grown over the years. Components for XPath, XSLT, validation with RelaxNG, picklers for conversion from/to native Haskell data, lazy parsing with tagsoup, input via curl and native Haskell HTTP and others have been added. This has led to a rather large package with a lot of dependencies. To make the toolbox more modular and to reduce the dependencies on other packages, hxt has been split into various smaller packages since this version. Information about this release, about the new packages, changes and incompatibilities to older versions can be found at HXT home: "http://www.fh-wedel.de/~si/HXmlToolbox/index.html" and on the Haskell wiki page about HXT "http://www.haskell.org/haskellwiki/HXT" The source repo has been moved to GitHub: "http://github.com/UweSchmidt/hxt" Downloads and installation is available from hackage. Please email comments, bugs, etc. to hxmltoolbox(a)fh-wedel.de or si(a)fh-wedel.de Uwe -- University of Applied Sciences, Wedel, Germany http://www.fh-wedel.de/~si/index.html

16 32

concurrency vs. I/O in GHC
by Donn Cave 18 Oct '10

18 Oct '10

As I have migrated more of my application into Haskell, I find that I/O in one thread effectively blocks other threads. That's rather the opposite of what I need - I don't care so much if Haskell threads manage to compute in parallel, but the application should continue to function, in other threads, while an I/O has one thread blocked. Is that supposed to happen, is there anything I can do about it? Specifically I'm talking about OpenSSL SSL_read(). In this case, while a file descriptor is involved, there is also (I assume) some buffering, so it isn't a simple matter of deferring SSL_read() until data arrives at the fd. I'm hoping there's something more generic, that unblocks other threads during any foreign call - as one would do in Python, for example, bracking a foreign call with C macros that release and acquire the interpreter global lock. You'd also use this with functions like open(), which may not return immediately but don't answer to select(). All the Haskell code in question is executing in callbacks, from threads started in C++. The thread that actually does the network I/O could if necessary be started in 1st generation Haskell as a special case, if that might make any difference. I disable the RTS clock itimer signals, because something in the libraries I'm using doesn't thrive under a barrage of signals. (Environment setting GHCRTS=-V0.) The consequence, according to the documentation, should be "Context switches will still happen, but deterministically and at a rate much faster than normal", and anyway I suppose that's talking about green threads, not the OS threads where context switches are an OS function. Thanks! Donn Cave, donn(a)avvanta.com

2 3