November 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

Libraries need a new owner
by Adrian Hey 27 Mar '08

27 Mar '08

Hello Folks, As some of you will be aware, I have been working on various Map implementations that currently live here.. http://code.haskell.org/collections/collections-ghc6.8 The libs in question being Data.Tree.AVL, Data.Trie.General and a few other bits like Data.COrdering and the AVL based Data.Map/Set clones. Well, I have decided to stop work on these. So they need a new owner if they're going to go anywhere. If anyone is interested in the job then I suggest they contact myself or Jean-Philippe Bernardy. Of course I will be happy to provide any help or advise anyone who takes over these libs may feel they need from me. I might even contribute a few patches from time to time myself :-) Thanks -- Adrian Hey

4 12

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

darcs patch: Data.List.sort: force elements from start to end.
by Bertram Felgenhauer 16 Jan '08

16 Jan '08

Hi, the patch below is a trivial change to the merge helper function of Data.List.sort. Its effect is that the first argument of merge is evaluated before the second argument instead of vice versa. I think it's obviously correct. Also, sort is necessarily strict in the whole list, so there can be no loss of laziness. Rationale: The change helps to avoid a stack overflow in the common case where each element of a list depends on the previous one. Examples for such lists are '[1..]' or uses of 'iterate f' where f is a strict function. I believe this case is far more common than the opposite case where each element of the list depends on the next one, so the patch below is an improvement. See also http://thread.gmane.org/gmane.comp.lang.haskell.cafe/30598 Bertram Wed Nov 21 11:14:58 CET 2007 Bertram Felgenhauer <int-e(a)gmx.de> * Data.List.sort: force elements from start to end. this prevents a stack overflow on sort (take 10^6 [1..])

2 1

new language extensions
by Duncan Coutts 07 Jan '08

07 Jan '08

All, GHC 6.8 has a lot of new names for language extensions which are not yet listed in Language.Haskell.Extension: UnicodeSyntax PatternSignatures UnliftedFFITypes LiberalTypeSynonyms TypeOperators PArr RecordWildCards RecordPuns DisambiguateRecordFields OverloadedStrings GADTs MonoPatBinds RelaxedPolyRec ExtendedDefaultRules UnboxedTuples DeriveDataTypeable ConstrainedClassMethods These are the extension names you can list in the "extensions:" field in a .cabal file and are also in the {-# LANGUAGE #-} pragma. So I propose we add all of these to the Extension enumeration data type. I'd like to keep this addition separate from the proposal to make Extension a String or newtype String, since I expect even in that case we need a central list of extensions so different implementations can agree on names when they implement the same extensions, or to ensure they pick different names for different extensions. It'd also be nice if we could document all these extensions in the Language.Haskell.Extension module so we can refer to it from the cabal documentation about the extensions field. Duncan

5 10

GHC's CPP and Cabal's unlit
by Alistair Bayley 04 Dec '07

04 Dec '07

I'm doing some testing with GHC 6.6.1 and Cabal 1.3, and I'm trying to figure out what happens with CPP and Cabal's unlit. I start with file Test.lhs: > {-# OPTIONS -fglasgow-exts #-} > module Test where > main = putStrLn "hello CPP" and run command: ghc -E -x hs -cpp Test.lhs -o Test2.lhs which gives me Test2.lhs: {-# LINE 1 "Test.lhs" #-} # 1 "Test.lhs" # 1 "<built-in>" # 1 "<command line>" # 1 "Test.lhs" > {-# OPTIONS -fglasgow-exts #-} > module Test where > main = putStrLn "hello CPP" So I'm wondering: where does the {-# LINE #-} comment come from, and also the # 1 lines? AFAICT the # 1 lines are ignored by GHC; I can compile Test2.lhs without errors. Is there anything in GHC's docs about this? More puzzling is that the files that Cabal runs through ghc's CPP don't get the # n lines, so we end up with something like this: {-# LINE 1 "Test.lhs" #-} > {-# OPTIONS -fglasgow-exts #-} > module Test where > main = putStrLn "hello CPP" which is not a valid .lhs file, because we have a code line next to a comment. I also note in Cabal the haddock command runs CPP before unlit. GHC does it the other way around i.e. run unlit first then CPP, and I'm wondering if Cabal shouldn't do the same thing? Thanks, Alistair

3 8

Maybe Monoid spilt milk
by Conor McBride 04 Dec '07

04 Dec '07

Hi folks I realise I should have been paying more attention last March, and as such have no reason to expect any sympathy, let alone action. I would, however, like to comment on the fact that the Data.Monoid instance for (Maybe x) prioritises monoidal structure from x over monoidal structure from Maybe. This makes it hard to use generic monoidal operations to support choice in the Maybe monad. I don't know if this breaks anybody else's code, but it certainly breaks mine. I guess I'll just have to stop using Data.Monoid and roll my own. That's not a serious hardship, I suppose. I have only myself to blame, and I'm not proposing that the Maybe behaviour is changed. I suppose people are busy enjoying the instance as it now stands, and that it would be damaging to change. What a pity Conor http://www.cs.nott.ac.uk/~ctm This message has been checked for viruses but the contents of an attachment may still contain software viruses, which could damage your computer system: you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation.

5 5

Fwd: 2 GHCs => can't resolve Cabal dependencies
by Valery V. Vorotyntsev 30 Nov '07

30 Nov '07

---------- Forwarded message ---------- From: Valery V. Vorotyntsev <valery.vv(a)gmail.com> Date: Dec 1, 2007 12:40 AM Subject: 2 GHCs => can't resolve Cabal dependencies To: cvs-ghc(a)haskell.org Hi, I've installed GHC from darcs recently (following http://hackage.haskell.org/trac/ghc/wiki/Building/Hacking instructions), and come into issue with Cabal dependencies: http://hpaste.org/4182 I suspect my GHC configuration to be broken. Could you please help me investigate the problem? Thanks. :) -- vvv

1 0

darcs patch: Don't test for rl_completion_word_break_hook with -lreadline if we're using GNUreadline.framework.
by Judah Jacobson 29 Nov '07

29 Nov '07

Looking over some buildbot logs, I realized the following issue with the readline configure script: It always adds an extra -lreadline when checking for rl_completion_word_break_hook, despite the fact that sometimes we want to link with -framework GNUreadline. Thanks, -Judah * Don't test for rl_completion_word_break_hook with -lreadline if we're using GNUreadline.framework. M ./configure.ac -2 +2

1 0

Supporting various versions of Cabal
by Alistair Bayley 29 Nov '07

29 Nov '07

Hello, Is there a story for supporting various versions of Cabal in a package? For Takusen we now have three different Setup.lhs files, for Cabal versions 1.1.4, 1.1.6.2, and 1.2. I'm not sure I want to discard the Setup scripts for the older versions, as this allows users with older installations to use Takusen without being forced to upgrade their Cabal package. However, I'm also conscious that latest Cabal works with versions of ghc back to 6.4 (if not earlier), so is this a non-issue? Is it reasonable to require users to upgrade Cabal to a newer version than the one that ships with their compiler, just to get your package to build? Thanks, Alistair

2 1