February 2008 - Libraries

Re: ANNOUNCE: multiset 0.1
by Christian Maeder 07 Feb '08

07 Feb '08

> Hackage: > http://hackage.haskell.org/cgi-bin/hackage-scripts/package/multiset-0.1 > Haddock: http://twan.home.fmf.nl/multiset/doc/ > Darcs: http://twan.home.fmf.nl/repos/multiset/ Seeing all these nice little packages (i.e. also bimap), is there a cute way to get a binary distribution - similar to the current extra libs - with many packages already included, so that installation can be accomplished in one go (maybe for the next ghc release)? Cheers Christian

1 0

Minor issue with mapAccumR
by Cale Gibbard 06 Feb '08

06 Feb '08

I'm not sure whether this would be considered worth fixing right away, or if we should wait until some other major compatibility breaking language change to fix it, but it appears that somehow the parameters to the function passed to mapAccumR are flipped relative to their natural order. To show what I mean, here is some code: Prelude Data.List> mapAccumR (\x y -> (concat ["(f ",x," ",y,")"], concat ["(g ",x," ",y,")"])) "z" ["1","2","3"] ("(f (f (f z 3) 2) 1)",["(g (f (f z 3) 2) 1)","(g (f z 3) 2)","(g z 3)"]) You can see here that the list is flipped over in the process, even though the right fold structure is there, it ends up looking like a left fold over the reverse of the list. One would want the law: fst . mapAccumR f z = foldr (fst . f) z to be true, but instead we have: fst . mapAccumR (flip f) z = foldr (fst . f) z You can see that structurally if we flip the parameters in the above example: Prelude Data.List> mapAccumR (\y x -> (concat ["(f ",x," ",y,")"], concat ["(g ",x," ",y,")"])) "z" ["1","2","3"] ("(f 1 (f 2 (f 3 z)))",["(g 1 (f 2 (f 3 z)))","(g 2 (f 3 z))","(g 3 z)"]) I also have some diagrams on http://cale.yi.org/index.php/Fold_Diagrams (near the end) displaying the difference, and that's where I first noticed it. Are many people using mapAccumR? How much would it hurt to change it? - Cale

3 3

lambdabot setup
by Valery V. Vorotyntsev 06 Feb '08

06 Feb '08

Dear, lazy programmers, Please let me know the proper place to report lambdabot bugs, and feel free to ignore the rest of message. Are you still reading? In this case you may want to know that *** I've successfully installed lambdabot with GHC 6.9! :) *** Kudos to Cale & the IRC crowd for making my day [http://tunes.org/~nef/logs/haskell/08.02.04] Boring part: $ darcs get http://code.haskell.org/lambdabot $ cd lambdabot $ runhaskell Setup configure --prefix=$HOME --user $ runhaskell Setup build $ touch LICENSE # see the patch attached $ runhaskell Setup install Interesting part: $ lambdabot -e 'hoogle map' Initialising plugins ...........Plugin.Djinn: couldn't find djinn binary ...........................sending message to bogus server: IrcMessage {msgServer = "freenode", msgLBName = "urk!<outputmessage>", msgPrefix = "", msgCommand = "NAMES", msgParams = [""]} .................. done. A Hoogle error occured. Exception: all servers detached exception: State/seen: openBinaryFile: does not exist (No such file or directory) $ hoogle map Could not find hoogle database, looked for: hoogle.txt In order to make `hoogle' binary usable, one should copy `hoogle.txt' file to "$(dirname $(which hoogle))/" directory: $ cp State/hoogle.txt ~/bin/ # FIXME $ hoogle map [...success...] To my believe, it's a package's responsibility to copy data files to proper locations (during `runhaskell Setup install' step). And hoogle _plugin_ still doesn't work though. $ lambdabot Initialising plugins ...........Plugin.Djinn: couldn't find djinn binary ...........................sending message to bogus server: IrcMessage {msgServer = "freenode", msgLBName = "urk!<outputmessage>", msgPrefix = "", msgCommand = "NAMES", msgParams = [""]} .................. done. lambdabot> hoogle map A Hoogle error occured. lambdabot> lambdabot: user error (<eof>) Exception: all servers detached Thank you. -- vvv PS: Tue Feb 5 18:38:55 EET 2008 "Valery V. Vorotyntsev" <valery.vv(a)gmail.com> * `LICENSE' file added Tue Feb 5 18:37:12 EET 2008 "Valery V. Vorotyntsev" <valery.vv(a)gmail.com> * lambdabot.cabal: add `build-type' to make Cabal happy

2 3

Proposal: Add concatMapM function (#2042)
by Twan van Laarhoven 06 Feb '08

06 Feb '08

Hello library people, I have noticed that many projects include a 'concatMapM' function: concatMapM :: (Monad m) => (a -> m [b]) -> [a] -> m [b] I think this is useful in general, so let's add it to Control.Monad. Trac ticket: http://hackage.haskell.org/trac/ghc/ticket/2042 Deadline for discussion: 2 weeks from now, January 28 Twan

25 94

fgl-bug
by Christian Maeder 05 Feb '08

05 Feb '08

Hallo Martin, I was going to use xdfWith from Data.Graph.Inductive.Query.DFS with Data.Graph.Inductive.Graph.out' as second argument, but 1. xdfWith is not exported 2. out' seems to be wrong (by looking at the source code) -- | All outward-directed 'LEdge's in a 'Context'. out' :: Context a b -> [LEdge b] out' c@(_,v,_,_) = map (\(l,w)->(w,v,l)) (context4l' c) ^^^ I think, the outgoing edge must be made as "(v,w,l)"! inn' looks correct: -- | All inward-directed 'LEdge's in a 'Context'. inn' :: Context a b -> [LEdge b] inn' c@(_,v,_,_) = map (\(l,w)->(w,v,l)) (context1l' c) Can 1. and 2. be fixed? I need the general xdfWith because I want to filter out some successors (or maybe I can filter to whole graph first). Cheers Christian

1 0

Fixing MonadIO
by Yitzchak Gale 05 Feb '08

05 Feb '08

Simon Marlow wrote: > Avoiding > exceptions because MonadIO has trouble with them is not a good enough > reason, IMO. We should fix MonadIO instead. I'm all for it! Below is a summary of the three approaches that have been proposed, as far as I can remember: 1. Make the functions in Control.Exception more polymorphic. This is part of the more general program of providing polymorphic IO described in Haskell' ticket 110. Brian Hulley attached to that ticket a version of Control.Exception that does this by introducing the MonadException subclass of MonadIO. http://hackage.haskell.org/trac/haskell-prime/attachment/ticket/110/Excepti… 2. In another branch from this thread, I suggested adding only the following three low-level exception handling functions to Control.Exception: startDelayingExceptions stopDelayingExceptions getDelayedException This would allow exception handling to be extended arbitrarily in other libraries, with only a small addition to Control.Exception. Simon Marlow pointed out that this mechanism would lose certain optimizations that exist, e.g., for preserving tail-recursion in block. That would be a cost of this generality. (Obviously we would retain the current mechanism for IO itself.) http://www.haskell.org/pipermail/libraries/2008-February/009159.html 3. Earlier in this thread, Judah Jacobson proposed adding additional liftIO functions to MonadIO, or a subclass, that match the kinds of the exception handling functions of Control.Exception. The kinds that would be needed are: For block and unblock: * -> * For catch: * -> (* -> *) -> * For setUncaughtExceptionHandler: (* -> *) -> * The liftIO for catch is the most general, so it could be reused for the others, but that would look a little ad hoc. This approach has the advantage that it does not require any change at all to Control.Exception, but it puts more of a burden on monad authors. http://www.haskell.org/pipermail/libraries/2008-January/009034.html Any other approaches? Any opinions about which of these would be best? Thanks, Yitz

3 3

darcs patch: Figure out timezone offset from timezone name
by David Leuschner 05 Feb '08

05 Feb '08

Sat Feb 2 12:33:17 CET 2008 David Leuschner <david(a)loisch.de> * Figure out timezone offset from timezone name

7 12

MonadIO and IO exceptions
by Yitzchak Gale 02 Feb '08

02 Feb '08

Judah Jacobson wrote: > I've already demonstrated how a library writer can solve that problem in: > http://www.haskell.org/pipermail/libraries/2008-January/009034.html Yes, that is indeed very nice. But I don't think it is a practical solution right now, for the following reasons: It requires that users be in a special monad; it doesn't work for regular MonadIO. So it isn't really a practical solution until it gets into MTL and people start porting their code. Providing an instance for MonadIO1 (or whatever we would call it) is an extra step for monad writers that may often be skipped. Also, there are obviously many other more complex cases beyond a simple bracket. How general is this technique? As you point out, even for bracket it does not work unless the "after" action is IO. What other restrictions are there in the general case? Perhaps we could fix those problems by also providing liftIOk for all kinds k that occur in the signatures of various functions in Control.Exception. But that would make the new monad even more unwieldy. As I suggested before, I think the best solution would be to define the functions of Control.Exception in terms of lower-level primitives that could then be used to define the functions directly for other monads. Perhaps something like this would be general enough to cover everything: -- Delay any exception and put in buffer startDelayingExceptions :: IO () -- Stop delaying exceptions stopDelayingExceptions :: IO () -- Retrieve delayed exception and clear buffer getDelayedException :: IO (Maybe Exception) There would be one exception buffer per thread. New exceptions would replace old ones, so users of this mechanism would be required to catch as catch can. Based on Simon Marlow's observation in our previous discussion on this topic, we would still want to leave around the current primitives as a special case optimization for IO. Regards, Yitz

1 0

Fwd: Readline read_history and write_history addition
by Alexander Dunlap 02 Feb '08

02 Feb '08

On Feb 2, 2008 1:14 PM, Yitzchak Gale <gale(a)sefer.org> wrote: > Alexander Dunlap wrote: > >>> For instances where an exception would be too intrusive, I don't see > >>> how it would be too hard to write a wrapper function > > I wrote: > >> In a library that does not have direct access to the IO > >> monad, it would be not just hard - it would be impossible. > >> That is because of type restrictions in the current versions > >> of catch, block, and friends. > > Judah Jacobson wrote: > > You haven't said why something like the following would not be sufficient: > > > > readHistoryM :: MonadIO m => String -> m Bool > > readHistoryM file = liftIO $ do > > result <- try (readHistory file) > > return (result == Right ()) > > Because a library - other than readline itself - can't > force its users to do that. > > OK. Here's a simplified real-world example. Say you want to > write a simple library that interfaces the text-to-speech facilities > available on multiple platforms. To play nicely with programs > written in a monadic style, the interface might be something like: > > class MonadIO m => Speech m where > sayText :: String -> m () > runSpeech :: m a -> IO a > > instance Speech SomeSpeechSystem where > sayText t = ... > runSpeech x = do > liftIO startSomeSpeechSystem > ret <- x > liftIO stopSomeSpeechSystem > return ret > > Unfortunately, bracket is not available. So if x throws an > uncaught IO exception, you may leave around zombies, > database corruption, missiles armed for launch, etc. > > Well, if your speech system doesn't arm any missiles, > you may consider it a reasonable risk to use this > library in programs that could throw an IO exception > on some rare error condition. > > But the proposal here is to raise the exception in a > common situation that will definitely occur in regular > usage. That may be fine in Java or Python, but it > is a bad idea for IO exceptions in Haskell. > > Alexander Dunlap wrote: > > So why couldn't you have a Utils.hs file that imports System.IO and > > provides the wrapper around readHistory? Then you can use the > > tryReadHistory function in your MonadIO-exporting module _exactly_ the > > same way as the original readHistory function. > > You can. But if you are writing a library, your users > might not. > > Regards, > Yitz > I don't understand. Why don't you compile the functions we are suggesting _into the library_? Alex

2 1