March 2010 - Libraries

Re: Proposed ghc-pkg and cabal feature - right list?
by Axel Simon 14 Mar '10

14 Mar '10

Hi Dan, I reply to libraries, I think that's the right list for Cabal. On 13.03.2010, at 21:39, Dan Knapp wrote: > There doesn't seem to be a mailing list for Cabal itself, so I'm > posting here. I came up with an idea for a small feature that I > believe would make a useful addition to ghc-pkg and Cabal. I'm > willing to implement it myself, but I have had some previous > experiences with other projects where I did some work and then the > maintainers said "sorry, not interested", so I want to gauge interest > before I start. Who should I talk to? > > The feature itself is this: Arbitrary key-value pairs in Cabal > package files and the installed-package database. The use-case is for > an application supporting plugins to discover installed plugins > compatible with it, interrogating these fields through the GHC API. For Gtk2Hs I would like to have a similar feature. Gtk2Hs is a wrapper for Gtk+. It evolves on its own (for which the package has a version number) but it may wrap different versions of Gtk+. I think people using Gtk2Hs need to be able to conditionally compile certain code fragments, depending on which Gtk+ version Gtk2Hs wraps. However, I had something simpler in mind than providing any kind of key,value pairs: I would like to "export" certain Cabal flags into the package, which could be as easy as specifying: Flag gtk_2_2 Description: Build objects for Gtk+ version 2.2. Exported: True Flag gtk_2_4 Description: Build objects for Gtk+ version 2.4. Exported: True Flag gtk_2_6 Description: Build objects for Gtk+ version 2.6. Exported: True where the 'Exported' would mean that this flag should be added to the package data base. A package would then be gtk-0.10.4{gtk_2_2,gtk_2_4} if the first two flags would be set by Cabal. A package could then depend on gtk-0.10.4 in which certain flags are set. Moreover, I would then want cabal to compile a users package with -Dgtk_2_2 -Dgtk_2_4 so the user can use CPP to conditionally compile code. You suggestion of using arbitrary key,value pairs is more general and needs more thought. You would have to extend Cabal quite a bit whereas my proposal is more lightweight in that it can build on top of Cabal's Boolean flags. May I ask: - could you express your package properties using Boolean flags (which are set by Cabal automatically)? - if not, could you not express your plug-in concept using several packages? Cheers, Axel. > For example, my content-management system FruitTart could enumerate > the list of installed packages looking for packages which export a > field "fruit-tart-plugin-interface-version" with a numeric value > matching the interface version it's expecting. > > Once again, I'm not asking anyone to do this work for me - I'm eager > to get my hands dirty and do it myself. I just want to find out what > the process would be to get it accepted, once it works. > > Thanks in advance, > > -- > Dan Knapp > "An infallible method of conciliating a tiger is to allow oneself to > be devoured." (Konrad Adenauer) > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users(a)haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

1 0

Doc fixes in Control.Exception
by Bas van Dijk 14 Mar '10

14 Mar '10

Hello, I noticed some minor errors in the documentation of Control.Exception. The attached patch fixes them. It would be nice if somebody could apply the patch. regards, Bas

4 11

MonadWriter instance for ListT
by Nicolas Frisby 14 Mar '10

14 Mar '10

*> runWriter . runErrorT $ censor (filter (/=3)) $ tell [1,2,3] >> throwError "" (Left "",[1,2,3]) That's kind of weird, right? I understand why it is that way. I think this is reason enough to make censor part of the class, since it wouldn't have this short-coming if it weren't defined in terms of pass. *> let censorErrorT f (ErrorT m) = ErrorT (censor f m) *> runWriter . runErrorT $ censorErrorT (filter (/=3)) $ tell [1,2,3] >> throwError "" (Left "",[1,2]) Or is it preferable for censor and pass to misbehave in the same way?

2 1

Re: Please don't deprecate Haskell 98 modules.
by John Lato 12 Mar '10

12 Mar '10

> From: John Meacham <john(a)repetae.net> > > Please don't deprecate these modules. > Encouraging people to use bleeding edge APIs just contributes to the > already dicey problem of writing future and backwards compatible code in > Haskell, in fact, writing to haskell 98 is the _only_ option at the > moment with any ability to do so. I was originally in favor of deprecating haskell98 but didn't care enough to voice an opinion. John's argument has convinced me otherwise, so +1 to keeping haskell98. John

3 3

linking in cabal haddock (was: [Haskell] ANNOUNCE: barchart-0.1.1)
by Sebastian Fischer 09 Mar '10

09 Mar '10

[moving to libraries mailing list] Begin forwarded message: > From: Sebastian Fischer <sebf(a)informatik.uni-kiel.de> > Date: March 8, 2010 10:56:16 AM GMT+01:00 > To: Haskell <haskell(a)haskell.org> > Subject: Re: [Haskell] ANNOUNCE: barchart-0.1.1 > >> barchart is a command-line program with associated Haskell library After announcing the barchart package, I have some problems building its Haddock documentation. Firstly, > The API is not generated on Hackage because the diagrams library > cannot be built on GHC 6.12. Hence, I tried to generate it myself, but > Even with > > --html-location='http://hackage.haskell.org/packages/archive/$pkg/latest/doc/html' > > 'cabal haddock' does not generate links to the required packages. I noticed, that 'cabal haddock' does generate (external) Links to Hackage when I use the --html-location option after reinstalling all required packages *locally*. Why do I have to istall local documentation in order to get external links? Secondly, there are no Haddocks for the Diagrams library on Hackage and, hence, the links from the barchart docs to Diagrams's types are broken. I'd like to specify a custom link target for only the Diagrams package (the Diagrams website has Haddock documentation). Is this possible? Cheers, Sebastian -- Underestimating the novelty of the future is a time-honored tradition. (D.G.)

1 1

Improving containers library
by Milan Straka 09 Mar '10

09 Mar '10

Hi all, I have started an internship in Cambridge and will spend 3 months on Haskell. One of the possible projects is improving the containers library. Things I am thinking about: - measuring the performance of existing implementations (notably Map and Set) and possibly improve them (either without or with API changes), - adding Queue and a PriorityQueue, - maybe adding a generalized trie, - maybe adding a hashtable (more like a trie of the hashes, something in the line of Ideal hash trees; and maybe a 'classic' hash modifiable in the ST monad?) I would be grateful for any comments, thoughts or wishes. Milan Straka

10 18

Progress on priority queues for containers
by Louis Wasserman 09 Mar '10

09 Mar '10

A brief update: I'm continuing to work on a priority queue implementation for containers. I've pretty much settled on a variation on a binomial heap that actually has the type-checker guarantee the correct binomial structure. It has the following properties: - Amortized O(1) insertion. There are variations (skew binomial heaps) with guaranteed O(1) insertion, but they add tremendously to the complexity of the implementation, if they work at all with this approach (I've encountered some difficulties with this approach). I think this is fine, as-is. - Worst-case O(log n) union. (If you're working in a single-threaded fashion, I am pretty convinced that you can treat union as amortized O(0), but O(log n) is pretty good in any event.) - O(1) find-min. - Worst-case O(log n) extract. The primary competing implementation is a pairing heap implementation, with the following properties: - O(1) insertion, union, and find-min, worst-case and amortized. - Amortized O(log n) extract, but worst-case O(n). If used in a persistent context, it's possible that a user could encounter a situation that performs linear-time extraction operations many times. (This is my primary concern with this implementation, especially given that containers users will be expecting a reliable data structure that won't break down.) For a simple heap sort, the pairing heap is just about twice as fast as the binomial heap, but I think having reasonable worst-case guarantees for containers users is important enough to dominate that concern. There has also been some discussion of using priority search queues -- priority queues in which you can also find previously inserted elements -- but I think this is more appropriate for a separate package, and not something that is necessarily needed by most users. I've also written a wide variety of utility functions, which you can see in the implementation here<http://hackage.haskell.org/trac/ghc/attachment/ticket/3909/containers-pqueu…>. In particular, a number of Data.List functions are modified to apply to priority queues, including take, drop, splitAt, takeWhile, dropWhile, span, break, filter, and partition. All of these are implemented asymptotically optimally. Do people have any other thoughts? Louis Wasserman wasserman.louis(a)gmail.com http://profiles.google.com/wasserman.louis

2 1

Re: Bug in Parsec.Token
by Don Stewart 05 Mar '10

05 Mar '10

derek.a.elkins: > Who is going to maintain "Parsec 4"? > > I'm completely against this. If people absolutely must have exactly > Parsec 2's implementation we can simply copy it into Parsec 3, and the > "compatibility" layer, in that case, will simply -be- Parsec 2. I've > considered this as a temporary solution for the performance issues > just so people could move to Parsec 3 dependencies, but that should > not be necessary now, and even then I considered it a much less than > ideal solution. > > If the community wants to freeze on Parsec 2, then I have no problem > renaming the package, otherwise I think it is both unnecessary and a > waste of effort. > The problem is the ongoing lack of confidence in Parsec 3's performance. The new release goes some way to addressing this, but I think this has gone unaddressed for too long. Can someone address the lingering concern with benchmarks against parsec 2? -- Don

2 1

Proposed additions to Data.Map: lookupFloor and lookupCeiling
by Leon Smith 05 Mar '10

05 Mar '10

Hi, here are two quick, modest additions to Data.Map. As Map is exported abstractly, lookupFlor can't be defined outside the library except via splitLookup and findMax. On the other hand, these implementations should be nearly the same cost as a regular lookup. Best, Leon -- | /O(log n)/. Find the greatest key that is smaller or equal -- to the given target key. This \"floor\" key is returned, along with it's -- associated value, as @'Just' (key, value)@. If the map does not have -- a key that is smaller or equal to the target key, then this function -- returns 'Nothing'. lookupFloor :: Ord k => k -> Map k a -> Maybe (k,a) lookupFloor = go Tip where go s k t = case t of Tip -> case s of Tip -> Nothing Bin _ ka a _ _ -> Just (ka,a) Bin _ ka a l r -> case compare ka k of LT -> go t k r GT -> go s k l EQ -> Just (ka,a) -- | /O(log n)/. Find the smallest key that is greater or equal -- to the given target key. This \"ceiling\" key is returned, along with it's -- associated value, as @'Just' (key, value)@. If the map does not have -- a key that is greater or equal to the target key, then this function -- returns 'Nothing'. lookupCeiling :: Ord k => k -> Map k a -> Maybe (k,a) lookupCeiling = go Tip where go s k t = case t of Tip -> case s of Tip -> Nothing Bin _ ka a _ _ -> Just (ka,a) Bin _ ka a l r -> case compare ka k of LT -> go s k r GT -> go t k l EQ -> Just (ka,a)

6 9

Bug in Parsec.Token
by Greg Fitzgerald 05 Mar '10

05 Mar '10

In Text.Parsec.Token, the list of reserved names is not necessarily sorted for case-insensitive languages. When the list of reserved names contains a string with capital letters, the 'identifier' combinator can accept identifiers that conflict with reserved names. Attached are patches for Parsec 2.1 and 3.0. Please let me know if there's anything else I can do to ensure this patch makes it to the next release of the Haskell Platform. Thanks, Greg

6 11