- Libraries - Haskell.org

patch: Network.URI relativeFrom documentation
by Greg Heartsfield 18 Jan '09

18 Jan '09

I tried sending this before, but it appears to have not gotten through. Attached is a small patch for the Network.URI relativeFrom docs, which I believe has an error in its example. Thanks, Greg Heartsfield

1 0

Re: Improved documentation for Bool (Was: [Haskell-cafe] Comments from OCaml Hacker Brian Hurt)
by Benja Fallenstein 18 Jan '09

18 Jan '09

On Sun, Jan 18, 2009 at 5:48 PM, <roconnor(a)theorem.ca> wrote: > I noticed the Bool datatype isn't well documented. Since Bool is not a > common English word, I figured it could use some haddock to help clarify it > for newcomers. > > -- |The Bool datatype is named after George Boole (1815-1864). > -- The Bool type is the coproduct of the terminal object with itself. Russell, this does seem like it might be very helpful, but it might be useful to include a note about what category you are working in. People may sometimes naively assume that one is working in the category of Haskell/Hugs/GHC data types and Haskell functions, in which there are no terminal -- or initial -- objects ('undefined' and 'const undefined' are distinct maps between any two objects X and Y), or else in the similar category without lifted bottoms, in which the empty type is terminal and the unit type isn't ('undefined' and 'const ()' are both maps from any object X to the unit type). These niceties will not confuse the advanced reader, but it may help the beginner if you are more explicit. - Benja P.S. :-)

1 0

Re: ANN: leapseconds-announced-2009
by Ashley Yakeley 18 Jan '09

18 Jan '09

Bjorn Buckwalter wrote: > leapseconds-announced is a pragmatic, if imperfect, improvement over > my past practices. It provides a LeapSecondTable with all leap seconds > announced to date (hence the name). Once the IERS announces[3] another > leap second the package will need an update and all code using it a > recompile. While this precludes its use in long-running production > applications it is eminently adequate for my one-off uses or for > applications that can afford to recompile infrequently. You should consider using the tz database, which provides a leap-seconds table in the "right/UTC" timezone (and much other useful information). -- Ashley Yakeley

2 3

extralibs and the haskell-platform
by Ian Lynagh 17 Jan '09

17 Jan '09

Hi all, As the plan is for the extralibs to become part of the Haskell Platform, I think we ought to have a BTS for them. I therefore propose that we create a project on community.haskell.org for each of those that are maintained by libraries(a)haskell.org. For now that will only provide a BTS (trac), but once the GHC VCS switch has happened it would make sense to move the authoritative darcs repos to community too. The packages in question are: haskell-src html HUnit mtl network parallel stm (I've left QuickCheck off as I think that it has real maintainers again) Also, I've created a haskell-platform mailing list: http://projects.haskell.org/cgi-bin/mailman/listinfo/haskell-platform Currently it gets mail for any changes to the haskell-platform trac, but I think that it makes sense to send mail for all the HP package tracs there too, so you don't need to subscribe to dozens of low-traffic lists to keep on top of what's going on. If the volume becomes too high then we can move the noisier packages to their own list. For now at least, discussion should stay on libraries(a)haskell.org. Any comments/objections? Thanks Ian

2 2

An Alternative Data.List.Zipper
by Jeff Wheeler 17 Jan '09

17 Jan '09

Hi, I'm somewhat of a beginner in Haskell, so take what I say with a grain of salt, please. The ListZipper implementation seems very odd to me, and #haskell seemed to agree with me. The current package implements a Zipper with > data Zipper = Zipper ![a] ![a] which allows for empty zippers, among other things. Very strange to me. It also seems unnecessarily strict. There are also no expected typeclasses implemented, like Foldable or Traversable. I thought it would be interesting to try fixing these problems with a much cleaner design, and I'd like to share what I came up with: http://hpaste.org/14006 I'd very much appreciate some criticism of the code so that I can improve it. I'm not sure how best to provide this alternative on Hackage; should we make this merely a newer version of the old library, provide it in a conflicting package, or find a new namespace for it and provide it there? Thanks, Jeff Wheeler

2 1

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