March 2010 - Libraries

Proposal #3339: Add (+>) as a synonym for mappend
by Bryan O'Sullivan 08 Nov '11

08 Nov '11

Ticket: http://hackage.haskell.org/trac/ghc/ticket/3339 >From the ticket: This proposal was, I think, originally suggested by Jules Bean. The idea is to add two functions to the Data.Monoid module, (+>) and (<+), corresponding to different uses of mappend. These should not be methods of the Monoidtypeclass, but top-level functions. I hope (but slightly doubt) that the visual nature of the two operators might help to counter the thought that monoids are just for gluing things together. (+>) :: (Monoid a) => a -> a -> a a +> b = a `mappend` b (<+) :: (Monoid a) => a -> a -> a a <+ b = b `mappend` a infixl 4 +> infixl 4 <+ Proposed deadline: two weeks. If this looks reasonable, I'll attach darcs patches.

30 75

There are too many error handling conventions used in library code!
by dons＠cse.unsw.edu.au 13 Aug '11

13 Aug '11

This article on the 8 different error handling strategies various common Haskell libs use: http://www.randomhacks.net/articles/2007/03/10/haskell-8-ways-to-report-err… got me thinking: we need to standardise/recommend a small set of methods for library error handling. The lack of consistent error reporting between libs results in verbose code, as we're not able to use a single error handling technique when gluing together code from different libs (i.e. we can't just use Maybe or Either/ErrorT). (It's always nice when you *can* use, say, a Maybe monad to glue code from a number of sources, but eventually you reach code with a different error system, and the Maybe monad breaks down). So, some questions I think we can tackle: * can we identify error handling strategies from the list that should not be used anymore? (throwDyn?) * can we move some of the outlying libraries to a more consistent error framework? * do we need more support for gluing together our different error systems? (it should be easier to glue code using , say, Maybe/Either). * what role does MonadError play here, as a generic error handler? * can we make precise recommendations about which error strategies to use? -- Don

11 16

[darcs patch] filepath: normalise trailing dot
by Conrad Parker 21 Dec '10

21 Dec '10

Hi, the attached darcs patch modifies the behaviour of normalise to handle trailing dots in a path. The previous behaviour yielded this: Prelude System.FilePath> normalise "../." "../." Prelude System.FilePath> normalise ".././" ".././" Prelude System.FilePath> normalise ".././.." "../.." This patch modifies dropDots such that the check for (".":[]) only occurs once for the path, after which a driver function dropDots' is used which skips this check. Hence "." can be removed from the end of a longer path, but a path of just "." is unchanged. (my trac account is pending verification, I'll reply with a trac ticket # later if needed) cheers, Conrad.

4 7

xhtml maintainership?
by Ganesh Sittampalam 03 Aug '10

03 Aug '10

Hi, I believe the xhtml package is currently unmaintained. As it is something that used to be distributed with GHC, is it something that libraries@ could/should take on? Cheers, Ganesh

6 10

Asynchronous exception wormholes kill modularity
by Bas van Dijk 01 May '10

01 May '10

Dear all, (sorry for this long mail) When programming in the IO monad you have to be careful about asynchronous exceptions. These nasty little worms can be thrown to you at any point in your IO computation. You have to be extra careful when doing, what must be, an atomic transaction like: do old <- takeMVar m new <- f old `onException` putMVar m old putMVar m new If an asynchronous exception is thrown to you right after you have taken your MVar the putMVar will not be executed anymore and will leave your MVar in the empty state. This can possibly lead to dead-lock. The standard solution for this is to use a function like modifyMVar_: modifyMVar_ :: MVar a -> (a -> IO a) -> IO () modifyMVar_ m io = block $ do a <- takeMVar m a' <- unblock (io a) `onException` putMVar m a putMVar m a' As you can see this will first block asynchronous exceptions before taking the MVar. It is usually better to be in the blocked state as short as possible to ensure that asynchronous exceptions can be handled as soon as possible. This is why modifyMVar_ unblocks the the inner (io a). However now comes the problem I would like to talk about. What if I want to use modifyMVar_ as part of a bigger atomic transaction. As in: block $ do ... modifyMVar_ m f ... >From a quick glanse at this code it looks like asynchronous exceptions can't be thrown to this transaction because we block them. However the unblock in modifyMVar_ opens an asynchronous exception "wormhole" right into our blocked computation. This destroys modularity. Besides modifyMVar_ the following functions suffer the same problem: * Control.Exception.finally/bracket/bracketOnError * Control.Concurrent.MVar.withMVar/modifyMVar_/modifyMVar * Foreign.Marshal.Pool.withPool We can solve it by introducing two handy functions 'blockedApply' and 'blockedApply2' and wrapping each of the operations in them: > import Control.Exception > import Control.Concurrent.MVar > import Foreign.Marshal.Pool > import GHC.IO ( catchAny ) > blockedApply :: IO a -> (IO a -> IO b) -> IO b > blockedApply a f = do > b <- blocked > if b > then f a > else block $ f $ unblock a > blockedApply2 :: (c -> IO a) -> ((c -> IO a) -> IO b) -> IO b > blockedApply2 g f = do > b <- blocked > if b > then f g > else block $ f $ unblock . g Control.Exception: > finally :: IO a -> IO b -> IO a > a `finally` sequel = blockedApply a $ \a' -> do > r <- a' `onException` sequel > _ <- sequel > return r > bracket :: IO a-> (a -> IO b) -> (a -> IO c) -> IO c > bracket before after thing = blockedApply2 thing $ \thing' -> do > a <- before > r <- thing' a `onException` after a > _ <- after a > return r > bracketOnError :: IO a -> (a -> IO b) -> (a -> IO c) -> IO c > bracketOnError before after thing = blockedApply2 thing $ \thing' -> do > a <- before > thing' a `onException` after a Control.Concurrent.MVar: > withMVar :: MVar a -> (a -> IO b) -> IO b > withMVar m io = blockedApply2 io $ \io' -> do > a <- takeMVar m > b <- io' a `onException` putMVar m a > putMVar m a > return b > modifyMVar_ :: MVar a -> (a -> IO a) -> IO () > modifyMVar_ m io = blockedApply2 io $ \io' -> do > a <- takeMVar m > a' <- io' a `onException` putMVar m a > putMVar m a' > modifyMVar :: MVar a -> (a -> IO (a,b)) -> IO b > modifyMVar m io = blockedApply2 io $ \io' -> do > a <- takeMVar m > (a',b) <- io' a `onException` putMVar m a > putMVar m a' > return b Foreign.Marshal.Pool: > withPool :: (Pool -> IO b) -> IO b > withPool act = blockedApply2 act $ \act' -> do > pool <- newPool > val <- catchAny > (act' pool) > (\e -> do freePool pool; throw e) > freePool pool > return val I'm not proposing to make this change (yet) because I first would like to have some discussion on this. Thanks for reading this rather long mail, Bas

12 47

Deprecating haskell98 module aliases
by Gwern Branwen 29 Apr '10

29 Apr '10

See http://hackage.haskell.org/trac/hackage/ticket/640 It seems to me that a warning on using the 'haskell98' package wouldn't be a bad thing; those modules have since been split apart in better modules, the names are ever more unfamiliar, etc. But Duncan thinks it merits discussion. -- gwern

16 35

extensible-exceptions 0.1.1.1 fails to build on GHC 6.8 (Cabal 1.2)
by Anders Kaseorg 25 Apr '10

25 Apr '10

http://hackage.haskell.org/trac/ghc/ticket/3931 With ghc 6.8.2 on Debian lenny, with Cabal-1.2.3.0 and cabal-install-0.4.0: $ cabal install extensible-exceptions Downloading 'extensible-exceptions-0.1.1.1'... Warning: Unknown fields: bug-reports (line 6) Fields allowed in this section: name, version, cabal-version, build-type, license, license-file, copyright, maintainer, build-depends, stability, homepage, package-url, synopsis, description, category, author, tested-with, data-files, extra-source-files, extra-tmp-files Warning: Unknown section type: source-repository ignoring... Warning: Ignoring trailing declarations. cabal: cannot satisfy dependency Cabal>=1.6 This is a regression from extensible-exceptions-0.1.1.0, which worked fine. Since compatibility with GHC < 6.10 is the entire point of the extensible-exceptions package, this should probably be fixed. The patch attached to the ticket fixes this by removing source-repository from the Cabal file and lowering the Cabal requirement back to >=1.2. (Cabal 1.2 would actually accept the package with a warning if the source-repository section was moved to the bottom, but cabal check does not know that, so the package could not be uploaded to Hackage that way. See http://hackage.haskell.org/trac/hackage/ticket/639 .) Anders

3 7

Network library patches
by Neil Mitchell 20 Apr '10

20 Apr '10

Hi I finally got the network library (darcs) building, installing and basically working on Windows with GHC 6.12.1. To do this I set up my environment as follows: 1) Install Cygwin 1.7 (include autoreconf) 2) Install GHC 6.12.1 3) export PATH=/cygdrive/c/ghc/ghc-6.12.1/mingw/bin:$PATH I then did the network steps: 1) Grab network from darcs 2) autoreconf 3) Apply the patch attached, which just changes the .cabal file 4) Change all instances of CALLCONV to stdcall 5) cabal install Please can you apply the attached patch, which should be compatible with Linux/Mac too. I found lots of references to CALLCONV all over the place, but couldn't figure out where it started/ended up - my attempts at #define were rather unsuccessful. Could you please change the logic so Windows gets stdcall as standard? I'm happy to test any patches you come up with. Having a working network library on Windows will be really nice, as it's stopped me upgrading to GHC 6.12.1 for a while now. Thanks, Neil

3 5

Re: Bug in Parsec.Token
by Greg Fitzgerald 03 Apr '10

03 Apr '10

> If the community wants to freeze on Parsec 2, then I have no problem > renaming the package, otherwise I think it is both unnecessary and a > waste of effort. Reasons one might prefer Parsec 2.1: * Haskell98 implementation * Daan Leijen's whitepapers: http://legacy.cs.uu.nl/daan/download/parsec/parsec.pdf http://legacy.cs.uu.nl/daan/download/papers/parsec-paper.pdf Reasons one might prefer Parsec 3.1: * Parametric in the input stream type (parses ByteStrings) * Monad transformer that can be stacked on arbitrary monads * More Haddock documentation Parsec 3 is certainly useful, but there are still good, valid reasons one might prefer Parsec 2.1. Derek, if you wouldn't mind renaming Parsec 3, I volunteer to become the maintainer of the Parsec package. Thanks, Greg

7 13

Terminfo package fails to load .so file on Fedora 13 prerelease
by Robin Green 01 Apr '10

01 Apr '10

I encountered a problem compiling yi on Fedora Linux 13 (prerelease): when the terminfo package was loaded by ghci, it attempted to load the native library /usr/lib/libncursesw.so. However, that file has recently been changed from a symbolic link to a library, into a plain text file, as explained here in the response to my Fedora bug report: https://bugzilla.redhat.com/show_bug.cgi?id=578509 The response suggests that ghci should instead try to load the versioned link libncursesw.so.5 (which happens to be in /lib in Fedora, incidentally). Is this something that could be changed by the terminfo package, or would there have to be a change made to ghci? -- Robin

2 1