August 2008 - Libraries

proposal #2517: remove 'pure' method from Arrow class
by Ross Paterson 16 Aug '08

16 Aug '08

The Arrow class as originally defined by John Hughes had methods arr, >>> and first. (>>> has since been moved by #1773 to the Category class.) When writing the "Fun of Programming" paper, I added pure as a synonym for arr, because Richard Bird preferred it. However this name hasn't caught on, and now it clashes with a method in the Applicative class, so I propose to remove it. The usual practice would be to deprecate the name in one release and remove it in the following one, but I propose to remove it in one step because * no-one seems to be using this name, and * backward compatibility has been broken anyway by the Category split (#1773). The only people who will be bitten by the change are those who import Control.Arrow hiding pure, and they wouldn't be warned by deprecation.

4 5

RE: [nightly] 10-Aug-2008 build of HEAD on i386-unknown-linux (cam-02-unx.europe.corp.microsoft.com)
by Simon Peyton-Jones 15 Aug '08

15 Aug '08

| -fgenerics -Wall -fno-warn-deprecated-flags -c Data/Time/Calendar/Gregorian.hs -o | dist/build/Data/Time/Calendar/Gregorian.o -ohi dist/build/Data/Time/Calendar/Gregorian.hi | | Data/Time/Calendar/Gregorian.hs:73:9: | Warning: orphan instance: instance Show Day | | <no location info>: | Failing due to -Werror. | | gmake[2]: *** [dist/build/Data/Time/Calendar/Gregorian.o] Error 1 | gmake[2]: Leaving directory `/playpen/simonmar/nightly/HEAD/i386-unknown-linux/libraries/time' | gmake[1]: *** [make.library.time] Error 2 | gmake[1]: Leaving directory `/playpen/simonmar/nightly/HEAD/i386-unknown-linux/libraries' | gmake: *** [stage1] Error 2 Now that orphan warnings are "proper warnings" as Duncan requested, and hence do the right thing with -Werror, someone should either remove this orphan (best), by moving the instance to the module that defines Day, or add -fno-warn-orphans to this module. Who is responsible for the time/ library? There may be other libraries similarly affected. Simon

15 33

ANN: Initial release of Language.C (language-c-0.3)
by Benedikt Huber 14 Aug '08

14 Aug '08

Hi all, I'm pleased to announce the first release of Language.C, a library for analysing and generating C code. This release features * A reasonably well tested parser handling and recording all of C99 and most GNU extensions, most notably gcc's attribute syntax. * A pretty printer generating source code from the AST, covering the same language subset as the parser. * A preview of the analysis framework, including functionality for dissecting C's cruel type and variable declarations. Places: * The project's homepage is located at http://www.sivity.net/projects/language.c (Getting Started, Bug Tracker) * The package is available via hackage (language-c-0.3) * darcs repo: http://code.haskell.org/language-c * API docs: http://code.haskell.org/~bhuber/docs/language-c-latest/ The library originated from the C-related code in c2hs (http://www.cse.unsw.edu.au/~chak/haskell/c2hs/ ), and is the topic of my SoC project, mentored by Iavor Diatchki. (Iavor, Don Steward and Duncan Coutts provided great support, thank you) Feedback and suggestions in any form are most welcome, especially because there is a large range of features which could be implemented. The current status and a few ideas for the next releases are summarized at http://www.sivity.net/projects/language.c/wiki/ ProjectPlan. best regards, benedikt

2 2

ANN: protocol-buffers (very early edition) version 0.0.5
by Chris Kuklewicz 14 Aug '08

14 Aug '08

Hi all, The Haskell version of protocol-buffer is still pre-bootstrap, but further, so there is a 0.0.5 release on http://hackage.haskell.org/cgi-bin/hackage-scripts/package/protocol-buffers and a darcs repository on http://darcs.haskell.org/packages/protocol-buffers/ The leading 0.0 in the type should show how early this code is :) What are protocol buffers? The are google's data interchange format: http://code.google.com/apis/protocolbuffers/docs/overview.html > What are protocol buffers? > > Protocol buffers are a flexible, efficient, automated mechanism for > serializing structured data – think XML, but smaller, faster, and simpler. You > define how you want your data to be structured once, then you can use special > generated source code to easily write and read your structured data to and from > a variety of data streams and using a variety of languages. You can even update > your data structure without breaking deployed programs that are compiled against > the "old" format. In addition to a manual translation of the self describing 'decriptor.proto' it has a partial code generator in Gen.hs and a stub of a parser in ProtoParser.hs and an intermediate data type in WireMessage.hs that I expect to sit between the byte stream reader/writer and the message types. Eventually the parser with read 'decriptor.proto' and the generator will emit source code to replace the manual translation. FAQ 1: Why is the Text.DescriptorProtos.* hierarchy so huge and the imports so plentiful? ANSWER 1: The namespace management. The namespace paradigm is the nested OO style namespace of C++, so I need modules and imports to fake nested Haskell namespaces. Cheers, Chris Kuklewicz

1 1

PROPOSAL: More base package breakup
by Ian Lynagh 13 Aug '08

13 Aug '08

Hi all, This is trac #1338: http://hackage.haskell.org/trac/ghc/ticket/1338#comment:14 http://hackage.haskell.org/trac/ghc/attachment/ticket/1338/packagegraph.png Initial deadline: 21 Aug (2 weeks). The base package is still a large, unwieldy beast, making it hard to develop and debug. If possible, I'd like to cut it down a bit more before the 6.10 release. I won't inline all the details here, as it's a huge amount of text and an image, but basically I'm proposing to: * Create packages: timeout, unique, concurrent, st, system, numeric, generics, version, getopt, debug, printf ghc-exts * Merge what I've listed as "control" into "containers" There's definitely a "foreign" package fighting to get out too, but that needs more work before we can set it free. An important point to note is that Simon Marlow has made a base 3 compatibility library that will come with GHC 6.10, and will provide the same interface as the base library that came with 6.8, so breaking backwards compatibility in base 4 shouldn't cause large problems like the base 2 to base 3 change did. Thanks Ian

4 4

Re: [nightly] 10-Aug-2008 build of HEAD oni386-unknown-linux(cam-02-unx.europe.corp.microsoft.com)
by Claus Reinke 11 Aug '08

11 Aug '08

>> 1. whatever I check in, the _whole_ thing has to build ok >> 2. if _my_ changes break someone else's code, _I_ have to fix that >> >> I'd suggest to interpret GHC+corelibs as a unit, and to apply rules >> 1 and 2. I was thinking of a unit of concern, not of any ownership or packaging (even the name "core"libs is ghc-specific: libraries ghc builds depends on). > But I do wish to point out that you cannot achieve both goals: "make > GHC and its dependencies into a single unit" and "share the libraries > with other compilers". At least, not without accepting some extra > work on the GHC side to maintain both illusions. Usually, the first time I hear about breakage affecting nhc98 or hugs is when you or Ross submit patches fixing said breakage!-) I think you are right: if the libraries are considered to be shared, then there are several such "units" which might affect each other via those shared libraries. Perhaps it helps to spell out the dependencies. In terms of changes in one place potentially having unwanted effects elsewhere, we have ghc <-> corelibs, ghc -> extralibs hugs -> corelibs+extralibs, ??hugslibs -> hugs nhc98 -> corelibs+extralibs, ??nhclibs -> nhc98 Actually, there are several forms of dependency: - changing the libraries cannot break hugs itself, but can make it unable to load or use any libraries, including the shared ones - changing (ghc-)corelibs can break ghc - changing nhc98-corelibs (which are?) can break nhc98 - changing hugs/nhc98/ghc can render each unable to load use some of the shared libraries (and others depending on these) Does that cover all cases? Changing ghc to make a library uncompilable by ghc only hurts ghc itself, but if the fix involves changing the library, the breakage might spread to hugs and nhc98. In principle, any changes to the shared libraries ought to be tested against all implementations sharing them. But as long as hugs and nhc98 are not part of a shared buildbot or validate system (neither of which are quite perfect even limited to ghc), breakage won't even be flagged for, let alone be fixed by submitters. While it is great that the two of you are always on the ball, is that something to be expected from all library maintainers all the time? Do all of them have to be subscribed to all of cvs-ghc, cvs-hugs, cvs-nhc98, and cvs-libraries, and fix any and all breakage arising in any and all situations, without their doing? Making it the submitters responsibility to look out for and fix any breakage caused by their patches simplifies the system and helps to ensure that any breakage resulting from changes is actually fixable (also in libraries outside the core+extralibs responsibility). In the time example, if ghc changes a warning flag to break the build, the immediate "fix" is to disable that new functionality, leaving it to the library maintainers to think about what the "proper" fix might be, possibly changing their code and re-enabling or leaving things as they are. Since those policies worked well in all projects where I have seen them used, I never really questioned them after I got my introduction. Is there a reason why they shouldn't or couldn't apply to the shared libraries and sharing haskell implementations? As I have mentioned, I'm worried that the move from extralibs to haskell platform will severe that responsibility, so library maintainers will have to become much more watchful for breakage affecting their packages, and more active in fixing such breakage. Claus

1 1

cabal-install
by Johannes Waldmann 11 Aug '08

11 Aug '08

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 "cabal install foo" seems a nice (in fact, indispensible) idea, but I don't see how to do the following with *one* command, for package "foo" and all its dependencies: * download and build as user, but install as root * also build and install haddockumentation for each of the packages Best regards, J.W. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4-svn0 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIoChEDqiTJ5Q4dm8RAlM3AJwPSNROTgsheAZksP3I9WrRVD/xBwCgiI0S Tpmo/YRT4J3kEq9HjkTOzqY= =YWYl -----END PGP SIGNATURE-----

2 1

Library submission process for tweaks / bugfixes
by Scott Dillard 07 Aug '08

07 Aug '08

Hi, The library submission process wiki page says to create a ticket and post it to the list when proposing interface changes, but what is the proper method for submitting bug fixes and tweaks? This post is both an inquiry into the library patching process, and a friendly reminder of some outstanding submissions of mine. I'm watching http://darcs.haskell.org/packages/containers and I don't see anything related to the following : 1) There is an egregious and program-breaking typo, already patched and languishing on trac : http://hackage.haskell.org/trac/ghc/ticket/2359 . IMO that needs to be pushed right now. (milestone 6.10? Whats the point of a separate containers repo?) 2) Months ago I submitted a small patch to fix a too-restrictive type signature : http://www.haskell.org/pipermail/libraries/2008-May/009677.html 3) and another to improve performance of findMin / findMax : http://www.haskell.org/pipermail/libraries/2008-May/009687.html 4) and another, with the help of Bertram F, to improve the runtime complexity of fromAscList for IntSet and IntMap : http://www.haskell.org/pipermail/libraries/2008-May/009685.html I was hoping for some kind of binary response, "ok, pushed" or "no thanks." I have more of these kinds of changes that I plan on making. Whom do I email? Should I use all caps or what? :) Clearly its not sufficient to say "propose interface changes on trac, post bugfixes to the list" because either no one with push power is reading the list, or they get their "to do" items from trac only. Which is something of a problem, because a mailing list can't generate "to do" items. On trac someone with access rights flags a ticket, but nothing like that happens on the list. And even if the proper place for submissions is trac, there is no "libraries/containers" component listed, and many library submissions are flagged "Not GHC" which sounds to me like a dismissal. Is containers still "GHC"? As I understand it, containers is a free-standing project and this list is its collective maintainer. (Which I don't really see as a solution.) Scott

2 1

Functor instance of ReaderT
by Henning Thielemann 07 Aug '08

07 Aug '08

The Functor instance of ReaderT has the header: Monad m => Functor (ReaderT r m) I thought (Functor m) must be the appropriate constraint.

2 2

Where should cabal install to by default?
by Duncan Coutts 06 Aug '08

06 Aug '08

Hi folks, cabal-install is supposed to make things simpler for users, especially new users. It's partly successful at that currently. Many users do not know ghc-pkg even exists for example (not that it was a design goal but it seems to be a consequence). On the other hand we're currently failing users by not making programs they install work by default. Currently cabal-install installs all binaries to ~/.cabal/bin by default. It does per-user installs by default and uses ~/.cabal as its prefix. Obviously ~/.cabal/bin is not on the $PATH, so users who install say, yi or whatever find that typing yi at the prompt does not do anything even though they just installed it. That's a failure on our part. It should work, and if we cannot make it work by default then we need to tell users what they need to do to make it work. So I'd like to discuss what defaults we should use. For reference, these are the features that are implemented right now that we have to play with: * We can do per-user or global installs (affects which package db we use but it also changes the default prefix) * We can set any --prefix we like * We can use versioned binaries (ie adding -$version suffixes) * We can add symlinks to binaries in some other directory * We can use a commend like sudo to do the install phase We can control all these features in the ~/.cabal/config file. When cabal-install is first run it creates a default ~/.cabal/config file. So the question is what default it should set and how we report failure cases to the user. We do not have to use the same defaults on every platform. If we can get away with it I think it's much nicer not to make it interactive. Here's a couple suggestions: For unix systems, do per-user installs to --prefix=~/.cabal but if ~/bin exists then add symlinks there. Or perhaps if ~/bin is not a convention on that unix platform (eg OSX) then do global installs by default to /usr/local and use sudo for the install phase (we know that OS X comes with sudo where as it may or may not on other unix systems). Duncan

8 12