October 2008 - Libraries

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 #2629: Data.List: Replace nub; add nubOrd, nubInt, nubWith
by Bart Massey 24 Feb '10

24 Feb '10

http://hackage.haskell.org/trac/ghc/ticket/2629 Everyone always complains about nub, but nobody ever does anything about it except (map head . group . sort), which isn't lazy and isn't always faster. :-) I've implemented a new function nubWith that takes a "stop list" as an argument and filters its target list against the stop list. I've then re-implemented nub and implemented nubOrd and nubInt in terms of nubWith: the stop list is a typeclass, so these implementations are trivial and new implementations are easily added. nubBy is left alone, since there's nothing obvious to be done about it. All of the nubs are still fully lazy. Basic QuickCheck tests are provided, and pass. Performance benchmarking code is provided. The performance of my nub implementation is quite comparable to that of the standard one. My nubOrd and nubInt implementations are dramatically faster, since they use a Set and IntSet respectively for the stop list. In particular, they are performant on long lists with long nubs, unlike the basic nub. My implementation is available via git at git://svcs.cs.pdx.edu/git/nub.git or can be browsed at http://svcs.cs.pdx.edu/gitweb?p=nub.git;a=tree and has a maybe-outdated tarball at http://svcs.cs.pdx.edu/haskell/nub.tar.gz The Nub.hs file itself is attached to the proposal. If the proposal is accepted, I will prepare a patch against current GHC library top-of-tree, but for now it seems easier for everyone to just look at the bits in their current natural habitat.

15 31

export toDescList from Data.Map
by Evan Laforge 25 Nov '09

25 Nov '09

So, I mentioned this a long time ago but didn't get any responses and then I got distracted. So this time I added a ticket and patch and everything: 2580 Here's the text: It's even implemented, but not exported. Without this, there's apparently no way to iterate over a map from high to low, since foldl is also not exported. Also, I implemented a toDescList for IntMap, and could do the same for Set, and could add those patches, if people agree it's a good idea. In addition, is there any problem with exporting foldl aka descending for the three modules? I implemented a foldl for IntMap and it seems to work, but I'd want someone smarter to look for problems with it. In addition, Set and Map are inconsistent with folds: Set exports 'fold' and says "no order is guaranteed", but it's just defined to foldr, which is in ascending order. Set.foldr itself is not exported. Meanwhile, Map also exports fold, but heavily implies from the doc that it's guaranteed to be ascending. Would it restrict implementation changes too much to export a descending fold for all three? Other languages that have tree oriented general purpose maps all let you start anywhere and iterate in either direction. Anyway, is 2-3 weeks ok for discussion period? The library submission wiki doesn't say how long.

6 13

Splitting SYB from the base package in GHC 6.10
by José Pedro Magalhães 16 Nov '08

16 Nov '08

Hello all, I'm initiating this discussion per suggestion of SP Jones and following from [1]. The issue is: SYB is being moved out of base into its own package. However, the Data class is, in a way, tied to base since it depends on the deriving mechanism. Therefore, it was suggested that the entire Data.Generics.Basics module [2] should remain in base. This module defines the Data class and several associated functions and datatypes. I don't think anyone objected to this so far: please correct me if I'm wrong, or object now. Then it was also suggested that Data.Generics.Instances [3] could stay in base (perhaps inside Basics as well). This, however, would prevent dealing with the "dubious" Data instances [4], and this was one of the motivating factors to split SYB from base. This refers concretely to the instances: instance (Data a, Data b) => Data (a -> b) instance Typeable a => Data (IO a) instance Typeable a => Data (Ptr a) instance Typeable a => Data (StablePtr a) instance Typeable a => Data (IORef a) instance Typeable a => Data (ForeignPtr a) instance (Typeable s, Typeable a) => Data (ST s a) instance Typeable a => Data (TVar a) instance Typeable a => Data (MVar a) instance Typeable a => Data (STM a) instance (Data a, Integral a) => Data (Ratio a) These instances are defined in such a way that they do not traverse the datatype. In fact, there is no other possible implementation, and this implementation at least allows for datatypes which contain both "regular" and "dubious" elements to still have their "regular" elements traversed. However, this implies that a user cannot redefine such instances even in the case where s/he knows extra information about these types that would allow for a more useful instance definition, for instance. Claus, please correct me if I'm wrong, but if the 11 "dubious" instances (or perhaps less, given your message in [5]) go in the syb package and the remaining, "standard" ones stay in base, we: - Mantain backwards compatibility regarding SYB in 6.10, and - Can still deal with the issue by releasing a new version of the syb package later, independently of GHC. Since the deadline for 6.10 is approaching I'm assuming that we should try to minimize the changes there, while keeping future development in the syb package as open as possible. Finally, there are module naming issues, which are probably secondary to the issue above and can be dealt with separately and later. Thanks, Pedro [1] The base library and GHC 6.10: http://thread.gmane.org/gmane.comp.lang.haskell.libraries/9929 [2] http://www.haskell.org/ghc/dist/stable/docs/libraries/base/Data-Generics-Ba… [3] http://www.haskell.org/ghc/dist/stable/docs/libraries/base/Data-Generics-In… [4] http://www.haskell.org/pipermail/generics/2008-June/000347.html [5] http://article.gmane.org/gmane.comp.lang.haskell.libraries/9957

11 46

darcs patch: Added list operations for arrows
by Peter Collingbourne 05 Nov '08

05 Nov '08

Hello, This patch adds two arrow combinators which I have found useful: mapA (equivalent of map) and filterA (equivalent of filter). Thu Oct 30 16:50:02 GMT 2008 Peter Collingbourne <pcc03(a)doc.ic.ac.uk> * Added list operations for arrows Thanks, -- Peter

7 10

HUnit in Hackage
by Jon Strait 01 Nov '08

01 Nov '08

Just some quick user feedback/questions. The current HUnit in Hackage depends on base (==4.*). I'm running GHC 6.8.3 with base 3.0.2.0. Is there an easier way to upgrade base without rebuilding GHC? Otherwise, the Cabal upgrade refuses to work unless I uninstall my older HUnit completely, do the Cabal upgrade, then re-install the older HUnit. I have other packages which depend on HUnit, so this must be done every time. Or is there a way to tell Cabal Install that I want to mask off HUnit for upgrading when I do a Cabal upgrade? Thanks, Jon

2 2

configVerbose, writeHookedBuildInfo
by Johannes Waldmann 29 Oct '08

29 Oct '08

Hello. these things seem to have gone missing from Cabal-1.4 to 1.6: configVerbose writeHookedBuildInfo this is from a Setup.lhs posted here: http://article.gmane.org/gmane.comp.lang.haskell.libraries/7628 now what? I knew to insert build-depends: base==3.* but here I'm lost. J.W.

2 3

Some QuickCheck Instances
by Dominic Steinitz 25 Oct '08

25 Oct '08

I often find I need to use QuickCheck & SmallCheck with e.g. Word8 but there don't seem to be standard instances. Would these be worth adding? If so, what would I need to do? Just send a patch to the maintainers? Thanks, Dominic. > > instance Serial Word8 where > series d = drawnFrom (map fromIntegral [0..d]) > instance Arbitrary Word8 where > arbitrary = > do n <- choose ((fromIntegral (minBound::Word8))::Int, > (fromIntegral (maxBound::Word8))::Int) > return (fromIntegral n) > > instance Arbitrary Word64 where > arbitrary = > do n <- choose ((fromIntegral (minBound::Word64))::Integer, > (fromIntegral (maxBound::Word64))::Integer) > return (fromIntegral n) > > instance Arbitrary Word128 where > arbitrary = > do n <- choose ((fromIntegral (minBound::Word128))::Integer, > (fromIntegral (maxBound::Word128))::Integer) > return (fromIntegral n) >

1 0

fgl version missing on hackage
by Christian Maeder 23 Oct '08

23 Oct '08

Hi Ross, on http://hackage.haskell.org/cgi-bin/hackage-scripts/package/fgl there are fgl-versions 5.3, 5.4.1.1 However, ghc-6.8.3 was shipped with fgl-5.4.2.0 fgl-5.4.2.0 exports more functions (ie. xdfsWith) and I would like to use it with other ghc versions, too. Could you upload fgl-5.4.2.0? Cheers Christian

3 5

Proposal #2717: Add nubWith, nubOrd
by Bart Massey 23 Oct '08

23 Oct '08

Ok, I've killed the overly ambitious proposal #2629, and replaced it with the more modest proposal #2717 http://hackage.haskell.org/trac/ghc/ticket/2717 which just adds Data.List.nubWith and Data.Set.nubOrd as previously discussed ad nauseam. I know at least one person thought that adding these was a bad idea, but some others thought it was a fine thing to do. Hence the discussion on this list. Bart Massey bart(a)cs.pdx.edu

6 8