September 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

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

HackageDB bug in exposed modules
by Alfonso Acosta 03 Oct '08

03 Oct '08

Hi, I just uploaded a library to hackagedb: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/ForSyDe Everything went smoothly, but the webpage shows certain hidden modules (other-modules section in the cabal description) as exposed. Am I missing something or is this a bug in HackageDB? Best regards, Alfonso Acosta

3 8

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

Announce: Haskell protocol-buffers version 0.3.1
by Chris Kuklewicz 28 Sep '08

28 Sep '08

And now it is much more complete. The 'hprotoc' compiler for proto files to Haskell source code now takes a "-u" command-line option. When given, this turns on code generation to support loading, storing, and saving unknown fields. The master source code archive has been broken up into the three corresponding Haskell packages: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/protocol-buffers http://hackage.haskell.org/cgi-bin/hackage-scripts/package/protocol-buffers… http://hackage.haskell.org/cgi-bin/hackage-scripts/package/hprotoc The latest version is 0.3.1. They must be installed in the order given above (and all have been tested with the "cabal-install" command). In addition the new unknown field support, a few small bugs were fixed. In the future I will look at the new extensible proto file option and see how such support could be added to this Haskell project. Cheers, Chris

1 0

Arch Haskell News: Sep 27 2008
by Don Stewart 28 Sep '08

28 Sep '08

Highlights, * 590 Haskell packages now in Arch Linux, up 14 from last week. Noteworthy, * garsia-wachs :”A Functional Implementation of the Garsia-Wachs Algorithm * datapacker :”Tool to help pack files into the minimum number of CDs/DVDs/etc” * simple-sessions :”A simple implementation of session types” * QuickCheck 2 released * xml updated. Full details: http://archhaskell.wordpress.com/2008/09/28/arch-haskell-news-sep-27-2008/ For more information about Haskell on Arch Linux, see the wiki page, or join us online, on IRC, #arch-haskell @ freenode.

1 0

Some things about haskell-src
by Marco Túlio Gontijo e Silva 27 Sep '08

27 Sep '08

Hello, I'm using haskell-src, and I noticed that the data types defined in Language.Haskell.Syntax don't derive Ord. It makes sense, cause there's no logical way to ordenate them, but it makes it impossible to use with Data.Set functions, such as fromList. It would be good to be possible to use Data.Set with these types, so maybe including deriving Ord to the data types is a good idea. Some other thing I've thought is using operators as type constructors for some types, such as: (:.) = Qual (:$) = HsApp I don't know how much this is possible for other cases, but I think it could make the look of a parsed code clearer. Greetings. -- marcot Página: http://marcotmarcot.iaaeee.org/ Blog: http://marcotmarcot.blogspot.com/ Correio: marcot(a)riseup.net XMPP: marcot(a)jabber.org IRC: marcot(a)irc.freenode.net Telefone: 25151920 Celular: 98116720 Endereço: Rua Turfa, 639/701 Prado 30410-370 Belo Horizonte/MG Brasil

1 1