April 2011 - Libraries

Proposal: Add newUniqueSTM to Data.Unique
by Edward Kmett 27 Apr '12

27 Apr '12

Data.Unique's newUnique uses atomically internally to update a TVar. Consequently attempting to "unsafeIOToSTM newUnique" to allocate a Unique within an STM transaction blows you sky high. The proposal is to split the definition of newUnique into: newUnique = atomically newUniqueSTM and expose newUniqueSTM. Alternately, since bug #3838 has been resolved, we could revert to using an IORef, which would avoid the wart of having us have an overtly IO action detonate because of an internal implementation detail of using STM. Since, there are two paths forward, I haven't put forward a patch, but wanted to open a discussion. Discussion Period: 2 weeks. -Edward Kmett

6 12

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

Proposal: Tidy up and export PSQ from base
by Edward Z. Yang 15 May '11

15 May '11

The new IO event manager implements a priority search queue internally. This is a kind of handy data structure; in particular, some algorithmic improvements in Hoopl would require a decent priority queue implementation. I propose that we move GHC.Event.PSQ to Data.PSQ, cleaning up the dependency on GHC.Event.Unique, and export it unconditionally (right now it is only available on non-Windows.) Discussion period: 1 week. Cheers, Edward

8 20

Proposal: add Int indexing functions to Data.Set
by Luis Casillas 02 May '11

02 May '11

Hi everybody. First time proposer here, so bear with me. While I was looking at the Haddock documentation for Data.Map, I noticed that it has a section with "Indexed" operations that address the map with Int indexes: http://www.haskell.org/ghc/docs/latest/html/libraries/containers/Data-Map.h… The relevant functions' signatures are these: lookupIndex :: Ord k => k -> Map k a -> Maybe Int findIndex :: Ord k => k -> Map k a -> Int elemAt :: Int -> Map k a -> (k, a) updateAt :: (k -> a -> Maybe a) -> Int -> Map k a -> Map k a deleteAt :: Int -> Map k a -> Map k a Now, the Data.Set module, which is a near carbon-copy of Data.Map, does not have any counterparts to these functions. My proposal is to add such counterparts to Data.Set (I'm writing some code that could benefit from them). The proposed functions' signatures: lookupIndex :: Ord a => a -> Set a -> Maybe Int findIndex :: Ord a => a -> Set a -> Int elemAt :: Int -> Set a -> a deleteAt :: Int -> Set a -> Set a I attach a patch to add these to Data.Set. Note that the implementation of the Set functions is basically a copy-paste-and-edit of their counterparts in Data.Map. That seems to be the convention in those two modules; Data.Set is really just like Data.Map but with no "value" field in the datatype's constructor. Since I am a noob, I mistakenly created a Trac ticket before figuring out the correct library proposal process (#5162, which promptly got closed; my apologies). There have been a couple of responses there, which I will summarize here: 1. Concern over the efficiency of the code in my patch (Trac comment by tibbe). At my present skill level with Haskell, frankly, the most intelligent response I can give to this is that I'm copying the Data.Map implementation from darcs to the best of my ability, and that the most I hope is to make the Set versions no worse than the Map versions. 2. Concern that Int-based indexing breaks the set abstraction by exposing a specific ordering (Trac comment by Malcolm Wallace). My assumption when I decided to submit this patch was that if it's OK for Data.Map to have these operations, then it should also be ok for Data.Set to have them. But Malcolm's concern makes me wonder if some people will find the original Data.Map functions objectionable and dislike the idea of "spreading the infection" to Data.Set. Discussion period: 2 weeks.

10 20

Instances for BaudRate from System.Posix.Terminal
by Heka Treep 02 May '11

02 May '11

Hi, the c-libraries use BaudRate as integers, so how about to add Enum instance for BaudRate? It allow users to use fromEnum, toEnum methods. Like this: module System.Posix.Terminal ( ... data BaudRate = B0 ... | B115200 deriving ( Eq, Ord ) instance Enum BaudRate where fromEnum b = case b of B0 -> 0 B50 -> 50 B75 -> 75 B110 -> 110 B134 -> 134 B150 -> 150 B200 -> 200 B300 -> 300 B600 -> 600 B1200 -> 1200 B1800 -> 1800 B2400 -> 2400 B4800 -> 4800 B9600 -> 9600 B19200 -> 19200 B38400 -> 38400 B57600 -> 57600 B115200 -> 115200 toEnum i = case i of 0 -> B0 50 -> B50 75 -> B75 110 -> B110 134 -> B134 150 -> B150 200 -> B200 300 -> B300 600 -> B600 1200 -> B1200 1800 -> B1800 2400 -> B2400 4800 -> B4800 9600 -> B9600 19200 -> B19200 38400 -> B38400 57600 -> B57600 115200 -> B115200 _ -> error $ "unsupported baudrate " ++ show i

2 2

Arrows that are also Functors
by Henning Thielemann 01 May '11

01 May '11

Is it common to make a type an instance of both Arrow and Functor type class? If a type is both instance of Arrow and Functor, would you expect that fmap = (^<<) ? If yes, how about adding this as expected law to the Control.Arrow documentation? Same question for Applicative functors and liftA2 (,) = (&&&). (Btw. Control.Arrow haddock documentation does not mention any Arrow law so far.)

6 12

ANNOUNCE: cereal-0.3.3.0
by Trevor Elliott 26 Apr '11

26 Apr '11

Hot on the heels of the last release, cereal-0.3.3.0 [1] adds support for parsing and rendering lazy ByteStrings. Most running functions in Data.Serialize.Get and Data.Serialize.Put now have lazy analogues, and Data.Serialize has gained encodeLazy and decodeLazy. This new functionality was made possible by the incremental parsing support added in cereal-0.3.1.0 by Lemmih. [1] http://hackage.haskell.org/package/cereal-0.3.3.0

1 0

Subject: Hackage broken -- no building/haddock being done
by Darius Jahandarie 24 Apr '11

24 Apr '11

Hello all, Hackage seems to have stopped building packages since April 16th. Consequently, no haddocks have been created for all packages uploaded since then. Here is the last package that built: http://hackage.haskell.org/package/acid-state-0.3 Here is the package right after it, which was the first failure: http://hackage.haskell.org/package/text-json-qq-0.3.0 I got these packages by scrapping what 'hackagebot' said on #haskell and checking the urls, but since that bot drops in and out randomly, it's possible that I missed some packages. The full list of packages uploaded since text-json-qq-0.3.0 is attached (again, from hackagebot). Hopefully this is a fixable problem. :) Cheers. -- Darius Jahandarie

4 3

ANNOUNCE: iteratee-compress 0.2.0.0
by Maciej Piechotka 23 Apr '11

23 Apr '11

Iteratee-compress provides compressing and decompressing enumerators including flushing (using John Lato's implementation). Currently only gzip and bzip is provided but LZMA is planned. Changes from previous version: - Add BZip support Next goals: - LZMA support - Generic interface for flushing To think about: - Should inner iteratee be able to request flushing Regards

1 0