January 2009 - Libraries

Cabal 2.0
by Duncan Coutts 17 Jan '09

17 Jan '09

All, I've started a wiki page to collect ideas for Cabal 2 http://hackage.haskell.org/trac/hackage/wiki/Cabal-2 The basic idea for Cabal 2 is to learn lessons from our how the existing design has fared and how we can make a better design to tackle an expanded set of goals. I'd like the page to be about suggested design concepts. I don't want to fill it with "wouldn't it be nice if we had a feature to help me doing ..." I guess it would also be useful to make links on that page to some of the discussions we've had on various lists, eg on the ghc users and libraries mailing lists where various people have made criticisms of the current design and suggested alternatives and improvements. Duncan

1 0

Recommendations for module hierarchy names for Python parser
by Bernie Pope 17 Jan '09

17 Jan '09

Hi all, I've written a parser for Python 3.0 using Happy and Alex and I want to make it available as a library. I'd like some feedback on choosing the right module hierarchy names. I guess it is fairly clear that it should go in: Language The following document already has space for Language.Python: http://www.haskell.org/~simonmar/lib-hierarchy.html The nub of my question is really what to do about version numbers of Python? Currently my parser only supports Python 3.0. In the near future I will also support an earlier version from the 2 series. In case you don't know Python, version 3.0 is the latest version, which was released late 2008. It is not backwards compatible with earlier versions. I think it would be difficult, and probably a bad idea to try to merge a parser for Python 3.0 with a parser for an earlier version. I don't think I should use: Language.Python, since it is not clear which version of Python it is. Would it be better to have: Language.Python30 -- for version 3.0 and say: Language.Python26 -- for version 2.6 Or would it be better to have something like: Language.Python.Version30 Language.Python.Version26 In general my strategy has been to follow the structure of Language.C, but they appear to only have one version. Cheers, Bernie.

6 6

Proposal #2960: Add instance Data.Traversable for Data.IntMap
by Matti Niemenmaa 16 Jan '09

16 Jan '09

Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/2960 Discussion period: 2 weeks This one should be a no-brainer. Data.Map has a Traversable instance, Data.IntMap doesn't. The proposal is to add one to Data.IntMap as well.

2 1

Fwd: glut bug
by Eyal Lotem 16 Jan '09

16 Jan '09

Forwarding a bug report about GLUT... Eyal ---------- Forwarded message ---------- From: Eyal Lotem <eyal.lotem(a)gmail.com> Date: Sun, Jan 11, 2009 at 4:01 PM Subject: glut bug To: Sven Panne <sven.panne(a)aedion.de> Hi Sven, GLUT's build has a configure script. When that script says: "libGLUT... yes/no" its not actually looking just for libGLUT, but for various other libs such as libXmu. Additionally, when it fails to find these other libraries, and gets a "no", it still finishes the configure and build "successfully", but without the proper -l flags in the package description. This results in linkage failures of GLUT programs later. In my opinion the fix should include: A. Look for libXmu and any other such library in a separate configure item, so its clear what's missing. B. Failure to find necessary libraries should fail the configure/build/install, and not continue as if successful, only to fail later. Eyal

1 0

Proposal #2875: Correct SYB's representation of Char
by José Pedro Magalhães 16 Jan '09

16 Jan '09

Hello all, SYB uses DataRep to represent datatypes: -- | Public representation of datatypes data DataRep = AlgRep [Constr] | IntRep | FloatRep | StringRep | NoRep I believe that StringRep should be CharRep. Note that IntRep is used for the primitive Int and Integer datatypes, FloatRep for Float and Double, and StringRep (apparently) for Char. String, however, is represented as AlgRep [[],(:)]: *Main> dataTypeOf 'p' DataType {tycon = "Prelude.Char", datarep = StringRep} *Main> dataTypeOf "p" DataType {tycon = "Prelude.[]", datarep = AlgRep [[],(:)]} This makes sense, since String is not a primitive datatype. But it causes the apparently wrong behavior: *Main> fromConstr (mkStringConstr (dataTypeOf "a") "ab") :: String "*** Exception: mkStringConstr *Main> fromConstr (mkStringConstr (dataTypeOf 'a') "ab") :: String "*** Exception: constrIndex The correct way of using mkStringConstr is to construct a Char. This, however, only works for strings with a single character: *Main> fromConstr (mkStringConstr (dataTypeOf 'a') "b") :: Char 'b' *Main> fromConstr (mkStringConstr (dataTypeOf 'a') "ab") :: Char *** Exception: gunfold *Main> fromConstr (mkStringConstr (dataTypeOf 'a') "") :: Char *** Exception: gunfold I find this behavior counterintuitive. Therefore I propose to rename StringRep to CharRep and mkStringConstr to mkCharConstr. For backwards compatibility, this entails: * Deprecating mkStringConstr and StringConstr * Deprecating mkStringRep and StringRep * Introducing mkCharConstr and CharConstr * Introducing mkCharRep and CharRep Additionally, due to deprecation warnings, the following have to change as well: * libraries/template-haskell/Language/Haskell/TH/Quote.hs * compiler/utils/Serialized.hs A patch is attached in #2875 ( http://hackage.haskell.org/trac/ghc/ticket/2875) I propose a discussion period of 4 weeks, therefore until the 8th of January. Thanks, Pedro

2 4

Add Applicative instances for MTL types
by Bas van Dijk 16 Jan '09

16 Jan '09

Hello, In a project of mine I needed an Applicative instance for Identity and noticed it didn't exist. So I decided to add Applicative (and Alternative instances where possible) for all MTL types. When I was about to submit a library proposal I saw there already existed one. So I added my patch to that ticket. My patch I different in that my Applicative instances don't require a Monad constraint. This also means that most Functor instances now also depend on Applicative rather than on Monad. See the ticket for the details: http://hackage.haskell.org/trac/ghc/ticket/2316 Discussion period: 5 weeks (taking the holidays into account) This is the old thread about this proposal: http://thread.gmane.org/gmane.comp.lang.haskell.libraries/9140/focus=9154 regards, Bas

5 9

Control.Monad.Writer.Strict .... enough?
by Ben Moseley 15 Jan '09

15 Jan '09

Hi, In most of the 'mtl' variants on Hackage (with the notable exception of 'monadLib'), the Control.Monad.Writer.Strict main instance is: newtype Writer w a = Writer { runWriter :: (a, w) } instance (Monoid w) => Monad (Writer w) where return a = Writer (a, mempty) m >>= k = Writer $ case runWriter m of (a, w) -> case runWriter (k a) of (b, w') -> (b, w `mappend` w') ...ie the `mappend` is hidden inside a lazy "(,)" constructor. ...shouldn't the bind really be strict in the written monoid? (eg by replacing "(a,w)" with "(a,!w)" and using Bang Patterns). ...if so, is it worth submitting patch? --Ben

1 0

Haskell platform related proposal: update regex to latest versions
by Chris Kuklewicz 14 Jan '09

14 Jan '09

I have added this to the trac wiki at http://trac.haskell.org/haskell-platform/wiki/Library/regex-base Chris Kuklewicz proposes: As the writer and maintainer of the regex-(base|posix|compat) packages I would like suggest the following. The Haskell platform should upgrade from the 0.72 version of regex-base to the 0.93.1 version. Similar updates to the latest releases of regex-posix and regex-compat would also be made. The old version has been kicking around too long, partly because I have not bothered to push updating the GHC bundle. The regex-base update adds makeRegexM and makeRegexOptsM which allow for saner error handling when compiling regular expressions, they use "fail" instead of "error". It would be possible to switch to !MonadError or perhaps the new exceptions, discussion of this is welcome. The older version of regex-base has lazy overlapping instances of !RegexContex which GHC allows and Hugs forbids, so the new version of regex-base has newtypes that force the user to be more explicit: {{{ newtype AllSubmatches f b = AllSubmatches {getAllSubmatches :: (f b)} newtype AllTextSubmatches f b = AllTextSubmatches {getAllTextSubmatches :: (f b)} newtype AllMatches f b = AllMatches {getAllMatches :: (f b)} newtype AllTextMatches f b = AllTextMatches {getAllTextMatches :: (f b) } }}} It would be possible to include most (or perhaps all) of the old instances, either as a sub-module or conditionally compiled, again discussion of this is welcome.

1 0

Policy question re: Haskell Platform installer on OSX
by Gregory Collins 14 Jan '09

14 Jan '09

Hi all, I'm currently writing a program to take Cabal libraries and turn them into OSX .pkg files, for the Haskell platform's Mac installer. Where should the libraries be installed? The current GHC installer plops them down into /Library/Frameworks/GHC.framework/Versions/xxx/usr, and my thinking is that I'll keep it that way so that we can piggyback on GHC's uninstall script. Otherwise the platform project will need an uninstaller of its own. Thanks, G. -- Gregory Collins <greg(a)gregorycollins.net>

4 6

ghc-6.10 and Exception vs OldException
by Alistair Bayley 13 Jan '09

13 Jan '09

I'm upgrading Takusen to compile with ghc-6.10, and I'm wondering what the recommended approach is for dealing with the new Exception module. What does one do if one wants to maintain a library that will build with ghc-6.10 and also older versions, as far back as 6.4, say? CPP hackery, or is there something more elegant? Alistair

2 1