May 2007 - Libraries - Haskell.org

problems using ghc-6.6.1 (due to fgl-5.4.1)
by Christian Maeder 09 May '07

09 May '07

I wrote: > Dear Hets- and GHC-Developers, > we have a problem using ghc-6.6.1. The created hets binary runs a > couple > of times slower than the one created using ghc-6.6. This problem is gone when I install and use fgl-5.3 (where "hiding (indices)" needs to be deleted in Data.Graph.Inductive.Monad.IOArray). I strongly suspect the new functions context1l' and context4l' in Data.Graph.Inductive.Graph (fgl-5.4.1) to be the reason for our drastic slow down. In fgl-5.3 the functions fst4 and fth4 have been used instead. A cyclic edge (an edge from and to the very same node) was only returned as ingoing edge and not as outgoing one. (a design decision documented elsewhere). I think, the change in fgl-5.4.1 now returns a cyclic edge also as outgoing edge (and possibly twice as ingoing one). Our application heavily uses in- and outgoing edges that may be cyclic. Christian P.S. ghc-6.6.1/libraries/fgl/Setup.hs does not compile with ghc-6.6.1

2 2

darcs patch: Make Gen an instance of Applicative
by Duncan Coutts 09 May '07

09 May '07

Thanks to Björn Bringert and Koen Claessen, the QuickCheck 2 darcs repository is now hosted at: darcs get http://darcs.haskell.org/QuickCheck/ 'darcs send' will send patches to the libraries mailing list. We figured this list is appropriate since QC is a tool that many people depend on so getting a wider range of reviewers is good and yet development activity isn't likely to be so high that a seperate mailing list would be needed. Here's one such patch: Tue May 8 17:32:04 BST 2007 Duncan Coutts <duncan.coutts(a)worc.ox.ac.uk> * Make Gen an instance of Applicative So we can use the nice syntax: f <$> a <*> b <*> c

2 2

Re: [Haskell] -compiler-options vs {#-LANGUAGE Flags-#}
by John Meacham 09 May '07

09 May '07

On Thu, Apr 05, 2007 at 07:07:34PM +0100, David House wrote: > On 05/04/07, John Meacham <john(a)repetae.net> wrote: > >A very big problem with the pragma as it relates to > >Distribution.Extension is that it is unextensable. > > Yet another use case for Andres Löh and Ralf Hinze's open datatypes > [1]. Shame they're still lacking an implementation. > > [1]: http://www.informatik.uni-bonn.de/~loeh/OpenDatatypes.html Well, The mistake is making them a data type at all, cabal doesn't do anything with them other than pass them to the appropriate compiler (perhaps after translating them to flags if the compiler doesn't support the LANGUAGE pragma). it should not have to enumerate a set of valid ones inside its code, just translation tables for the various compilers (or a note saying the compiler supports the LANGUAGE pragma, so the table isn't needed) likewise for the License field and getting rid of all built in preprocessors. cabal is just too inflexible (and much bigger than it needs to be) with so much stuff built in. ideally, the compilers would also not be hard coded into it, but that would be a bigger task but fixing up the rest shouldn't be hard. as a compiler writer, what I would love is if there were a document on the cabal site that said "to allow cabal to use your compiler, have it (or a wrapper) accept the following command line options and do X with them" likewise for a preprocessor or a language extension. none of these should require editing cabals code at all or require people to put something odd in their Setup.hs files to support the new compiler. perhaps what can be done for compiler support is to add a new 'common api' that newer compilers can use and a real --compiler option rather than the current --ghc --hugs hardcoded stuff. it should be just as easy as adding a specific hard-coded 'jhc' target and wouldn't feel so dirty. :) John -- John Meacham - ⑆repetae.net⑆john⑈

3 2

HackageDB: request for requests
by Ross Paterson 08 May '07

08 May '07

As you may know, Sascha Böhme will be doing a Google Summer of Code project on enhancing the (currently rather basic) web interface to HackageDB. There's a list of ideas at http://hackage.haskell.org/trac/hackage/wiki/HackageToDo Let's hear views on what's most important, what's missing, how it should be done, etc, but don't expect it all to get done this (northern-hemisphere) summer.

1 0

Test, please ignore
by Simon Marlow 08 May '07

08 May '07

I've had a report of difficulty posting to the list, so this is a test.

1 0

Why isn't Data.Map not an instance of Monoid :-)
by Adrian Hey 07 May '07

07 May '07

Hello Folks, Just been going through making sure the class instances for the AVL based Data.Map clone make sense, and I find this in Data.Map (and the clone). instance (Ord k) => Monoid (Map k v) where mempty = empty mappend = union mconcat = unions This worries me because there is no obviously correct choice for the semantics of union for maps (as in which maps associated values get dropped). I've always felt that it was bad practice to provide library functions which simply make an arbitrary but a significant choice on users behalf, knowing it's likely that this isn't going to be what 50% of users actually want. So I'd been giving serious consideration to deprecating union, thereby forcing users to specify the behaviour they actually want using unionWith. The only reason I didn't in the end is that it's easy enough for users to get what they want in this case using flip (provided they don't care about "biasing" for keys) But it's not so easy if functions like this are used as class methods. So my inclination was to drop the Monoid instance for Maps. But I see by doing this I break Jean-Philippes instance of the Map class (which has a Monoid constraint) in the new Collections API.. http://darcs.haskell.org/packages/collections-ghc6.6/Data/Collections.hs AFAICT Jean-Philippe class only uses mempty, so I had been considering.. instance Ord k => Monoid (Map k v) where mempty = empty mappend = error "Data.Map.AVL: undefined Monoid.mappend." mconcat = error "Data.Map.AVL: undefined Monoid.mconcat." However, fooling people into thinking it is a Monoid when it isn't all so seems bad. So what do you think about this? Keep it or drop it? Does anybody (other than Jean-Philippe :-) currently rely on Data.Map being a Monoid instance? Regards -- Adrian Hey

2 2

why is Data.Set not a Monad?
by Frederik Eaton 07 May '07

07 May '07

Hello, Anyone know why Data.Set is not a Monad? Or Data.Map? It seems Data.Map is a Functor, but not Data.Set... I am confused. Am I not importing the right modules? Thanks, Frederik

5 6

StringBuffer.lhs (compiler/utils/) - hGetStringBuffer ? should the 'h' be there?
by Marc Weber 04 May '07

04 May '07

hPutStrLn etc all denote that you have to pass a handle hGetStringBuffer has the type hGetStringBuffer :: FilePath -> IO StringBuffer so I think the h is superfluous here ? Marc

1 0

POSIX named semaphore and shared memory object bindings
by Daniel Franke 03 May '07

03 May '07

I've written some bindings for POSIX named semaphores and shared memory objects, which I'd like to submit for inclusion into the `unix' package. However, I can't seem to do so through the proper channels, as a couple things seem to be broken at the moment: 1. Account creation on http://hackage.haskell.org/trac isn't working: [Errno 13] Permission denied: '/srv/trac/ghc/trac.htpasswd' . 2. The HEAD version of `unix' depends on the HEAD version of `Cabal', which currently won't build: Distribution/Compat/TempFile.hs:6:7: Could not find module `IO': it is a member of package haskell98, which is hidden As soon as these things are resolved I'll submit a proper patch. For the time being, I've put the extensions into a separate package, attached. -- Daniel Franke df(a)dfranke.us http://www.dfranke.us |----| =|\ \\\\ || * | -|-\--------- Man is free at the instant he wants to be. -----| =| \ /// --Voltaire

2 2

Test, please ignore
by Simon Marlow 03 May '07

03 May '07

I've had a report of difficulty posting to the list, and we haven't had any posts in a couple of days, so this is a test.

1 0