May 2009 - Libraries - Haskell.org

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

Bug in old-locale?
by Deniz Dogan 11 Jul '09

11 Jul '09

Hi Is there a bug in the old-locale package? I tried the following simple program: import Data.Time import System.Locale main = do time <- getCurrentTime putStrLn $ formatTime defaultTimeLocale rfc822DateFormat time The above program prints: Mon, d Apr 2009 15:23:56 UTC Notice "Mon, d", where "d" should be the day of the month. Looking at the source code in the package, I see: rfc822DateFormat = "%a, %_d %b %Y %H:%M:%S %Z" So what's up with %_d? -- Deniz Dogan

4 6

draft proposal for relative paths in installed package descriptions
by Duncan Coutts 01 Jun '09

01 Jun '09

All, This is a draft proposal for a common mechanism for implementing relative paths in installed package descriptions. Comments and feedback are welcome. I'm cc'ing this to the cabal and ghc-users lists but let's keep the discussion on the libraries list. There has been some discussion of this issue on the cabal and ghc-users list, but it's a relatively long thread and the idea has evolved somewhat so this is an attempt to present the proposal clearly. Proposal ======== This proposal is an extension to the Cabal spec section 3 http://haskell.org/cabal/proposal/x272.html Motivation ---------- Being able to have relative paths in the installed package description is useful as it makes it possible to construct relocatable (prefix-independent) package installations. This is useful when distributing compilers along with packages and there may be other uses. This proposal does not require that all paths are relative. It is still perfectly ok to use absolute paths where appropriate. It just adds an option to use relative paths. The aim is for a single simple specification that any compiler can implement and have the tools work uniformly, rather than ad-hoc implementations for each compiler. Details ------- In the installed package description, we will allow paths that begin with the variables ${pkgroot} or ${pkgrooturl}. For example: library-dirs: ${pkgroot}/foo-1.0 haddock-html: ${pkgrooturl}/doc/foo-1.0 They may only appear at the beginning of the paths and must be followed by a directory separator (platform-dependent '/' or '\'). This is because the vars refer to a directory so it does not make sense to construct extensions like ${pkgroot}blah. The use of '{}' is required and is to avoid any ambiguity (especially since the string "$pkgrooturl" is otherwise an extension of "$pkgroot"). Directly relative file paths like "blah" or "./blah" are not allowed. Fields containing paths must be absolute or begin with ${pkgroot}. Field containing urls must be absolute or begin with ${pkgrooturl}. The var ${pkgroot} is to be interpreted as the directory containing the installed package description. For ghc this will be the dir containing the package.conf db, for hugs/nhc for each package there is a specific installed package description file, and ${pkgroot} is thus the directory containing that file. The syntax of the string representing this directory is the usual system-dependent filepath syntax, e.g. windows: c:\ghc\ghc-6.12.1 unix: /opt/ghc-6.12.1 The var ${pkgrooturl} is to be interpreted as a url representation of the directory containing the installed package description. For ghc this will be the dir containing the package.conf db, for hugs/nhc for each package there is a specific installed package description file, and ${pkgroot} is thus the directory containing that file. The syntax of the string representing this directory is as a valid file url including the file:// prefix e.g. windows: file:///c:/ghc/ghc-6.12.1 unix: file:///opt/ghc-6.12.1 This is similar to how relative paths in .cabal files are interpreted relative to the directory containing the .cabal file, however in this case we mark relative paths more explicitly using a variable. So in the original example library-dirs: ${pkgroot}/foo-1.0 haddock-html: ${pkgrooturl}/doc/foo-1.0 If we assume this installed package description is at c:\ghc\ghc-6.12.1 \package.conf on windows or /opt/ghc-6.12.1/package.conf on unix then the compiler and other tools would interpret these as library-dirs: c:\ghc\ghc-6.12.1/foo-1.0 haddock-html: file:///c:/ghc/ghc-6.12.1/doc/foo-1.0 or on unix: library-dirs: /opt/ghc-6.12.1/foo-1.0 haddock-html: file:///opt/ghc-6.12.1/doc/foo-1.0 Tools ----- Tools which process the installed package description format will be expected to interpret these relative paths. This requires that they can discover the path for the ${pkgroot}. How they discover this is dependent on the Haskell implementation. Some implementations use separate files for each installed package description, some embed them in library package files, some use databases of installed package descriptions. Haskell implementations should provide a mechanism to discover the path for an installed package description. Duncan

2 2

Patch to register XmlSyntax and RegularPatterns as known extensions
by Niklas Broberg 01 Jun '09

01 Jun '09

Hi all, I'd like to have concrete XML syntax (HSP) and regular expression pattern syntax (HaRP) registered in Language.Haskell.Extension. The attached patch registers XmlSyntax and RegularPatterns as constructors in the Language.Haskell.Extension.Extension data type, along with haddock documentation. Cheers, /Niklas

4 8

cabal: confusing dependencies conflict between ghc-6.10.1 and process
by Sebastian Fischer 29 May '09

29 May '09

Hello, I get a confusing message when trying to install 'vacuum' from Hackage: $ cabal install vacuum Resolving dependencies... cabal: dependencies conflict: ghc-6.10.1 requires process ==1.0.1.1 however process-1.0.1.1 was excluded because ghc-6.10.1 requires process ==1.0.1.0 There is something wrong: according to this message, the package ghc-6.10.1 requires both process==1.0.1.1 and process==1.0.1.0. According to ghc-pkg, the package ghc-6.10.1 requires process==1.0.1.0: $ ghc-pkg describe ghc name: ghc version: 6.10.1 [...] depends: Cabal-1.6.0.1 array-0.2.0.0 base-4.0.0.0 bytestring-0.9.1.4 containers-0.2.0.0 directory-1.0.0.2 editline-0.2.1.0 filepath-1.1.0.1 haskell98-1.0.1.0 hpc-0.5.0.2 old-time-1.0.0.1 process-1.0.1.0 template-haskell-2.3.0.0 unix-2.3.1.0 [...] Why does cabal think that ghc-6.10.1 requires process==1.0.1.1? I use $ ghc --version The Glorious Glasgow Haskell Compilation System, version 6.10.1 $ cabal --version cabal-install version 0.6.2 using version 1.6.0.2 of the Cabal library Is it a problem that cabal uses version 1.6.0.2 of the Cabala library but the package ghc-6.10.1 requires version 1.6.0.1? Cheers, Sebastian

3 4

time library dependencies
by Ashley Yakeley 29 May '09

29 May '09

I'm looking to update the time library in response to various requests. Right now it has some weird split-base 2/3 dependency thing going on, and uses only FFI and CPP language extensions. Will it cause anyone any problems if * it depends >=base-4.1? * it requires GeneralizedNewtypeDeriving and DeriveDataTypeable to build? The Haskell language is kind of a moving target right now. -- Ashley Yakeley

1 0

time package - parsing of incorrect data
by Paolo Losi 26 May '09

26 May '09

Hi all, I'm experimenting with time package parsing functionalities. I'm trying to verify what happens with inconsistent input data. From what I've seen, incorrect days are "truncated" while incorrect hours are left unmodified leading to inconsistent data. Is this the intended behaviour? Would it be more appropriate to return a parsing Error (Nothing in the following example)? with time-1.1.3: > parseTime defaultTimeLocale "%Y-%m-%d %H:%M" "2008-04-31 25:30" :: Maybe LocalTime Just 2008-04-30 25:30:00 Thanks Paolo

2 2

Patch to expose reportProgram in Distribution.Simple.Configure
by Dominic Steinitz 25 May '09

25 May '09

I found this useful - see http://code.haskell.org/asn1/Setup.hs for an example. Dominic.

1 0