- Libraries - Haskell.org

Pretty class as alternative for Show class
by Henning Thielemann 14 Feb '08

14 Feb '08

There seems to be the need for (at least) two classes for showing values in Haskell: One class that outputs values in a way that can be copied and pasted into Haskell programs. This is useful in GHCi. Another class (say Pretty) that shows values in a prettily formatted way. Current libraries use the Show class for both applications depending on the taste of the author. A third class would be useful for outputting values with markup, say HTML or LaTeX. The Show class converts to String, the Pretty class could convert to a pretty printer data type like Doc. The Show class should output all data that is necessary to reconstruct the value, but not necessarily in the form of the underlying data structure, but maybe using appropriate generating functions. Thus e.g. 'show' for Doubles does not need a parameter for precision, it just emits all available digits. On the other hand a Pretty class should have such parameters (maybe then requiring a multi-parameter type class with functional dependency from value type to formatting style type). A nice infix operator like (//) like in the GSL wrapper could flatten the Pretty data to String, and thus is easy to use in GHCi. Matrix> fiboMatrix matrix [[1,0], [1,1]] Matrix> fiboMatrix // 3 /1.000 0.000\ \1.000 1.000/ where (//) :: Pretty style value => value -> style -> IO String x // p = putStr (Doc.toString (Pretty.toDoc p x)) class Pretty style value | value -> style where toDoc :: style -> value -> Doc If such a separation would become consensus then libraries could better separate the concerns of pretty output and re-usable output.

5 10

Labelled graphs in fgl
by Henning Thielemann 14 Feb '08

14 Feb '08

Is there a reason why graphs in fgl are labeled by default, and unlabelled graphs must be constructed by labeling with () ? In my opinion the more natural design would be to number the nodes and edges with an Enum type instead of Int and to retrieve the labels from an array. This would support the "from simple to complex" design.

2 5

Re: Data.Ord and Heaps
by Ross Paterson 14 Feb '08

14 Feb '08

[redirecting to libraries] On Mon, Feb 04, 2008 at 01:09:00PM +0100, Stephan Friedrichs wrote: > apfelmus(a)quantentunnel.de wrote: >> [newtype Ord a => Reverse a = Reverse { unReverse :: a }] >> >> Yes. I mean "non-standard" in the software-reuse sense, i.e. Ord is for >> user-defined orderings and should be the only such mechanism in order >> to enable reuse. In fact, Data.Heap clearly shows that Data.Ord is >> currently missing functionality. > > Ah, now I see. The entire ordering policy mechanism - no matter how it > is going to be solved - belongs into Data.Ord and not in Data.Heap. As > soon as Data.Ord provides a solution, I'll use it in Data.Heap. Unfortunately the Data.Ord module is constrained to use only Haskell 98 features, because it is used by all implementations. So it could include the above Reverse (also mentioned in the group-by HW paper), but not the various OrdPolicy proposals. They could go in a separate module, though. Off on a tangent: the containers package, which collects portable implementations of general purpose data structures, could use a good priority queue implementation. However it is also constrained to use only Haskell 98 features, which would rule out using policies. Also, using weight-biased leftist trees (Cho & Sahni, 1996) instead of Knuth's rank-biased leftist trees would offer O(1) size for free. And they come out slightly faster in my test runs.

2 1

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 07 Feb '08

07 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 07 Feb '08

07 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