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

Re: [Haskell-cafe] Just for a laugh...
by John Meacham 31 May '07

31 May '07

On Thu, May 31, 2007 at 08:47:28PM +0100, Andrew Coppin wrote: > My first instinct was to use Data.Bits - but I see no instance for > Double. (Presumably because performing bitwise operations on a Double is > a pretty odd thing to want to do.) So my next guess is to do some > bizzare type system hackery that allows you to transform a Double > into... whichever integer type is the same size, and proceed from there. > Does anybody know how to do that? This reminds me. it would be nice if we could remove the 'Num' superclass of Bits, having bitwise operations and being a number are fairly unrelated and having to declare bogus instances is annoying. It is probably just a holdover from C that we think of them as related. 'Bool' would be a simple example of something that is a good instance of bits, but not Num. John -- John Meacham - ⑆repetae.net⑆john⑈

1 0

darcs patch: Add proximal lookup functions in Map (and 2 more)
by Adam Langley 31 May '07

31 May '07

Please see attached 2 patches (and 1 misc patch) to Data.Map which add the ability to lookup entries by proximity. For example, if I have a Map which relates times to the state of a system at that time: let m = Map.fromList [(1, x), (10, y), (15, z)] Then, if I want to find out the state at time 5: Map.nearestLesserOrEqual 5 m -> (1, x) In a similar fashion, nearestGreaterOrEqual and nearest are also provided. Thanks AGL Tue May 22 10:15:05 PDT 2007 agl(a)imperialviolet.org * Add proximal lookup functions in Map These functions require the key to be an instance of Num, because they use the numerical distance, |x-y|, to find elements in a map which are close to a query key. This is useful, for example, if the map is mapping times to state changes and you want to find out the state at any given time. Tue May 22 10:16:00 PDT 2007 agl(a)imperialviolet.org * Update deprecated Debug.QuickCheck name Tue May 22 10:16:28 PDT 2007 agl(a)imperialviolet.org * Add tests for proximal lookup functions -- Adam Langley agl(a)imperialviolet.org http://www.imperialviolet.org 650-283-9641

5 7

uploading tagged core/extra libs to hackage
by dons＠cse.unsw.edu.au 30 May '07

30 May '07

After the recent GHC 6.6.1 release, a number of the core and extra libs got new tags. In particular, xmonad wants X11 1.2.1, which was tagged during the 6.6.1 ghc release, but not uploaded to hackage. Igloo, could these newly tagged libs be uploaded? (We're holding up an xmonad release, to get X11 1.2.1 onto hackage first) -- Don

2 1

IPv6 support patches for network - please apply
by Bryan O'Sullivan 30 May '07

30 May '07

Hi - As there's been no recent discussion of my patches to add IPv6 support to the network library, and I've resolved every question and comment that people had, I propose that they now be applied. The trac ticket is here: http://hackage.haskell.org/trac/ghc/ticket/1212 And the darcs patches against network are here: http://darcs.serpentine.com/network6 Thanks, <b

2 3

HUnit broken for GHC
by Martin Grabmueller 30 May '07

30 May '07

Hello all, I noticed that HUnit does not work for GHC when trying to build some HUnit test cases for my code. There is already an (old) entry in the GHC bugtracker http://cvs.haskell.org/trac/ghc/ticket/476 about this issue, which contained a patch. Somehow, this patch never made it into the HUnit repository. I have tried out the patch with the HUnit and GHC fresh from darcs, and it seemed to work. So my question is: what is the procedure for getting this patch into the official darcs repository? A simple "darcs send"? Thanks, Martin

2 1

package haskell-src depending on happy?
by Andreas Marth 30 May '07

30 May '07

Hi! I just tried to install haskell-src with cabal and passed 'runhaskell setup.hs configure' but 'runhaskell setup.hs build' died with "Language\Haskell\Parser.ly: no happy preprocessor available". This looks to me like happy is required for haskell-src, but it is not mentenied in the dependencies. Do I really have to install happy? (In the past that was a nightmare if I remember correctly.) My system is Win2k and ghc-6.1.1. Kind regards Andreas

2 1

darcs patch: Control.Concurrent documentation fix
by shae＠ScannedInAvian.com 29 May '07

29 May '07

Thu May 24 11:33:25 CDT 2007 shae(a)ScannedInAvian.com * Control.Concurrent documentation fix

2 1

darcs patch: base.cabal: install all include files from include/
by Bertram Felgenhauer 22 May '07

22 May '07

Hi, the base package needs to install some more header files to make compilations via C work properly (as required, for example, by gtk2hs). This can now be done properly with Cabal. See the patch below. Bertram Sat May 19 15:47:19 CEST 2007 Bertram Felgenhauer <int-e(a)gmx.de> * base.cabal: install all include files from include/ many of them are needed by HsBase.h; Typeable.h is useful for Haskell code

2 1

Re: anyone interested in developing a Language.C library?
by Stephen Tetley 21 May '07

21 May '07

Hello I've a Frown port of the c2hs parser here: http://slackwise.org/spt/files/Haskell/lang_c-2007_05_21.tar.gz I've also done some work towards packaging the original c2hs code so it follows the form of the Language/Haskell library (removed the 'C' prefix from file names, added Haddock markers in some of the comments). Other changes include some work to handle GCC attributes (added in the syntax tree and some of the productions in the parser); and some work on a pretty printer (there is a rough version implemented with UUAG and the PPrint library that needs better parens handling). Also I've changed the AST slightly to remove some of the dependency on c2hs - the parser just tracks source position rather than source locations and unique names. I haven't looked further at disentangling the Happy parser, and with the changes to the syntax tree and file layout it would need some work to reinstate it. I hope to look at this in the next couple of weeks. Best wishes Stephen Tetley Duncan Coutts wrote: > * The parser error messages are terrible (it might be interesting > to try porting from happy to frown for this purpose)

1 0