- Libraries - Haskell.org

darcs patch: Small documentation fix
by vandijk.roel＠gmail.com 13 Feb '08

13 Feb '08

Wed Feb 6 01:58:29 CET 2008 Roel van Dijk <vandijk.roel(a)gmail.com> * Small documentation fix

2 1

Re: [Haskell] ANNOUNCE: Haddock version 2.0.0.0
by Ross Paterson 13 Feb '08

13 Feb '08

On Tue, Jan 08, 2008 at 01:28:50PM +0100, David Waern wrote: > * Format of module attributes has changed. The only way of specifiying > module attributes is via a new OPTIONS_HADDOCK pragma. Example: > {-# OPTIONS_HADDOCK hide, prune #-} Unfortunately the old-style attributes are widely used: over 400 modules in hackage, including 100 shipped with GHC. The vast majority of these are #hide, which ideally should be unnecessary if the modules are not exposed. However some packages expose modules for use in the internals of other packages, but don't want to show those modules in the documentation. For example, most of the GHC.* modules in the base package, which are used in the internals of many of the packages split from base. If I add the new-style attributes to the base package, it hides those modules in the documentation for base, but packages that depend on base seem to generate links to locations in those hidden modules, e.g. uses of IO point at GHC.IOBase.IO. Also, the new haddock rejects some modules the old one accepted. For example, it doesn't like extra doc comments that aren't attached to anything. It also rejects data Pair = Pair {-# UNPACK #-} !Int -- ^ first field {-# UNPACK #-} !Int -- ^ second field

2 8

Re: [Haskell] ANNOUNCE: Haddock version 2.0.0.0
by David Waern 10 Feb '08

10 Feb '08

2008/2/10, Bryan O'Sullivan <bos(a)serpentine.com>: > David Waern wrote: > >> It also rejects > >> > >> data Pair = Pair {-# UNPACK #-} !Int -- ^ first field > >> {-# UNPACK #-} !Int -- ^ second field > > > > I just took a look a this last issue. It is not a bug, > > Perhaps you mean "not a regression" :-) > > <b Right, it would perhaps be useful to have this. David

1 0

Re: ANNOUNCE: multiset 0.1
by Twan van Laarhoven 08 Feb '08

08 Feb '08

(moving discussion to the libraries list) Wolfgang Jeltsch wrote: > this is interesting. A few days ago I discovered that I needed such a library > and decided to implement it myself. However, I had not started yet when I > received your e-mail. > > A bit of criticism concerning the name: According to the English Wikipedia, > multiset is a single word. So the identifiers should be Multiset and > IntMultiset instead of MultiSet and IntMultiSet. After looking around a bit, it seems 'multiset' is consistently spelled as a single word. Personally I think "MultiSet" looks better, but if more people agree with you I will change the name in the next version. > However, I think it would > be even better to just use Bag and IntBag as identifiers. Those are shorter > and maybe easier to remember. After all, the term bag is fairly standard. There are two several for choosing "multiset" over "bag": - The name "multiset" covers the functionality much better. If I didn't know the name of the data structure, only that it is like a set containing multiple copies of elements, I would find it if it was called multiset, not if it was called bag. - The name Bag is also used for other data structures. For instance GHC uses 'bag' for an ordered data structure with fast concatenation. - Other libraries like the C++ STL also use the name multiset. > I think that actually your multiset/bag implementation should be a part of the > containers package. So why not ask the maintainers of the containers package > for permission to add your implementation and change the identifiers to Bag > and IntBag during this process? This would be great. I initially wrote these modules as part of the containers package. Unfortunatly the libraries process is awefully slow. And if you think about it, there isn't a big advantage to having multiset in the containers package. I decided to get the code out there quickly, so it can be used right now. Perhaps the library could/should be merged into the containers package somewhere in the future. Twan

2 1

Re: ANNOUNCE: multiset 0.1
by Christian Maeder 08 Feb '08

08 Feb '08

Twan van Laarhoven wrote: > Hackage: > http://hackage.haskell.org/cgi-bin/hackage-scripts/package/multiset-0.1 > Haddock: http://twan.home.fmf.nl/multiset/doc/ > Darcs: http://twan.home.fmf.nl/repos/multiset/ There used to be Daan's DData http://research.microsoft.com/users/daan/ddata.html How does your implementation relate to his (MultiSet and IntBag)? (partial reuse or duplication, differences) Cheers Christian

2 1

Re: ANNOUNCE: multiset 0.1
by Christian Maeder 07 Feb '08

07 Feb '08

> Hackage: > http://hackage.haskell.org/cgi-bin/hackage-scripts/package/multiset-0.1 > Haddock: http://twan.home.fmf.nl/multiset/doc/ > Darcs: http://twan.home.fmf.nl/repos/multiset/ Seeing all these nice little packages (i.e. also bimap), is there a cute way to get a binary distribution - similar to the current extra libs - with many packages already included, so that installation can be accomplished in one go (maybe for the next ghc release)? Cheers Christian

1 0

Minor issue with mapAccumR
by Cale Gibbard 07 Feb '08

07 Feb '08

I'm not sure whether this would be considered worth fixing right away, or if we should wait until some other major compatibility breaking language change to fix it, but it appears that somehow the parameters to the function passed to mapAccumR are flipped relative to their natural order. To show what I mean, here is some code: Prelude Data.List> mapAccumR (\x y -> (concat ["(f ",x," ",y,")"], concat ["(g ",x," ",y,")"])) "z" ["1","2","3"] ("(f (f (f z 3) 2) 1)",["(g (f (f z 3) 2) 1)","(g (f z 3) 2)","(g z 3)"]) You can see here that the list is flipped over in the process, even though the right fold structure is there, it ends up looking like a left fold over the reverse of the list. One would want the law: fst . mapAccumR f z = foldr (fst . f) z to be true, but instead we have: fst . mapAccumR (flip f) z = foldr (fst . f) z You can see that structurally if we flip the parameters in the above example: Prelude Data.List> mapAccumR (\y x -> (concat ["(f ",x," ",y,")"], concat ["(g ",x," ",y,")"])) "z" ["1","2","3"] ("(f 1 (f 2 (f 3 z)))",["(g 1 (f 2 (f 3 z)))","(g 2 (f 3 z))","(g 3 z)"]) I also have some diagrams on http://cale.yi.org/index.php/Fold_Diagrams (near the end) displaying the difference, and that's where I first noticed it. Are many people using mapAccumR? How much would it hurt to change it? - Cale

3 3

lambdabot setup
by Valery V. Vorotyntsev 06 Feb '08

06 Feb '08

Dear, lazy programmers, Please let me know the proper place to report lambdabot bugs, and feel free to ignore the rest of message. Are you still reading? In this case you may want to know that *** I've successfully installed lambdabot with GHC 6.9! :) *** Kudos to Cale & the IRC crowd for making my day [http://tunes.org/~nef/logs/haskell/08.02.04] Boring part: $ darcs get http://code.haskell.org/lambdabot $ cd lambdabot $ runhaskell Setup configure --prefix=$HOME --user $ runhaskell Setup build $ touch LICENSE # see the patch attached $ runhaskell Setup install Interesting part: $ lambdabot -e 'hoogle map' Initialising plugins ...........Plugin.Djinn: couldn't find djinn binary ...........................sending message to bogus server: IrcMessage {msgServer = "freenode", msgLBName = "urk!<outputmessage>", msgPrefix = "", msgCommand = "NAMES", msgParams = [""]} .................. done. A Hoogle error occured. Exception: all servers detached exception: State/seen: openBinaryFile: does not exist (No such file or directory) $ hoogle map Could not find hoogle database, looked for: hoogle.txt In order to make `hoogle' binary usable, one should copy `hoogle.txt' file to "$(dirname $(which hoogle))/" directory: $ cp State/hoogle.txt ~/bin/ # FIXME $ hoogle map [...success...] To my believe, it's a package's responsibility to copy data files to proper locations (during `runhaskell Setup install' step). And hoogle _plugin_ still doesn't work though. $ lambdabot Initialising plugins ...........Plugin.Djinn: couldn't find djinn binary ...........................sending message to bogus server: IrcMessage {msgServer = "freenode", msgLBName = "urk!<outputmessage>", msgPrefix = "", msgCommand = "NAMES", msgParams = [""]} .................. done. lambdabot> hoogle map A Hoogle error occured. lambdabot> lambdabot: user error (<eof>) Exception: all servers detached Thank you. -- vvv PS: Tue Feb 5 18:38:55 EET 2008 "Valery V. Vorotyntsev" <valery.vv(a)gmail.com> * `LICENSE' file added Tue Feb 5 18:37:12 EET 2008 "Valery V. Vorotyntsev" <valery.vv(a)gmail.com> * lambdabot.cabal: add `build-type' to make Cabal happy

2 3

Proposal: Add concatMapM function (#2042)
by Twan van Laarhoven 06 Feb '08

06 Feb '08

Hello library people, I have noticed that many projects include a 'concatMapM' function: concatMapM :: (Monad m) => (a -> m [b]) -> [a] -> m [b] I think this is useful in general, so let's add it to Control.Monad. Trac ticket: http://hackage.haskell.org/trac/ghc/ticket/2042 Deadline for discussion: 2 weeks from now, January 28 Twan

25 94

fgl-bug
by Christian Maeder 05 Feb '08

05 Feb '08

Hallo Martin, I was going to use xdfWith from Data.Graph.Inductive.Query.DFS with Data.Graph.Inductive.Graph.out' as second argument, but 1. xdfWith is not exported 2. out' seems to be wrong (by looking at the source code) -- | All outward-directed 'LEdge's in a 'Context'. out' :: Context a b -> [LEdge b] out' c@(_,v,_,_) = map (\(l,w)->(w,v,l)) (context4l' c) ^^^ I think, the outgoing edge must be made as "(v,w,l)"! inn' looks correct: -- | All inward-directed 'LEdge's in a 'Context'. inn' :: Context a b -> [LEdge b] inn' c@(_,v,_,_) = map (\(l,w)->(w,v,l)) (context1l' c) Can 1. and 2. be fixed? I need the general xdfWith because I want to filter out some successors (or maybe I can filter to whole graph first). Cheers Christian

1 0