December 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

QuickCheck properties for IntSet
by David Benbennick 01 May '08

01 May '08

Here's a patch to IntSet.hs that adds many QuickCheck properties. It adds properties testing almost all of the public interface of IntSet, and also properties testing that the data type invariants are never broken. (The patch doesn't test the Data, Eq, Monoid, Read, or Typeable instances.) Also, this patch removes a helper function, foldlStrict, and replaces it with calls to Data.List.foldl'. I have two questions: 1) Is this the right way to submit patches? 2) Is there a good reason that IntSet doesn't use "deriving Eq", and instead manually implements the Eq instance?

5 21

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

Proposal: Add variants of tails & inits not returning empty lists
by Maxime Henrion 31 Jan '08

31 Jan '08

Hi all, I just opened a Trac ticket (#1979), to suggest the addition of the inits1 and tails1 functions, which don't return empty lists unlike their counterpart. They're defined as such : inits1 = tail . inits tails1 = init . tails I've needed them a few times so I thought they would make a nice addition to the base package. And, I've got to say, the symmetry in this code is is nice :-). http://hackage.haskell.org/trac/ghc/ticket/1979 Cheers, Maxime

7 10

filepath
by Ian Lynagh 27 Jan '08

27 Jan '08

Hi Neil, I'm having some problems using filepath in GHC. I think some of these we might have discussed before, but if so I've forgotten what the conclusion was, if any, and I can't see the answers in the docs. The first is this: Prelude System.FilePath> "." </> "foo" "./foo" which means we get things like [2 of 2] Compiling GHC.Foo ( ./GHC/Foo.hs, ./GHC/Foo.o ) rather than [2 of 2] Compiling GHC.Foo ( GHC/Foo.hs, GHC/Foo.o ) Is there a reason the result shouldn't be "foo"? Possibly relatedly, the current directory seems to be "" rather than ".". This turns up in at least a couple of areas: Prelude System.FilePath> normalise "." "" Prelude System.FilePath> splitFileName "foo" ("","foo") I expected "." and "./" respectively, rather than the ""s. This causes problems when giving arguments to library functions or programs, which generally want "." or "./" rather than "", and if you are displaying a directory to the user then you again probably don't want to print "". As an example, I had a problem where GHC was running "gcc -I foo" rather than "gcc -I. foo". This looks like a straightforward bug to me: Prelude System.FilePath> normalise "./" "/" I'm not convinced by Prelude System.FilePath> isValid "" True I don't think I could "create a file like it". Finally, could splitSearchPath please take an extra argument, a list of FilePaths, to be appended to the result if it ends with a : or ; (as appropriate)? Thanks Ian

13 34

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

15 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

Announcement: Typeful [x]html combinators -- pre-release 0
by Jon Fairbairn 10 Jan '08

10 Jan '08

... or, "whoops! I've writtten another html combinator library." History: I was surprised to find that all the Haskell html generating stuff I've tried allowed one to construct invalid HTML. I thought to myself that this might make an undergraduate project, but then I thought "maybe it's too hard? I'd better write some of it to see how hard it is." After a while I decided that it was probably a bit too big for an undergraduate project, but by that time I'd written too much of it to throw away, and just had to keep going so here it is. I'm announcing it here because I hope the audience is fairly small but discerning, and I'm announcing it at all because I've run out of steam for the moment. This is the first code above the size of a nonce-programme that I've written since I got ill years ago, so don't go too hard on me! I still am ill, so don't expect swift responses either. I'm mainly interested in opinions on the questions below, and in test cases that fail validation. You can get it with darcs get --partial http://homepage.ntlworld.com/jon.fairbairn/Typeful/Text/HTMLs and the documentation (such as it is) is at <http://homepage.ntlworld.com/jon.fairbairn/Typeful/Text/HTMLs/Documentation…> Here's the announcement (which might better be called the release note, except that I'm not sure this counts as a relase). ------ Typeful HTMLs library Library of types and combinators to produce valid xhtml 1.0 (and eventually html 4.01) -- if you use this library (and if it's not faulty), you won't need to run the validator over the output of your code. Types prevent invalid nesting of elements (including the prohibitions of appendix B of the xhtml standard) and ensure an attribute is only passed to elements that has it. Most attributes are given types that reflect their content rather than just being strings (although some are just wrappers around strings for the moment). Includes full set of xhtml character entity names Includes type with names for all IANA-registered character sets. Provides the option of generating output in a choice of character sets (currently with the wide choice of utf_8, us_ascii, latin1 or iso_8859_5 (cyrillic)). Provides the option of generating xhtml without an xml version declaration (to avoid putting IE into quirks mode). It's generated by TemplateHaskell, but otherwise Haskell98. Questions: * I want to add a function to produce HTML 4.01. Unfortunately there are trivial differences (body takes a nonempty list in HTML but an ordinary list in xhtml, and similar). One approach (and the one I'd choose if left to my own devices) would be to restrict the document tree to the common subset, so the types would be constrained by whichever language was the more restrictive in any given case. An alternative would be to transform the xhtml tree by adding empty div elements. Which do people prefer? * Having a monad inside the result types of the *_allowed_in classes complicates the types, complicates programmatic generation of elements and makes some error messages much worse. It wouldn't be necessary if we simply wrote Haskell lists instead of using the +++ operator, ie instead of body << (h1 << ... +++ p << ... +++ p << ...) we had to write body << [h1 << ..., p << ..., p << ...] Admittedly, it is rather more awkward for nonempty lists: ul << (li <<... +++ li<< ... +++ li<<...) would have to be written ul << (li<<... +:[li<<...,li<<...]). Would anyone really be bothered by that? (Either that, or can someone come up with a way of rearranging the types so that +++ works without the monad in the result types of elements?) * What should I do about REQUIRED attributes? Some alternatives are listed in the TODO file. * The preference carrying monad used for Render is backwards; I tried making it go forwards, but the Laziness test programme took about 1.7 times as long to run. I'd like to put some state in there, which can't be done backwards. Can I do this somehow without the performance hit? * This pre release has a very restrictive license (barely falling short of "You may not use this!") My preference is, I think, to release it under LGPL. Is that going to cause people undue grief? -- Jón Fairbairn Jon.Fairbairn(a)cl.cam.ac.uk

5 14

Add 'subsequences' and 'permutations' to Data.List (ticket #1990)
by Twan van Laarhoven 10 Jan '08

10 Jan '08

Hello all, As Thomas Hartman noted in a recent cafe thread [1], haskell 1.3 included the functions 'subsequences' and 'permutations'. I think these functions are quite useful, and I don't know why they were ever removed. This is a proposal to add these two functions to Data.List. The implementation is taken directly from the Haskell 1.3 report [2]. Trac ticket: #1990 Discussion period ends: January 7th (since there is a holiday comming up) Twan [1] http://article.gmane.org/gmane.comp.lang.haskell.cafe/33535 [2] http://haskell.cs.yale.edu/haskell-report/List.html

8 21

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