February 2011 - Libraries

ANN: bytestring-trie 0.2.3
by wren ng thornton 12 Feb '11

12 Feb '11

-------------------------------------------- -- bytestring-trie 0.2.3 -------------------------------------------- A long-awaited release for efficient finite maps from (byte)strings to values. This version adds a number of new functions for taking advantage of the trie structure. At the Haskell Symposium 2010, Milan Straka presented a wonderful paper comparing the state of the @containers@ library pre-GHC7. In it he compared the new @hashmap@ against the buggy old @bytestring-trie@ 0.1.4 (the major bug was fixed in 0.2.2 released 2010-06-10), and I've been meaning to update the package ever since. I haven't had a chance to do an extensive performance analysis yet, but it's worth clearing up some misconceptions--- which is what this release is all about. If you are only interested in being able to associate strings to values, then you may prefer the @hashmap@ package which is faster for those only needing a map-like structure. This package is intended for those who need the extra capabilities that a trie-like structure can offer (e.g., structure sharing to reduce memory costs for highly redundant keys, taking the submap of all keys with a given prefix, contextual mapping, extracting the minimum and maximum keys, etc.) While hacking on another project I noticed that @bytestring-trie@ didn't actually export many functions taking advantage of the trie structure. So let's fix that! -------------------------------------------- -- Changes (available in 0.2.2, but not announced previously) -------------------------------------------- * Added some functions for treating tries like priority queues (minAssoc, maxAssoc, updateMinViewBy, updateMaxViewBy). Currently these are only exported by Data.Trie.Internal though future releases may re-export them from Data.Trie too. -------------------------------------------- -- Changes (since 0.2.2) -------------------------------------------- * Added Data.Trie.Internal.alterBy_: A variant of 'alterBy' which also allows modifying the sub-trie. This is useful for cases where you want to alter a number of values which are each prefixes of one another (e.g., "a", "ab", "abc",...). * Added a number of "contextual" mapping functions (contextualMap, contextualMap', contextualFilterMap, contextualMapBy) which give access to the sub-trie rooted at each value. Currently these are only exported by Data.Trie.Internal though future releases may re-export them from Data.Trie too. * Added strict variants of a number of functions in Data.Trie.Convenience (fromListWith', insertWith', insertWithKey', unionWith'). * Added some additional functions for building tries from association lists (fromListWith', fromListWithL, fromListWithL') as suggested by Ian Taylor. * Converted the definitions for fmap, foldMap, traverse, and filterMap to use the worker/wrapper transform. This appears to be an optimization, though I don't have a decent benchmarking suite for verifying this. * Lots of tweaks and improvements to the documentation. -------------------------------------------- -- Future work -------------------------------------------- * I'm still not leased with the situation of having so many different variants of fromList. There must be a nicer solution which generalizes over all of them and doesn't have the various pessimal corner cases... * The priority queue functions still need some work to make them general as well as comprehensive like the other functions in Data.Trie.Internal are. * I still need to do a thorough performance analysis. The code for Data.Trie was based very closely on the code for Data.IntMap. Milan Straka found a number of ways to optimize the Data.IntMap code, so I need to incorporate those into the Data.Trie code. -------------------------------------------- -- Links -------------------------------------------- Homepage: http://code.haskell.org/~wren/ Hackage: http://hackage.haskell.org/package/bytestring-trie Darcs: http://community.haskell.org/~wren/bytestring-trie/ Haddock (Darcs version): http://community.haskell.org/~wren/bytestring-trie/dist/doc/html/bytestring… -- Live well, ~wren

1 0

Data.Text for parsec3
by Kazu Yamamoto 09 Feb '11

09 Feb '11

Hello, I would like to add Data.Text support to parsec3. The following is a sample implementation. https://github.com/kazu-yamamoto/parsec3/commit/58c268c37e54a470c841c3ef5ec… If there is no problem, please merge it to parsec3. Regards, --Kazu

4 8

Proposal: Add chop function to Data.List
by Lennart Augustsson 08 Feb '11

08 Feb '11

I would like to propose the following function for inclusion in Data.List chop :: (a -> (b, [a]) -> [a] -> [b] chop _ [] = [] chop f as = b : chop f as' where (b, as') = f as It's commonly occuring recursion pattern. Typically chop is called with some function that will consume an initial prefix of the list and produce a value and the rest of the list. The function is clearly related to unfoldr, but I find it more convenient to use in a lot of cases. Some examples ------------- -- From Data.List group :: (Eq a) => [a] -> [[a]] group = chop (\ xs@(x:_) -> span (==x) xs) -- From Data.List words :: String -> [String] words = filter (not . null) . chop (span (not . isSpace) . dropWhile isSpace) -- From Data.List lines :: String -> [String] lines = chop ((id *** dropNL) . span (/= '\n')) where dropNL ('\n':s) = s; dropNL s = s -- From Data.List tails :: [a] -> [[a]] tails = (++ [[]]) . chop (\ xs@(_:xs') -> (xs, xs')) -- From Data.List map f = chop (\ (x:xs) -> (f x, xs)) -- Split a list into a list of list with length n. splitEveryN n = chop (splitAt n) -- Simple Haskell tokenizer tokenize = chop (head . lex) History ------- I first encountered this function around 1981 when I was talking to Sören Holmström about this recursion pattern and he said that he had also observed it and he called the function chopList. Ever since then I've used chopList a lot, but unfortunately I always have to make my own definition of this common function.

12 17

Proposal: Deprecate Control.Exception.blocked in favour of getMaskingState
by Bas van Dijk 08 Feb '11

08 Feb '11

Dear all, I would like to propose deprecating 'Control.Exception.blocked' in favour of 'getMaskingState'. The term "blocked" refers to the old way of dealing with asynchronous exceptions (block/unblock). It can also be a bit confusing to which "blocked" property it refers: blocked asynchronous exceptions, or a blocked thread. Note that 'blocked' is already listed in the section "(deprecated) Asynchronous exception control": http://hackage.haskell.org/packages/archive/base/4.3.0.0/doc/html/Control-E… We could add an equivalent function with an unambiguous and more consistent name: masked :: IO Bool masked = fmap (/= Unmasked) getMaskingState However, I don't think it will be used enough to warrant its addition. I believe the proposal is clear enough, so I will make a patch when consensus is reached. Discussion deadline: 2 weeks (19 February). Bas

2 1

Proposal: Applicative => Monad: Is there any consensus?
by John Smith 08 Feb '11

08 Feb '11

There has been much discussion on this proposal, much of it orthogonal to the actual patch. The discussion deadline has passed, but it is difficult to gauge whether consensus has been reached or not. Can we have a final yay or nay? The patch is attached to http://hackage.haskell.org/trac/ghc/ticket/4834

13 27

Cabal problem: cannot satisfy package-id ...
by Alistair Bayley 07 Feb '11

07 Feb '11

(Is this the best place for cabal help?) I'm trying to install Takusen and build the tests on an Ubuntu 10.4 machine, with haskell-platform 2010.1.0.0.1. Takusen itself built and installed correctly. When building the tests I get this failure: Building Takusen-0.8.7... Building executable takusen_tests... Creating dist/build/takusen_tests (and its parents) Creating dist/build/takusen_tests/takusen_tests-tmp (and its parents) /usr/bin/ghc --make -o dist/build/takusen_tests/takusen_tests -hide-all-packages -fbuilding-cabal-package -no-user-package-conf -package-conf dist/package.conf.inplace -i -idist/build/takusen_tests/takusen_tests-tmp -i. -idist/build/autogen -Idist/build/autogen -Idist/build/takusen_tests/takusen_tests-tmp -optP-DUSE_NEW_EXCEPTIONS -optP-include -optPdist/build/autogen/cabal_macros.h -odir dist/build/takusen_tests/takusen_tests-tmp -hidir dist/build/takusen_tests/takusen_tests-tmp -stubdir dist/build/takusen_tests/takusen_tests-tmp -package-id QuickCheck-2.1.0.3-c608a0a2c555bdf292cfea5b3273ac6b -package-id base-4.2.0.0-2cc27b7e43511c4ca001642a7f77a8f6 -package-id mtl-1.1.0.2-23ca4de7c573fd4df309067199a40634 -package-id old-time-1.0.0.3-9efceb2bb905784e503d6cf147359f62 -package-id random-1.0.0.2-cf650c34bae72c01e165a0d26c11236b -package-id time-1.1.4-1ced433acd576e314843b083f147bc38 -package-id Takusen-0.8.7 -O -XCPP -XDeriveDataTypeable -XScopedTypeVariables ./Main.lhs <command line>: cannot satisfy -package-id Takusen-0.8.7 (use -v for more information) (and that was the -v output) There's no clue as to why "-package-id Takusen-0.8.7" cannot be satisfied. "ghc-pkg list" shows the package (in the global database), as does "cabal list Takusen". Thanks, Alistair

1 0

Problem with xhtml 1.5.1.1: html tags are split
by Gwern Branwen 05 Feb '11

05 Feb '11

On Thu, May 13, 2010 at 11:38 AM, Gwern Branwen <gwern0(a)gmail.com> wrote: > On Tue, May 11, 2010 at 3:00 AM, Bjorn Bringert <bjorn(a)bringert.net> wrote: >> I support finding a new maintainer. > > Alright; as the old maintainer, I guess it falls on you to advertise > on -cafe and libraries. Has a request gone out yet? I didn't notice anything (maybe it got lost in all the recent haskell.org downtime), and the current Hackage page of xhtml is still listing Bjorn. Anyway, John MacFarlane has found a workaround which he's implemented in HEAD Pandoc (http://code.google.com/p/pandoc/issues/detail?id=134) from http://groups.google.com/group/pandoc-discuss/browse_frm/thread/915586b5c5e… : > Many people have wanted pandoc to produce "more normal" HTML output, > without nesting, but with line breaks between block elements (where > they aren't semantically significant). Something like this: > > <ul> > <li>a <a href="/foo">link</a></li> > <li>another list item</li> > </ul> > > I've found that I can get this kind of output, even using Text.XHtml's > renderer, by modifying the writer to insert raw newlines after block > elements, and using 'showHtmlFragment' rather than 'prettyHtmlFragment'. This may be useful for other people to know. (There are quite a few users of xhtml: http://bifunctor.homelinux.net/~roel/cgi-bin/hackage-scripts/revdeps/xhtml-… ) -- gwern http://www.gwern.net

1 0

Proposal: Change to library proposal process
by Ian Lynagh 02 Feb '11

02 Feb '11

Hi all, The current proposal process requires that both a ticket is created and a mailing list post sent at the start of the proposal. The ticket creation means: * Redundant work is done: The same information is repeated in two places * Some replies end up on the list, while others end up as a ticket comment * Tickets for rejected or abandoned proposals tend to hang around, cluttering up the bug tracker I propose that proposals are instead started by sending a message to the list, and a ticket is only created when and if consensus for the change has been reached. This proposal is orthogonal to the proposal to give some libraries maintainers, so that they no longer use the process. The proposal process would change to: Start: Send a mail to libraries@, with subject beginning "Proposal:", containing details of the change and a proposed deadline (at least 2 weeks time). End: If consensus for the change has been reached, file a ticket in the GHC trac, including: * A link to the start of the thread in the archives * A summary of the discussion * Details of the change, ideally in the form of a patch Suggested deadline: 24 Jan 2011 Thanks Ian

20 36

Re: parsec3 vs parsec-3.x
by Roman Cheplyaka 02 Feb '11

02 Feb '11

* Christian Maeder <Christian.Maeder(a)dfki.de> [2011-01-31 09:34:47+0100] > > Perhaps I missed something. Can someone please explain why do we have to > > have two different third parsecs? Should one of them be deprecated? When > > would a user prefer one to another? > > parsec-2 (and possibly its compatibility layer) may be deprecated or > superseded at some stage. > > > I read the description of parsec3 package on hackage, it tries to give > > some explanation, but still: > > > > 1. It's not clear why "you may want to develop your code using this > > subset of parsec3 modules". What advantage does it give? > > The parsec3 package only ensures that you are not using the > compatibility layer for parsec2 given by the modules > Text.ParserCombinators.Parsec*, because parsec3 code developed with > these modules might not work with parsec2 or parsec-2.x. >From the description of parsec3 on hackage [...] I do not recommend to unconditionally use parsec3 as dependency in cabal files of packages for hackage. But you may want to develop your code using this subset of parsec3 modules and finally change the dependency from parsec3 to parsec-3.1.1 [...] I got an impression that parsec3 should be used only during the development, not in a released package. But as a developer of a package I have pretty good understanding of what modules I'm using, and if in doubt I can simply run "grep -r Text.ParserCombinators.Parsec ." Maybe it would become more clear if you elaborate on who and how exactly might benefit from this package? Thanks, Roman -- Roman I. Cheplyaka :: http://ro-che.info/ Don't worry what people think, they don't do it very often. In-Reply-To: <4D467427.1000104(a)dfki.de>

3 7