November 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

Applicative instance for ST
by Daniel Peebles 29 Dec '10

29 Dec '10

Hi all, Strangely enough, ST has a Functor and a Monad instance, but no Applicative instance (I guess it was pre-Applicative). I propose to add one. It doesn't seem very controversial, but I guess a normal discussion period for these proposals is two weeks? Thanks, Dan

6 10

Functor => Pointed => Applicative => Monad
by John Smith 22 Dec '10

22 Dec '10

Is there any intention to reorganise the standard class hierarchy, arranging them logically instead of in order of invention? I plagiarised the following example from http://stackoverflow.com/questions/1634911/can-liftm-differ-from-lifta and Trac: class Functor f where map :: (a -> b) -> f a -> f b class Functor f => Pointed f where pure :: a -> f a class Pointed f => Applicative f where (<*>) :: f (a -> b) -> f a -> f b (*>) :: f a -> f b -> f b (<*) :: f a -> f b -> f a class Applicative m => Monad m where (>>=) :: m a -> (a -> m b) -> m b (>>) :: m a -> m b -> m b join :: m (m a) -> m a f >>= x = join (fmap f x) m >> k = m >>= \_ -> k join x = x >>= id This would eliminate the necessity of declaring a Monad instance for every Applicative, and eliminate the need for sets of duplicate functions such as [fmap,liftM,map,liftA], [(<*>),ap], and [concat,join]. fail should be removed from Monad; a failed pattern match could error in the same way as is does for pure code. The only sensible uses for fail seem to be synonyms for mzero.

21 53

[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

Make Chan an instance of Eq
by Mitar 20 Dec '10

20 Dec '10

Hi! Chan should be an instance of Eq. I opened a ticket for this with a patch: http://hackage.haskell.org/trac/ghc/ticket/4526 Mitar

4 16

Proposal: Add tryReadChan to Chan
by Mitar 13 Dec '10

13 Dec '10

Hi! Now that isEmptyChan is deprecated (#4154) it would be useful to add tryReadChan. It seems it is possible to define it so that it does not block like isEmptyChan. This is because semantics is a bit different: tryReadChan is allowed to return Nothing also when Chan is non-empty, but it would block. Contrary, isEmptyChan is expected that it would return False only if Chan is really empty. I have defined also two new MVar functions which helped me implementing tryReadChan: tryReadMVar and tryModifyMVar. Probably it would be useful to make them public. Please comment. I propose three weeks for discussion. I have also opened a ticket: http://hackage.haskell.org/trac/ghc/ticket/4535 and attached a ptach there with working implementation. It would be useful to run it against some tests. (I am sorry that patch is not in darcs format.) Mitar

5 11

Re: [GHC] #4517: Add Data.Functor.Backwards to transformers
by roconnor＠theorem.ca 10 Dec '10

10 Dec '10

#4517: Add Data.Functor.Backwards to transformers ---------------------------------+------------------------------------------ Reporter: r6 | Owner: Type: proposal | Status: new Priority: normal | Component: libraries (other) Version: 7.0.1 | Keywords: backwards Testcase: | Blockedby: Os: Unknown/Multiple | Blocking: Architecture: Unknown/Multiple | Failure: None/Unknown ---------------------------------+------------------------------------------ Data.Functor.Backwards is a wrapper for functors that allow Foldable, Traversable, and Applicative functors to be operated backwards. It is similar to Dual for Monoids. The Applicative instance runs effects in reversed order. The Foldable instance folds from right to left, The Traversable instance traverses from right to left. -- Russell O'Connor <http://r6.ca/> ``All talk about `theft,''' the general counsel of the American Graphophone Company wrote, ``is the merest claptrap, for there exists no property in ideas musical, literary or artistic, except as defined by statute.''

5 9

Haskell Platform Proposal: HLint
by John Smith 07 Dec '10

07 Dec '10

As a beginner, I'm finding HLInt (http://hackage.haskell.org/package/hlint) extremely useful for improving my code. Would it be worthwhile including this in HP?

18 59

Can containers depend on Template Haskell?
by Johan Tibell 05 Dec '10

05 Dec '10

Hi all, I'm working on a proposal for adding a Data.HashMap and Data.HashSet type to containers. These types could share most of their implementation with Data.IntMap (and Data.IntSet) but can be (somewhat) more efficiently implemented by specializing IntMap from data IntMap a = Nil | Tip {-# UNPACK #-} !Key a | Bin {-# UNPACK #-} !Prefix {-# UNPACK #-} !Mask !(IntMap a) !(IntMap a) to data FullList k v = FL !k v (List k v) data List k v = Nil | Cons !k v (List k v) data IntMap a = Nil | Tip {-# UNPACK #-} !Hash {-# UNPACK #-} !(FullList k v) | Bin {-# UNPACK #-} !Prefix {-# UNPACK #-} !Mask !(IntMap a) !(IntMap a) Unpacking the FullList into the Tip constructor saves one indirection and two words of overhead per key/value pair. One way to achieve this specialization would be to duplicate the implementation of Data.IntMap, but it would be nice to avoid the duplication. Template Haskell would allow most of the implementation to be shared without sacrificing performance. Can containers use Template Haskell? I think the answer is no, but I thought I'd check anyway. Johan

8 11