- Libraries - Haskell.org

registering packages in ghc using a directory of package files
by Duncan Coutts 13 Mar '06

13 Mar '06

All, Yet again I've got annoyed by the difficulties with the way ghc registers packages. It's hard to get right. This time I had someone testing hdbc-odbc for me on ppc64. He uninstalled ghc and reinstalled it (to pick up a fix I had made) then he found that building hdbc-odbc failed because the hdbc package was not registered. However portage (the Gentoo package management facility) knew that it was installed. Of course what happened is that when ghc was reinstalled all the ghc packages that were already installed were not re-registered. Actually that is my fault because our ghc ebuild is supposed to do this. (Technically to do this correctly we should re-register the packages in dependency order, but we don't and just use --force) The point is that there are several bits that the packaging system has to get right for this to all work. The majority of the code in our ghc-package.eclass is for dealing with this issue. If we could just have ghc use a directory of package files rather than registering via modifying one central file then this would all become much simpler and more robust. One concern is that it would remove a point where the package database can be checked for consistency. I don't think this is necessarily so. The place that this QA check is really important is when users are manually installing packages. If an package management system finds a QA problem at registration time then it's already an unrecoverable bug. So the ghc-pkg could continue to be used in the way it is now, it will do it's carious checks and then install a file into a global package.conf.d directory rather than modifying a global package.conf file. For distro packaging systems we could use "ghc-pkg --check" or something, and then the package system would take responsibility for actually installing the file (and removing it when the package is uninstalled/upgraded). I'm somewhat tempted to patch our current ghc to do this, it might be easier to get that working than to get our current hacks to work properly. Duncan

3 5

Re: New collections package ready (almost)
by Simon Marlow 13 Mar '06

13 Mar '06

Jean-Philippe Bernardy wrote: > I've set up the new collections package, and it compiles under ghc and > hugs. I don't know about nhc, because I've been unable to compile nhc. > (I've got a x86_64 system; I've tryied to compile under a chroot does > not work, and configure program baffles me.) The non-ghc version is > portable though, so it _should_ work under nhc alright. > > So, you can try to make "collections" a default package, so I can > start moving stuff out of "base" into it. Ok, I misunderstood what you were doing here. I thought you were simply packaging AVL trees, but you're actually including the generic collections framework. I'm not completely comfortable with shipping this framework with GHC at the moment, given the small amount of discussion it has received, and the volume of competition in this space. This isn't a criticism of the design at all (indeed, I haven't looked at it in detail). I'd much prefer to see this provided as a separate package for now. Of course if a concensus emerges that this collections framework is the right way to go, then we'll certainly include it - a collections framework is pretty basic functionality. Cheers, Simon

4 3

darcs patch: add Data.Set.notMember and Data.Map.notMember
by John Meacham 13 Mar '06

13 Mar '06

Thu Mar 9 11:18:06 PST 2006 John Meacham <john(a)repetae.net> * add Data.Set.notMember and Data.Map.notMember

10 13

Re: New collections package ready (almost)
by Jean-Philippe Bernardy 12 Mar '06

12 Mar '06

I've checked again and it looks like, with the CVS version of hugs, modules that are transitively used must be exposed. Did I miss some option in the cabal file? Cheers, JP. On 3/12/06, Jean-Philippe Bernardy <jeanphilippe.bernardy(a)gmail.com> wrote: > Hello Einar, > > I did some tests with a (probably bugged) version of cabal which > required the modules to be exposed, and this is a left-over. > > Thanks for the feedback :) > > Cheers, > JP. > > On 3/12/06, Einar Karttunen <ekarttun(a)cs.helsinki.fi> wrote: > > On 12.03 16:03, Jean-Philippe Bernardy wrote: > > > I've set up the new collections package, and it compiles under ghc and > > > hugs. I don't know about nhc, because I've been unable to compile nhc. > > > (I've got a x86_64 system; I've tryied to compile under a chroot does > > > not work, and configure program baffles me.) The non-ghc version is > > > portable though, so it _should_ work under nhc alright. > > > > Looked at the package briefly and it seems promising. Why are > > Data.Tree.AVL.Internals.* in exposed-modules and not hidden ones? > > Should the Data.Tree.AVL.Test.* be added at all to the library > > or just remain there for a Makefile test target? > > > > - Einar Karttunen > > >

1 0

Re: [Haskell-cafe] STUArray
by Frederik Eaton 12 Mar '06

12 Mar '06

On Sun, Mar 12, 2006 at 09:05:58AM +0300, Bulat Ziganshin wrote: > Hello Frederik, > > Sunday, March 12, 2006, 5:58:42 AM, you wrote: > > FE> Perhaps some sort of warning in the documentation for STUArray is in > FE> order, until Bulat's code can be incorporated? > > excellent idea. you can make diff for Data.Array.ST/IO and send it to the > libs maillist $ diff -u libraries/base/Data/Array/IO.hs{.old,} --- libraries/base/Data/Array/IO.hs.old 2006-03-12 07:29:28.000000000 +0000 +++ libraries/base/Data/Array/IO.hs 2006-03-12 07:24:27.000000000 +0000 @@ -11,6 +11,8 @@ -- -- Mutable boxed and unboxed arrays in the IO monad. -- +-- XXX I'm not sure what to put here. +-- ----------------------------------------------------------------------------- module Data.Array.IO ( [1]$ diff -u libraries/base/Data/Array/ST.hs{.old,} --- libraries/base/Data/Array/ST.hs.old 2006-03-12 07:29:58.000000000 +0000 +++ libraries/base/Data/Array/ST.hs 2006-03-12 07:39:41.000000000 +0000 @@ -10,6 +10,15 @@ -- -- Mutable boxed and unboxed arrays in the 'Control.Monad.ST.ST' monad. -- +-- Beware that it is currently not easy to use STArray +-- polymorphically, since conditioning on "forall s . MArray (STUArray +-- s) e (ST s)" is impossible. Hopefully this should be fixed soon +-- (with an Unboxed class, Bulat Ziganshin is working on it). +-- +-- See http://www.mail-archive.com/haskell%40haskell.org/msg17085.html +-- +-- Use IOArray if you want your element types to be polymorphic. +-- ----------------------------------------------------------------------------- module Data.Array.ST (

1 0

darcs patch: add Data.Set.notMember and Data.Map.notMember / generalized infix notation use case
by Jean-Philippe Bernardy 11 Mar '06

11 Mar '06

Patch applied. Still, In time, I suppose the somewhat ugly not (element `member` set) sould be addressed by a mixture of generalized infix notation and the definition of such an operator: f /. g = \x y -> f (g x y) allowing element `not/.member` set Cheers, JP. On 3/11/06, Cale Gibbard <cgibbard(a)gmail.com> wrote: > > I don't like notElem either > > > > > * quite useful for cleaning up guards: > > > > > > f x | not (x `Set.member` map) && foo = ... > > > is hard to read. > > > > You may swap quards (or the "then" and "else" branches of "if"), or > > avoid the infix notation (which is horrible in this case anyway). > > > Although I'd normally agree with negated versions of things being > somewhat redundant, the infix version here is rather important, since > one often wants the code to look the same way as the mathematics. The > symbols \in and \not\in are both usually written infix, and that's not > going to change soon. Putting the membership operation in between is > nice, because we read the guard here as "If x is a member of xs > then..." rather than "If member x xs then..." anyway. Perhaps if the > proposal to allow somewhat more general expressions as infix operators > goes through (which I'm actually ambivalent about), I'd feel different > about this case. > > If you want to reduce redundancy, let's unify the 3 separate ways to > say 'map'. :) > > - Cale > _______________________________________________ > Libraries mailing list > Libraries(a)haskell.org > http://www.haskell.org/mailman/listinfo/libraries >

1 0

Trie implementation
by Keith Wansbrough 10 Mar '06

10 Mar '06

Hi... I was writing some code yesterday to walk over a directory tree, and needed a Trie. Not seeing one around, I wrote a basic implementation of the functions I needed (attached below). Has anyone else done this? Should I polish it up and offer it for inclusion in Data? --KW 8-)

7 8

Range queries and Data.Map
by Einar Karttunen 10 Mar '06

10 Mar '06

Hello Data.Map seems to lack a way to perform range queries like "fetch all elements between keys low and high". The naive implementation is easy: range :: Ord k => k -> k -> Map.Map k v -> [(k,v)] range low high = toList . fst . split high . snd . split low But this is not very fast for larger maps. Maybe this operation could be provided in Data.Map? - Einar Karttunen

2 1

Text.ParserCombinators.* is a bad name
by dons＠cse.unsw.edu.au 10 Mar '06

10 Mar '06

* Firstly, a library naming issue. Text.ParserCombinators feels like a clunkey name. This week I was working on a set of regex combinators, that ideally would go under: Text.Combinators.Regex but we're stuck with Text.ParserCombinators.Regex. Making me think that: Text.ParserCombinators.ReadP Text.ParserCombinators.Parsec Text.PrettyPrint.HughesPJ namespace should be deprecated in favour of: Text.Combinators.ReadP Text.Combinators.Parsec Text.Combinators.HughesPJ Reflecting the wide variety of text-manipulation combinators we use. The latter seem more elegant. Parsec in particular can lead to some noisy import statements in its current namespace. * Secondly, an FAQ on #haskell is "Where is fst3/snd3/thd3?" Lacking some fun generic system for hacking at tuples, perhaps fst3/snd3/thd3 should be put back into the base library under Data.Tuple, next to fst/snd? I note they were in (at least some versions of) Haskel 1.2, and they're even defined locally in GHC.PArr. I'll draft the patches if people think these are reasonable. Cheers, Don

12 18

unboxed arrays for nhc/jhc
by Bulat Ziganshin 09 Mar '06

09 Mar '06

Hello , i'm now working on alternative unxboxed arrays implementation, based on the Oleg Kiselyov idea this implementation is already compatible with Hugs and GHC, now i plan to make it NHC-compatible. i have the following question - is NHC implements 1) strict ST monad 2) unsafeIOtoST operation 3) Data.Array.* if nhc don't supports ST/unsafeIOtoST, then i plan to use the following ST monad emulation: type ST a = IO a unsafeIOtoST = id runST = unsafePerformIO also i plan to use this emulation layer for JHC. is this can work? -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com

3 6