April 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

Haskell 2010 libraries
by Simon Marlow 09 May '10

09 May '10

Hi Folks, I'm editing the Haskell 2010 report right now, and trying to decide what to do about the libraries. During the Haskell 2010 process the committee agreed that the libraries in the report should be updated, using the current hierarchical names, adding new functionality from the current base package, and dropping some of the H'98 library modules that now have better alternatives. In Haskell 2010 we're also adding the FFI modules. The FFI addendum used non-hierarchical names (CForeign, MarshalAlloc etc.) but these are usually known by their hierarchical names nowadays: e.g. Foreign.C, Foreign.Marshal.Alloc. It would seem strange to add the non-hierarchical names to the Haskell language report. So this is all fine from the point of view of the Haskell report - I can certainly update the report to use the hierarchical module names, but that presents us with one or two problems in the implementation. The obvious thing to do would be to make a haskell2010 package that re-exports the appropriate modules from base, providing a fixed API that people can depend on when they write Haskell 2010 code. However, what happens when someone wants to write some code that uses Haskell 2010 libraries, but also uses something else from base, say Control.Concurrent? The modules from haskell2010 overlap with those from base, so all the imports of Haskell 2010 modules will be ambiguous. The Prelude is a bit of a thorny issue too: currently it is in base, but we would have to move it to haskell2010. Bear in mind these goals: we want to a. support writing code that is Haskell 2010 only: it only uses Haskell 2010 language features and modules. b. not break existing code as far as possible c. whatever we do should extend smoothly when H'2011 makes further changes, and so on. Here are some non-options: 1. Not have a haskell2010 package. We lose (a) above, and we lose the ability to add or change the API for these modules, in base, since they have to conform to the H'2010 spec. If H'2011 makes any changes to these modules, we're really stuck. 2. As described above: you can either use haskell2010, or base, but not both. It would be painful to use haskell2010 in GHCi, none of the base modules would be available. Here are some options: 3. allow packages to shadow each other, so haskell2010 shadows base. This is a tantalising possibility, but I don't have any idea what it would look like, e.g. should the client or the package provider specify shadowing? 4. Provide a haskell2010 package and a base2010 package that re-exports all of base except the modules that overlap with haskell2010. You can either use haskell2010, haskell2010+base2010, or base. This is a bit like (1), but avoids the need for shadowing by using package re-exports, on the other hand confusion could well arise due to the strange base2010 package, and some people would surely try to use haskell2010 + base and run into difficulties. 5. Not have a haskell2010 package, but have the report say that implementations are allowed to add things to the standard libraries. Thoughts? Better ideas? Cheers, Simon

13 20

darcs patch: Correct haddock formatting.
by Adam Vogt 06 May '10

06 May '10

1 patch for repository http://darcs.haskell.org/packages/base: Thu Apr 22 22:21:03 EDT 2010 Adam Vogt <vogt.adam(a)gmail.com> * Correct haddock formatting.

2 1

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

Add flipped fmap
by Bas van Dijk 01 May '10

01 May '10

Hello, I would like to propose adding a flipped variant of <$> to Data.Functor: (<$$>) ∷ Functor f ⇒ f α → (α → β) → f β (<$$>) = flip (<$>) Please see the ticket for motivation and patch: http://hackage.haskell.org/trac/ghc/ticket/3962 Discussion period: 2 weeks. regards, Bas

13 40

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

Cannot install readline on Mac OS X
by Yitzchak Gale 29 Apr '10

29 Apr '10

After a recent upgrade of Mac OS X from Tiger to Snow Leopard, I installed the Haskell Platform. I installed genuine readline using MacPorts. Now I cannot install the readline package, due to the well-known problem that configure finds the fake readline that comes with Mac OS X and refuses to proceed. I have tried the various solutions suggested in: http://hackage.haskell.org/trac/ghc/ticket/3121 http://www.haskell.org/pipermail/libraries/2009-May/011595.html http://hackage.haskell.org/trac/hackage/ticket/631 and various combinations of them. Nothing helped, the same problem always occurred. Any new ideas? Thanks, Yitz

3 6