August 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

Bugfix for QuickCheck 1.1.0.0
by Patrick Perry 09 Oct '08

09 Oct '08

Hi everyone, I've put in a proposal that fixes a bug in QuickCheck 1.1.0.0. http://hackage.haskell.org/trac/ghc/ticket/2535 Thanks, Patrick

6 10

The base library and GHC 6.10
by Ian Lynagh 30 Sep '08

30 Sep '08

Hi all, We're trying to decide what to do with the base library for GHC 6.10, in terms of how much of it should be broken up into separate packages. Since the recent proposal about this, we may be rethinking what we want to do, and we would welcome your opinions. First, the motivation for splitting base up: It becomes possible to separately upgrade the parts, and makes it easier for different people to maintain different parts. It makes it easier to see what the hierarchy is, and to restructure the hierarchy, and work towards more of the code being shared between different Haskell implementations. Plus it means that people can't re-tangle the logically separate components, which is all too easy to do when you just have one huge package. It also means that packages are clearer about what they depend on. One possibility, which would be really cool, is to separate all the IO modules from the non-IO modules; between that and looking at the extensions used (e.g. TH and FFI) it would then be clear whether or not a library could do any IO. Of course, the Prelude is a hurdle for this goal. Also, GHC's current plan for the base library: http://hackage.haskell.org/trac/ghc/wiki/DarcsConversion#Planforlibraries essentially means forking base (as nhc98 would continue to use base in a darcs repo, while GHC would use it from a git repo, and there are no plans for any merging between these repos). Therefore any code that is to be shared between the implementations needs to not be in base, so from that point of view it would be good to pull out as much as possible. The main argument /against/ splitting base up is that at some point the dependencies of packages need to be updated to reflect the changes. However, GHC 6.10 will come with a base version 3, as well as the new base version 4, so the transition should be much smoother than the base 2 -> base 3 transition. Now, on with the proposed splitting. In the below, LoC stands for "Lines of Code". First the easy bit: The Data.Generics hierarchy is going to have a separate maintainer, and I think that everyone is agreed that it should be pulled out into an "syb package". I'll treat this as not part of base from here on. The only thing still being debated here is whether the Data class itself should remain in base or not. Some people believe that it should remain in base, as it is desirable to have Data instances for as many types as possible, and because there is a resistance among library writers against adding dependencies. The counter argument is that there are many other classes that the same is true of (e.g. uniplate, syb-with-class, binary), and it does not scale to put all of these classes into base. Also, by requiring a dep to be added even for the classes that have historically been included in base, adding dependencies for the sake of providing instances may become more socially acceptable. Now, on with the splitting. We have System.Console.GetOpt (129 LoC, 1 module) This doesn't really fit in with anything else in base, so the proposal is to split it off into its own getopt package. I don't think there is much objection to this one. Next we have the Control.Monad.ST Data.STRef (120 LoC, 6 modules) hierarchies. The proposal is to put these into an st package. The low-level implementation is still in base (69 LoC of in the GHC.ST and GHC.STRef), so to some extent this is a false separation. On the other hand, nhc98 doesn't support ST, so splitting this package off gets us closer to all implementations exposing the same modules from base. Then we have Control.Concurrent (490 LoC, 6 modules) hierarchy, along with System.Timeout (39 LoC) Data.Unique (32 LoC) (those modules depend on Control.Concurrent.*). The proposal is to put these into concurrent, timout and unique packages respectively. Again, this is a false separation, with 698 LoC left behind in GHC.Conc; at some time we'd hope that this could either be moved down to ghc-prim, or make a new ghc-concurrent package for it, depending on how the dependencies work out. Again, nhc doesn't support concurrent or its dependencies, so this gets us closer to a consistent base interface. Splitting off the above 5 packages would leave 106 modules and 16621 LoC in base. About 5% of the LoC, and 12.5% of the modules, would be in the new packages. Thanks Ian

16 65

Unhelpful library documentation
by Gwern Branwen 13 Sep '08

13 Sep '08

I don't know if everyone has seen this, so I thought I'd mention this: <http://lukeplant.me.uk/blog.php?id=1107301692> > "Haskell API docs suck. A lot." "Haskell API documentation is very lacking for newbies. For instance, I want to understand how to create and use regexes. If you start at Text.Regex.Posix documentation, it tells you that =~ and =~~ are the high level API, and the hyperlinks for those functions go to Text.Regex.Posix.Wrap, where the main functions are not actually documented at all!" "Since Haskell libraries are almost always implemented by Haskell gurus, and they implement them with themselves in mind (I have no objection to this, they are enthusiasts working for free), they use lots of clever code and advanced Haskell techniques. But this means that if you want people to actually use these libraries (and by consequence Haskell itself), the documentation for Haskell libraries has to be about an order of magnitude better than anything you'd find anywhere else. I suspect it is at least an order of magnitude worse than for something like .NET APIs, which means that relatively speaking the documentation of Haskell is currently in an absolutely dire state." These are all interesting points, but I found most interesting the conclusion: "Moving forward, I guess one problem is contributing to a library's documentation. There is nothing on the API doc pages that shows you how to do this. I suspect you need to check out the source with darcs (not something I do normally, I just use cabal) and then start email patches or something. Even then, I don't know if I would contribute any documentation -- 'howto' style documentation seems out of place on the API pages, but it is desperately needed." So, what can be done here? Offhand, I want to suggest adding a link to some sort of tutorial module or wiki page. Each page *does* mention that 'Maintainer libraries(a)haskell.org', but this really isn't helpful; it doesn't tell you where to get the original library source code, how to edit, what libraries@ *is* (anyone with a brain in their head is going to know that libraries@ is some sort of group interface, and is going to refrain from emailing it until they know that they aren't cluelessly spamming/offending potentially hundreds of Haskellers), and so on. Even better would be a link in the Description to the source: 'Control.Concurrent.QSemN is a module in the concurrent package; you can 'darcs get' it from http://foo.... For contributing, please module Contributing/wiki page haskell.org/wiki/Contributing_to_libraries', etc. Thoughts? -- gwern plutonium industrial UHF Reaction and data POCSAG Finksburg Merlin fake

4 5

#2532: Add Typeable instance to Data.Unique
by Jim Apple 07 Sep '08

07 Sep '08

http://hackage.haskell.org/trac/ghc/ticket/2532 Discussion deadline: Sept 7 Jim

3 5

Performance horrors
by Adrian Hey 06 Sep '08

06 Sep '08

Hello Folks, I was looking at the definitions of nub (and hence nubBy) recently in connection with a trac ticket and realised that this is O(n^2) complexity! Ouch! I was going to say I sure hope nobody uses this in real programs, but I thought I'd better check first and I see that darcs seems to use it in a few places. Hmm.. How did we ever get stuff like this in the standard libs? I can only imagine this is relic from the days when Haskell was only used for research or pedagogical purposes only (not for real programs). Seeing as practically all Eq instances are also Ord instances, at the very least we could have O(n*(log n)) definitions for .. nub :: Ord a => [a] -> [a] nub = nubBy compare nubBy :: (a -> a -> Ordering) -> [a] -> [a] nubBy cmp xs ys = -- something using an AVL tree perhaps. ..or even better using the generalised trie stuff Jamie Brandon has been working on. Of course I'm not actually advocating this as it's probably bad policy to have a simple standard lib dependent on any complex non-standard lib. But if it just isn't possible to implement some functions with reasonable efficiency using simple definitions only then I think they really shouldn't be there at all. Instead we should make users "roll their own" using whatever complex non-standard lib they want. So could nub and nubBy be deprecated and an appropriate health warning added to the Haddock? In the mean time I think I'll put appropriate alternative definitions in the next AVL release and ask Jamie Brandon to consider doing the same in his generalised tries lib (GMap). Also, looking at a few other functions there like union(By) and intersection(By) make me quite suspicious. Maybe we need a thorough performance audit to get rid of implementations that are so insanely inefficient they should *never* be used. Regards -- Adrian Hey

16 32

darcs patch: Unbreak the GHC build with older versions of gcc
by kili＠outback.escape.de 04 Sep '08

04 Sep '08

Thu Aug 28 16:27:43 CEST 2008 kili(a)outback.escape.de * Unbreak the GHC build with older versions of gcc Stg.h must be included before HsBase.h, because the latter contains function definitions causing older versions of gcc (3.3.5 in my case) to bail out with "error: global register variable follows a function definition" on Regs.h, which is included by Stg.h.

2 2

Arrow without `>>>'
by Valery V. Vorotyntsev 03 Sep '08

03 Sep '08

Hi, friends, I've built GHC from darcs, and... Could anybody tell me, what's the purpose of Arrow[1] not having `>>>' method? 1. http://darcs.haskell.org/packages/base/Control/Arrow.hs $ ghci GHCi, version 6.9.20080104: http://www.haskell.org/ghc/ :? for help Loading package base ... linking ... done. Prelude> :m + Control.Arrow Prelude Control.Arrow> :i Arrow class (Control.Category.Category a) => Arrow a where arr :: (b -> c) -> a b c pure :: (b -> c) -> a b c first :: a b c -> a (b, d) (c, d) second :: a b c -> a (d, b) (d, c) (***) :: a b c -> a b' c' -> a (b, b') (c, c') (&&&) :: a b c -> a b c' -> a b (c, c') -- Defined in Control.Arrow instance Arrow (->) -- Defined in Control.Arrow instance (Monad m) => Arrow (Kleisli m) -- Defined in Control.Arrow Prelude Control.Arrow> Leaving GHCi. I can't build[2] arrows-0.3 package without `>>>' in Arrow. 2. vvv@fun:~/src/arrows$ darcs w { hunk ./Control/Arrow/Operations.hs 36 +import Control.Category ((>>>)) hunk ./Control/Arrow/Transformer/CoState.hs 23 +import Control.Category ((>>>)) } vvv@fun:~/src/arrows$ runhaskell Setup build Preprocessing library arrows-0.3... Building arrows-0.3... [ 3 of 12] Compiling Control.Arrow.Transformer.CoState ( Control/Arrow/Transformer/CoState.hs, dist/build/Control/Arrow/Transformer/CoState.o ) Control/Arrow/Transformer/CoState.hs:29:7: `>>>' is not a (visible) method of class `Arrow' The question arises "should I?", but this is one of lambdabot's[3] depencies. 3. http://code.haskell.org/lambdabot/ Thanks a lot! -- vvv

4 5

2533: Generic functions that take integral arguments should work the same way as their prelude counterparts
by Jim Apple 30 Aug '08

30 Aug '08

http://hackage.haskell.org/trac/ghc/ticket/2533 Deadline: Sept 7 The Prelude functions drop, take, and splitAt are unfailing (never call error). This patch changes the Data.List generic versions to behave the same way. At present, they call error on negative arguments. Jim

16 25

Historical question about type of Data.List.group
by Jim Apple 30 Aug '08

30 Aug '08

Why isn't the type of group Eq a => [a] -> [(a,[a])] That matches more exactly what group does, and it's easy to see that functions like nubOrd = map fst . group . sort are clearly safe, whereas map head . group . sort is not. Jim

4 4