October 2007 - 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

Data.Map, Data.IntMap documentation
by Andriy Palamarchuk 19 Mar '08

19 Mar '08

Improved, fixed documentation for Data.Map, Data.IntMap. Moved time complexity Big-O values to the end of function descriptions. Added examples. For the initial review I submitted only changes for Data.Map. I'll update IntMap for the final review. Deadline - August 27 (two weeks). Ticket: http://hackage.haskell.org/trac/ghc/ticket/1611 Haddock output: http://hackage.haskell.org/trac/ghc/attachment/ticket/1611/Data-Map.html?fo… The module source and diff are also attached to the ticket. Andriy ____________________________________________________________________________________ Pinpoint customers who are looking for what you sell. http://searchmarketing.yahoo.com/

17 50

PROPOSAL: Add Data.Set.mapMaybe
by Thomas Schilling 31 Oct '07

31 Oct '07

Hi there. I recently find myself missing Data.Set.mapMaybe. This function is implemented for Data.Map.Map, but is strangely missing from Data.Set.mapMaybe. I believe it could be implemented using Data.Foldable, but not as efficiently. The obvious implementation would be: mapMaybe :: (Ord a, Ord b) => (a -> Maybe b) -> Set a -> Set b mapMaybe f Tip = Tip mapMaybe f (Bin _ x l r) = case f x of Nothing -> merge (mapMaybe f l) (mapMaybe f r) Just y -> union y (mapMaybe f l) (mapMaybe f r) Any comments? Preliminary deadline: Nov 21, 2007 (3 weeks)

2 4

X11-extras merged into X11 library
by Don Stewart 30 Oct '07

30 Oct '07

This is a heads up about the X11 library. For the past 6 months a set of extensions, required by xmonad, to this library have been developed in the so-called X11-extras package. The time came to merge these together, finally. A new head branch of X11 has been created, which lives at: darcs.haskell.org/X11 with the merged source (adding support for xinerama, window manger stuff, X events, X fonts and more). This has also been tagged as X11 1.3.0 (following the versioning spec), and uploaded to hackage. Any stable branch ghc wishes to use for its extras bundle can still be found at darcs.haskell.org/packages/X11. -- Don

1 0

Re: [Haskell] Re: Trying to install binary-0.4
by Simon Marlow 29 Oct '07

29 Oct '07

Duncan and I have started a wiki page to collect proposals for ways to avoid or alleviate the pain from future package reorganisations. http://hackage.haskell.org/trac/ghc/wiki/PackageCompatibility It's been helpful for me to write all this down, the issues seem much clearer. However, I don't see an obviously best solution. For me proposal 4.2 (see the wiki page) looks the most promising, but it doesn't provide complete backwards compatibility, so I imagine there will be people who disagree. Please read the page. Fix problems, add rationale, add proposals if you have any that are substantially different from those already there. For general discussion just reply to this message (replies directed to libraries(a)haskell.org) Cheers, Simon

9 18

Proposal: Add Compositor class as superclass of Arrow
by Ashley Yakeley 28 Oct '07

28 Oct '07

http://hackage.haskell.org/trac/ghc/ticket/1773 (darcs patch attached to ticket) The Compositor class has two members: class Compositor comp where identity :: comp a a (>>>) :: comp a b -> comp b c -> comp a c with the obvious monoid. Since all Arrows are Compositors, make Compositor a superclass of Arrow. A number of useful types are Compositors but not Arrows: 1. Bijections data Bijection a b = MkBijection (a -> b) (b -> a) 2. Codecs, i.e. encoder/decoder pairs such as charset converters data Codec base derived = MkCodec { encode :: derived -> base, decode :: base -> Maybe derived -- or other Monad } utf8 :: Codec [Word8] String xml :: Codec String XML 3. Lenses These make updatable sections of data structures. data Lens s t = MkLens { lensGet :: s -> t, lensPutback :: t -> s -> s } See http://www.cis.upenn.edu/~bcpierce/papers/lenses-etapsslides.pdf 4. Reified proofs of type identity These are useful if you use GADTs and type-witnesses a lot. newtype SameType a a' = MkSameType (forall f. f a -> f a') Proposal period: two weeks, until 10-27

10 39

proposal: in base, for Data.Version, change the meaning of comparisons
by Malcolm Wallace 28 Oct '07

28 Oct '07

Proposal: that values of the type Data.Version.Version should compare equal, by ignoring trailing zeros. Thus 1.2.0 == 1.2, rather than 1.2.0 > 1.2 Regards, Malcolm ---- New patches: [In Data.Version, make equality comparisons independent of trailing zeros. Malcolm.Wallace(a)cs.york.ac.uk**20071025161240] { hunk ./Data/Version.hs 122 - v1 == v2 = versionBranch v1 == versionBranch v2 + v1 == v2 = branchEq (versionBranch v1) (versionBranch v2) hunk ./Data/Version.hs 125 + where + branchEq :: [Int] -> [Int] -> Bool + branchEq [] [] = True + branchEq vs [] = all (==0) vs + branchEq [] vs = all (==0) vs + branchEq (v:vs) (w:ws) = v==w && branchEq vs ws hunk ./Data/Version.hs 133 - v1 `compare` v2 = versionBranch v1 `compare` versionBranch v2 - + v1 `compare` v2 = versionBranch v1 `cmpBranch` versionBranch v2 + where + cmpBranch [] [] = EQ + cmpBranch vs [] | all (==0) vs = EQ + | otherwise = GT + cmpBranch [] vs | all (==0) vs = EQ + | otherwise = LT + cmpBranch (v:vs) (w:ws) | v==w = cmpBranch vs ws + | otherwise = compare v w + } Context: [Fix doc building with Haddock 0.9 Simon Marlow <simonmar(a)microsoft.com>**20071024090947 I was using a recent build here, which is more tolerant. ] [FIX #1258: document that openTempFile is secure(ish) Simon Marlow <simonmar(a)microsoft.com>**20071023130928 Also change the mode from 0666 to 0600, which seems like a more sensible value and matches what C's mkstemp() does. ] [Clean up .cabal file a bit Duncan Coutts <duncan(a)haskell.org>**20071022132708 specify build-type and cabal-version >= 1.2 put extra-tmp-files in the right place use os(windows) rather than os(mingw32) ] [base in 6.8 and head branch should be version 3.0 Don Stewart <dons(a)galois.com>**20071007150408] [FIX #1652: openTempFile should accept an empty string for the directory Simon Marlow <simonmar(a)microsoft.com>**20071018122345] [clean up duplicate code Simon Marlow <simonmar(a)microsoft.com>**20071017141311] [expose the value of +RTS -N as GHC.Conc.numCapabilities (see #1733) Simon Marlow <simonmar(a)microsoft.com>**20071009132042] [typo Simon Marlow <simonmar(a)microsoft.com>**20070917130703] [put extra-tmp-files field in the right place Simon Marlow <simonmar(a)microsoft.com>**20070914140812] [Add more entries to boring file Ian Lynagh <igloo(a)earth.li>**20070913210500] [Add a boring file Ian Lynagh <igloo(a)earth.li>**20070913204641] [TAG 2007-09-13 Ian Lynagh <igloo(a)earth.li>**20070913215720] Patch bundle hash: fe636959d9254b8fabd6e7ad6926a4d0b7ee0d15

6 6

QuickCheck support in libraries
by Conal Elliott 27 Oct '07

27 Oct '07

I'd like libraries to provide QuickCheck support (instances of Arbitrary) for types they define, where possible. Are there any reasons not to routinely do so? Otherwise, I end up working them out for myself and probably replicating other people's work. - Conal

5 6

System.Win32.Types to base library?
by Felix Martini 25 Oct '07

25 Oct '07

I am working on some Windows specific code for GHC in the base library. System.Win32.Types contains basic Win32 types and error handling functions. Using them would mean a dependency on the Win32 library. I could duplicate parts of System.Win32.Types that i need, but is it not preferable to relocate System.Win32.Types to the base library? Regards, Felix

4 12

Packages within a package
by ramsdell＠mitre.org 24 Oct '07

24 Oct '07

When I first carefully read the Cabal documentation, I remember wondering why there is a limit of one on the number of libraries in a package. Reflecting on autoconf, and its AC_CONFIG_SUBDIRS macro, I also wondered why packages cannot be components of a package. If you wrote a symbolic model checker, and you want it to be used with a specific version of a binary decision diagram package, the simplest way of enforcing this restriction is by including the package within yours. This is in fact how NuSMV is distributed. (It includes CUDD.) Recently, when I discovered there is no direct support for linking the executables in a package with the library it defines, I wondered why the advice was to separate the library and the executables into two packages even though both are meant to be used and distributed as a unit. Does Cabal not support things like packages within a package simply because Haskell libraries currently are not complex enough to require such a feature, or is there a guiding design principle with which these features are incompatible? John

4 13