- Libraries - Haskell.org

Monoid instances for mtl
by Stefan Holdermans 07 Jul '09

07 Jul '09

Hi all, On a number of occasions I found myself declaring simple instances like instance Monoid a => Monoid (State s a) where mzero = return mzero mappend = liftM2 mappend that make my life considerably easier. Would it be a good idea to add such instances to the Monad Transformer Library? Of course, one could ask where to stop---but for me it make sense to always add sensible instances of the classes from base to a given library. Cheers, Stefan

2 1

Documentation design
by Isaac Dupree 06 Jul '09

06 Jul '09

(for reference, here's the blog-post I wrote that inspired me to ask this list for advice. I'll explain everything in this email anyway though. http://haddock2009.wordpress.com/2009/06/23/how-to-navigate-your-code/ ) My challenge: getting to know an existing code-base quickly and easily, so that I can hack on it. Haddock and HsColour are already pretty helpful at this, but they could be more helpful. (haddock with --ignore-all-exports, i.e. cabal haddock --internal, especially) My dream situation: both haddock-pages and hscolour-pages would be super-hyperlinked and super-readable. For example, haddock would list all a module's definitions, not just its exports. In HsColoured source, every identifier would link to its definition or the haddockumentation of its definition. and so forth. It would be so much easier to generate and browse this in HTML, than to get an IDE working, and it would be so much more readable than a mere text-editor (even with syntax hilighting) and quicker clicking on hyperlinks than grepping for everything. Actually I don't have the resources to worry about designing any HsColour stuff right now (its current design is mainly just a lexeme highlighter). But, with your advices, I can design an improvement on Haddock's ignore-exports mode, which currently has a few shortcomings: 1. you can't tell which identifiers in a module are exported 2. it doesn't document a module's re-exports at all 3. it still obeys {-# OPTIONS_HADDOCK hide #-} et al, even when they're not appropriate for reading documentation of internals 4. 2+3 means that some things may be found nowhere in the documentation at all! Not quite satisfying for something invoked by `cabal haddock --internal`. (Here's a haddock-generated page you can look at so you can figure out the formatting-details I'll be describing: http://www.haskell.org/ghc/docs/latest/html/libraries/base/Data-List.html and its source code http://www.haskell.org/ghc/docs/latest/html/libraries/base/src/Data-List.ht… ) The ideal haddockumentation-formatting for this purpose isn't quite obvious though. For example, sometimes you want to think about a module in terms of its abstract interface, but sometimes you want to figure out how it's implemented (without reverting completely to text based code browsing). Maybe a compromise of some sort would be good. so... Here's a proposal, for a new mode (`haddock --all-internal`?, to be invoked by `cabal haddock --internal` rather than --internal's current effect of ignore-all-exports) : Files with no explicit export list can be treated as-is anyway. For all files that have an explicit export list, generate the synopsis-of-exports near the top, as usual. But have the index link, generally, to where functions are originally defined (modulo being from a non-internally-documented separate package, where it should link to the appropriate place), and have the fuller documentation below be a compilation of the identifiers *defined* in this module. Actually that would need some revision because the sections and subsections -- *, -- **, etc. defined in the export-list in the .hs, actually are displayed 1. above the table of contents, linking to places in 2. the full list of definitions. Which might be defined in the module in a different order than they're listed in the export list. Why not add the sections into the synopsis? In this case, instead of adding them to the main doc section. But hmm... in ordinary non-internal documentation, would it be nice to *additionally* have the sections marked in the synopsis (in addition to in the Contents and in the main docs section)? Maybe this mode should also abstain from "hiding" any module, because that would cause missing docs. Etc. Questions? Comments? Opinions? Does anyone want this feature, and/or not think it's particularly useful? -Isaac

2 1

base library and GHC 6.12
by Ian Lynagh 01 Jul '09

01 Jul '09

Hi all, There has been some discussion recently about the base library. In particular, base is supposed to follow the PvP, which means that certain sorts of changes require increasing the version number. When the version number is increased, this makes work for lots of people, as any packages correctly using an upper bound on base's version number need to be updated. For modules like Data.List this makes sense, but base also contains a number of modules in the GHC.* hierarchy which, while exposed, are really internal, and much less stable than the "public" API. There is also another issue: Currently, it is not possible for a package to specify, in its dependencies, whether or not it uses these GHC.* modules. We therefore can't easily tell whether a package is sensitive to changes in those modules, or whether it can be used with hugs, nhc98, etc. We've come up with 3 possible ways forward. Comments, suggestions and criticisms welcomed! Option 1 -------- In order to solve the version number issue, we could simply state that "base follows the PvP, but only for shared module hierarchies". However, it would be impossible for packages which /do/ need GHC.* modules to give accurately versioned dependencies, and it wouldn't solve the other issue at all. Option 2 -------- Another possible solution would be to rename the base package to base-internals, and to make base only re-export the "public" modules. This would require either renaming each module M to Internal.M, or for every implementation to support something like GHC's PackageImports extension. Option 3 -------- The other alternative is to try to split base into two parts: The shared "public" modules, and the internal GHC.* modules. Then GHC would have ghc-base, hugs would have hugs-base, etc, and there would be a common base package built on top of the appropriate impl-base. To do this with minimal loss of code sharing is a large task, and hard to just do in a branch, as merging changes made in the base HEAD is a pain when the file the patch applies to has moved to another repository. Thus in the short term we would expect to give up a reasonable amount of code sharing, but we hope that once we have separate impl-base packages it will be easier to untangle their contents (as impl-base will be significantly smaller than base currently is, and because we can rearrange imports and code inside impl-base without having to worry about breaking other implementations), and then regain as much sharing as possible. I've had a look at what can be done, and the first cut looks like this: We start off with 143 modules in base, 89 of which are public and 54 of which are GHC.*. Afterwards, base has 53 modules, 2 of which are GHC.*: * GHC.Exts, which could be moved into ghc-base, but would take Data.String with it, or it could go into a ghc-exts package. As this is "more public" than the other GHC.* modules, this seems like a reasonable thing to do anyway * GHC.Desugar, which could be put into its own package if nothing else Here's the module graph, which looks quite sane: http://community.haskell.org/~igloo/base-small.png That leaves 90 modules in ghc-base, 52 of which are GHC.*, and 38 of which are in the portable namespace. So almost all GHC.* modules have moved, and more than half of the portable modules are in base. These 38 are the interesting ones: Control.Exception.Base Control.Monad Data.Bits Data.Char Data.Dynamic Data.Either Data.HashTable Data.Int Data.List Data.Maybe Data.Tuple Data.Typeable Data.Word Foreign Foreign.C Foreign.C.Error Foreign.C.String Foreign.C.Types Foreign.ForeignPtr Foreign.Marshal Foreign.Marshal.Alloc Foreign.Marshal.Array Foreign.Marshal.Error Foreign.Marshal.Pool Foreign.Marshal.Utils Foreign.Ptr Foreign.StablePtr Foreign.Storable Numeric System.IO.Error System.IO.Unsafe System.Posix.Internals System.Posix.Types Text.ParserCombinators.ReadP Text.ParserCombinators.ReadPrec Text.Read.Lex Text.Show Unsafe.Coerce Some of them are easy to move back into base, e.g. Foreign contains no code, and Numeric is only needed so that GHC.Ptr can use showHex for its Show instance. Some are more integral to the implementation of the rest of GHC.*. I've only tried this for amd64/Linux, so it's possible that dependencies on other platforms could cause additional problems. Here's the module graph, which is somewhat messier than base's: http://community.haskell.org/~igloo/ghc-base-small.png As with option 2, for each implementation, either impl-base needs to rename the public modules M to Impl.M, or it needs to implement something like GHC's PackageImports extension. Thanks Ian

9 14

zlib and dependencies in general
by Iain Barnett 30 Jun '09

30 Jun '09

I've been trying to build zlib (any version) onto a Debian 5.1 machine, and had a few problems. I've solved these now, but one of them was a dependence on not only zlibc/zlib1g as you'd expect, but zlib1g-dev as well, and wasn't actually in any of the error messages. I ended up relying on a solution given for a similar problem with mySQL installation. I noticed that Hackage only lists Haskell library dependencies - might it be an idea to list other non-Haskell ones, too? cabal-install won't install without zlib, so there's no ease of installation to rely on, and not everyone would have found/read the mySQL post. Just a thought. Iain

3 6

Bug in Data.LargeWord
by Dominic Steinitz 29 Jun '09

29 Jun '09

Someone sent me a bug report for this. Unfortunately, my email has not worked since 9 June so it is lost. Did anyone see it? Could the poster resend? Many thanks, Dominic.

1 0

BerkeleyDBXML linking problems.
by Sebastiaan Visser 27 Jun '09

27 Jun '09

Hello all, After manually specifying where to find the appropriate include and library directories for the dbxml distribution, I succeeded to install both the BerkeleyDB and the BerkeleyDBXML Haskell bindings. They both nicely show up in `ghc-pkg list'. But when I try to compile my own test or the demo program included in the BerkeleyDBXML package it will kindly present me a dozen or so pages of linking errors. The top lines are: Undefined symbols: "std::basic_string<char, std::char_traits<char>, std::allocator<char> >::_Rep::_M_destroy(std::allocator<char> const&)", referenced from: __xmlDocument_setContent in libHSBerkeleyDBXML-0.6.2.a(dbxml_helper.o) ... Do I have to tell GHC where to find the original dbxml libraries when compiling my BerkeleyDBXML aware Haskell programs? Small system overview: - Mac OS X 10.5.7 - GHC 6.10.3 - BerkeleyDB 0.7.1 - BerkeleyDBXML 0.6.2 - gcc/g++ 4.0.1 Any clue on how to fix this? Thanks, -- Sebastiaan Visser

2 1

Revamping the module hierarchy (was: ANNOUNCE: OpenGLRaw 1.0.0.0)
by Johan Tibell 25 Jun '09

25 Jun '09

All, On Fri, Jun 12, 2009 at 11:24 AM, Sven Panne <Sven.Panne(a)aedion.de> wrote: > One point here is debatable: Do we really need the ".Rendering" part in the > package name or would simply "Graphics.OpenGL.Raw" be enough? We discussed > the > structure of the hierarchy when hierarchical packages were in their > infancy, > many years ago, and it was consensus then to distinguish between > "Graphics.Rendering" and "Graphics.UI". I don't have very strong feelings > about ".Rendering" and ".UI", and if the consensus nowadays is to remove > it, > I'll be happy to change this. But let's move the discussion about this to > the > libraries mailing list. > Perhaps it's time to overhaul the hierarchy. Some top level module namespaces like Network have become very crowded. Network is a very generic name that it conveys very little information today when most software has a network component. I suggest that parts of it be broken out into new top level modules. As a first step I suggest we create a new Http (and not HTTP with all caps please) module where we can have: Http.Client Http.Server Http.UrlEncoding Http.Cookies etc. Cheers, Johan

12 17

darcs patch: Fix detection of libiconf.
by Matthias Kilian 24 Jun '09

24 Jun '09

Sat Jun 20 14:21:59 CEST 2009 Matthias Kilian <kili(a)outback.escape.de> * Fix detection of libiconf. It's not enough to try to link against libiconv and look for a symbol iconv_open, because iconv may be installed in a way that internally renames iconv_foo to libiconv_foo in the library and adds corresponding #define iconv_foo libiconv_foo to iconv.h. This patch is needed on OpenBSD (but it's not enough, since cabal suffers from the same problem).

3 13

Proposal: Add Foldable and Traversable instances for ((,) a)
by Yitzchak Gale 23 Jun '09

23 Jun '09

These instances are pretty obvious, and no more or less trivial than the existing instances for Prelude types. I have found them to be useful. > instance Foldable ((,) a) where > foldMap f (_, y) = f y > foldr f z (_, y) = f y z > foldl f z (_, y) = f z y > foldr1 _ (_, y) = y > foldl1 _ (_, y) = y > instance Traversable ((,) a) where > traverse f (x, y) = (,) x <$> f y In the spirit of the world's finest legislative bodies, I am attaching two unrelated amendments to this proposal. One amendment is to add a few additional explicit method implementations in the Foldable and Traversable instances for Prelude types. These might sometimes be slightly more efficient, and they better match the strictness and style of the existing explicit method implementations. For lists: > sequence = Control.Monad.sequence For Maybe: > foldMap _ Nothing = mempty > foldMap f (Just x) = f x > foldr1 _ Nothing = error "foldr1 of Nothing" > foldr1 _ (Just x) = x > foldl1 _ Nothing = error "foldl1 of Nothing" > foldl1 _ (Just x) = x For arrays: > foldl f z = Prelude.foldl f z . elems > foldr1 f = Prelude.foldr1 f . elems > foldl1 f = Prelude.foldl1 f . elems The other amendment is to fix the documentation for the functions fmapDefault and foldMapDefault in Data.Traversable. Contrary to what is stated, these cannot be used as methods in superclasses, since the superclasses must already exist before these functions can be defined. Instead, I have paraphrased what is stated in the documentation above: that the corresponding superclass methods should be equivalent to these. http://hackage.haskell.org/trac/ghc/ticket/3324 Discussion period: two weeks.

2 3

Re: Top Level
by John Lato 23 Jun '09

23 Jun '09

> From: wren ng thornton <wren(a)community.haskell.org> > > I think at this stage in the game, OpenGL.* is probably better. The way > I see it there are two rather different kinds of modules (or module > collections): > > * For module collections which have high utility across many different > packages/programs (e.g. Data.Map, Control.Monad), having > functionality-based names is helpful for solving name-clash and > functionality-discovering/remembering issues. These modules are truly > stand-alone "libraries" and are extremely composable (with other module > collections) and extremely decomposable (from module collection into the > constituent modules). > > * However, there are other collections of modules which are not > "libraries" so much as "frameworks". While they're still (usually) > composable, they're typically not decomposable. Often these are the > results of taking an executable and shaving off some of the front-end > details. Because of the non-decomposability, it makes sense to me to > give each of these a top-level module name. Under the top-level they > should be organized by functionality--- in the terms of the framework > itself, not in the general terms shared by the "libraries". > +1. For me, the largest problem with the current system is one that Simon mentioned under his third point. While I may know what to expect from a module named "Control.Functor.Pointed", I have no idea what package to import to get that functionality.* This situation is worse in the cases of multiple packages providing the same modules, such as transformers and mtl. I do think that the module namespace hierarchy is useful, and I am not convinced that the top level should be flattened, but I think it would be good to have some sort of tighter connection between package name and either the top level or second level module name, even if only as a convention. John Lato * I actually do know, because it's my example. It's in category-extras. I was able to find this in Hayoo!, but not Hoogle.

2 2