September 2010 - Libraries

Proposal #3339: Add (+>) as a synonym for mappend
by Bryan O'Sullivan 08 Nov '11

08 Nov '11

Ticket: http://hackage.haskell.org/trac/ghc/ticket/3339 >From the ticket: This proposal was, I think, originally suggested by Jules Bean. The idea is to add two functions to the Data.Monoid module, (+>) and (<+), corresponding to different uses of mappend. These should not be methods of the Monoidtypeclass, but top-level functions. I hope (but slightly doubt) that the visual nature of the two operators might help to counter the thought that monoids are just for gluing things together. (+>) :: (Monoid a) => a -> a -> a a +> b = a `mappend` b (<+) :: (Monoid a) => a -> a -> a a <+ b = b `mappend` a infixl 4 +> infixl 4 <+ Proposed deadline: two weeks. If this looks reasonable, I'll attach darcs patches.

30 75

There are too many error handling conventions used in library code!
by dons＠cse.unsw.edu.au 13 Aug '11

13 Aug '11

This article on the 8 different error handling strategies various common Haskell libs use: http://www.randomhacks.net/articles/2007/03/10/haskell-8-ways-to-report-err… got me thinking: we need to standardise/recommend a small set of methods for library error handling. The lack of consistent error reporting between libs results in verbose code, as we're not able to use a single error handling technique when gluing together code from different libs (i.e. we can't just use Maybe or Either/ErrorT). (It's always nice when you *can* use, say, a Maybe monad to glue code from a number of sources, but eventually you reach code with a different error system, and the Maybe monad breaks down). So, some questions I think we can tackle: * can we identify error handling strategies from the list that should not be used anymore? (throwDyn?) * can we move some of the outlying libraries to a more consistent error framework? * do we need more support for gluing together our different error systems? (it should be easier to glue code using , say, Maybe/Either). * what role does MonadError play here, as a generic error handler? * can we make precise recommendations about which error strategies to use? -- Don

11 16

[darcs patch] filepath: normalise trailing dot
by Conrad Parker 21 Dec '10

21 Dec '10

Hi, the attached darcs patch modifies the behaviour of normalise to handle trailing dots in a path. The previous behaviour yielded this: Prelude System.FilePath> normalise "../." "../." Prelude System.FilePath> normalise ".././" ".././" Prelude System.FilePath> normalise ".././.." "../.." This patch modifies dropDots such that the check for (".":[]) only occurs once for the path, after which a driver function dropDots' is used which skips this check. Hence "." can be removed from the end of a longer path, but a path of just "." is unchanged. (my trac account is pending verification, I'll reply with a trac ticket # later if needed) cheers, Conrad.

4 7

Haskell Platform Proposal: add the 'text' library
by Don Stewart 07 Nov '10

07 Nov '10

= Proposal: Add Data.Text to the Haskell Platform = Maintainer: Bryan O'Sullivan (submitted with his approval) == Introduction == This is a proposal for the 'text' package to be included in the next major release of the Haskell platform. An up to date copy of this text is kept at: http://trac.haskell.org/haskell-platform/wiki/Proposals/text Everyone is invited to review this proposal, following the standard procedure for proposing and reviewing packages. http://trac.haskell.org/haskell-platform/wiki/AddingPackages Review comments should be sent to the libraries mailing list by October 1 so that we have time to discuss and resolve issues before the final deadline on November 1. http://trac.haskell.org/haskell-platform/wiki/ReleaseTimetable == Credits == Proposal author and package maintainer: Bryan O'Sullivan, originally by Tom Harper, based on ByteString and Vector (fusion) packages. The following individuals contributed to the review process: Don Stewart, Johan Tibell == Abstract == The 'text' package provides an efficient packed, immutable Unicode text type (both strict and lazy), with a powerful loop fusion optimization framework. The 'Text' type represents Unicode character strings, in a time and space-efficient manner. This package provides text processing capabilities that are optimized for performance critical use, both in terms of large data quantities and high speed. The 'Text' type provides character-encoding, type-safe case conversion via whole-string case conversion functions. It also provides a range of functions for converting Text values to and from 'ByteStrings', using several standard encodings (see the 'text-icu' package for a much larger variety of encoding functions). Efficient locale-sensitive support for text IO is also supported. This module is intended to be imported qualified, to avoid name clashes with Prelude functions, e.g. import qualified Data.Text as T Documentation and tarball from the hackage page: http://hackage.haskell.org/package/text Development repo: darcs get http://code.haskell.org/text/ == Rationale == While Haskell's Char type is capable of reprenting Unicode code points, the String sequence of such Chars has some drawbacks that prevent is general use: 1. unicode-unaware case conversion (map toUpper is an unsafe case conversion) 2. the representation is space inefficient. 3. the data structure is element-level lazy, whereas a number of applications require either some level of additional strictness An intermediate solution to these was via 'Data.ByteString' (an efficient byte sequence type, that addresses points 2 and 3), which, when used in conjunction with utf8-string, provides very simple non-latin1 encoding support (though with significant drawbacks in terms of locale and encoding range). The 'text' package addresses these shortcomings in a number of way: 1. support whole-string case conversion (thus, type correct unicode transformations) 2. a space and time efficient representation, based on unboxed Word16 arrays 3. either fully strict, or chunk-level lazy data types (in the style of Data.ByteString) 4. full support for locale-sensitive, encoding-aware IO. The 'text' library has rapidly become popular for a number of applications, and is used by more than 50 other Hackage packages. As of Q2 2010, 'text' is ranked 27/2200 libraries (top 1% most popular), in particular, in web programming. It is used by: * the blaze html pretty printing library * the hstringtemplate file templating library * *all* popular web frameworks: happstack, snap, salvia and yesod web frameworks * the hexpat and libxml xml parsers The design is based on experience from Data.Vector and Data.ByteString: * the underlying type is based on unpinned, packed arrays on the Haskell heap with an ST interface for memory effects. * pipelines of operations are optimized via converstion to and from the 'stream' abstraction[1] == The API == The API is broken into several logical pieces, which are self-explanatory: * combinators for operating on strict, abstract 'text's. http://hackage.haskell.org/packages/archive/text/0.7.2.1/doc/html/Data-Text… * an equivalent API for chunk-element lazy 'text's. http://hackage.haskell.org/packages/archive/text/0.7.2.1/doc/html/Data-Text… * encoding transformations, to and from bytestrings: http://hackage.haskell.org/packages/archive/text/0.7.2.1/doc/html/Data-Text… * support for conversion to Ptr Word16: http://hackage.haskell.org/packages/archive/text/0.7.2.1/doc/html/Data-Text… * locale-aware IO layer: http://hackage.haskell.org/packages/archive/text/0.7.2.1/doc/html/Data-Text… http://hackage.haskell.org/packages/archive/text/0.7.2.1/doc/html/Data-Text… == Design decisions == * IO and pure combinators are in separate modules. * Both a fully strict, and partially-strict type are provided. * The underlying optimization framework is stream fusion, (not build/foldr), and is hidden from the user. * Unpinned arrays are used, to prevent fragmentation. * Large numbers of additional encodings are delegated to the text-icu package. * An 'IsString' instance is provided for String literals. * The implementation is OS and architecture neutral (portable). * The implementation uses a number of language extensions: CPP MagicHash UnboxedTuples BangPatterns Rank2Types RecordWildCards ScopedTypeVariables ExistentialQuantification DeriveDataTypeable * The implementation is entirely Haskell (no additional C code or libraries). * The package provides a QuickCheck/HUnit testsuite, and coverage data. * The package adds no new dependencies to the HP. * The package builds with the Simple cabal way. * There is no existing functionality for packed unicode text in the HP. * The package has complexity annotations. == Open issues == The text-icu package is not part of this propposal. == Notes == The implementation consists of 30 modules, and relies on cabal's package hiding mechanism to expose only 5 modules. The implementation is around 8000 lines of text total. The public modules expose none of these (?). The Python standard library provides both a string and a unicode sequence type. These are somewhat analogous to the ByteString/String/Text split. = References = [1]: "Stream Fusion: From Lists to Streams to Nothing at All", Coutts, Leshchinskiy and Stewart, ICFP 2007, Freiburg, Germany.

25 85

Haskell Platform Proposal: add transformers and revise the mtl package to depend on it
by Ross Paterson 03 Nov '10

03 Nov '10

The proposal is that version 2 of the mtl package be the current contents of the monads-fd package, which depends on the transformers package: http://hackage.haskell.org/package/monads-fd http://hackage.haskell.org/package/transformers An up to date copy of this text is kept at: http://trac.haskell.org/haskell-platform/wiki/Proposals/transformers Everyone is invited to review this proposal, following the standard procedure for proposing and reviewing packages. http://trac.haskell.org/haskell-platform/wiki/AddingPackages Review comments should be sent to the libraries mailing list by October 15 so that we have time to discuss and resolve issues before the final deadline on November 1. http://trac.haskell.org/haskell-platform/wiki/ReleaseTimetable == Proposer == * Ross Paterson (maintainer of transformers and monads-fd) If this proposal is accepted, monads-fd would be obsoleted and transformers would be turned over to community control (like the current mtl package). == Rationale == Monad transformers are widely used, but the MTL interface is tied to functional dependencies, whose future is in doubt. Many people want to try out interfaces based on type functions, or without using experimental type class features, but their interfaces will then be incompatible with libraries using mtl. The idea is to factor out the monad transformers as the Haskell 98 package. The objectives for this package are: 1. that it be as useful as possible by itself, so that it can replace many uses of mtl. 2. that it serve as a base for other packages adding type classes based on either functional dependencies (e.g. mtl) or type functions, with interfaces referring to the monad transformers being compatible across the different libraries. The transformers and monads-fd packages have been in use for over 18 months, and are used by 112 and 23 packages respectively. The split structure has been shown to be viable, but its existence in parallel with mtl has meant extra effort for authors of client packages. It is time to complete the transition. == Structure == The current mtl is to be split in two: * transformers is a Haskell 98 package containing * base functors (Data.Functor.Constant and Data.Functor.Identity), * operations on functors (Data.Functor.Compose and Data.Functor.Product), * transformer classes (Control.Monad.Trans.Class and Control.Monad.IO.Class) and * concrete monad transformers with code to lift operators (Control.Monad.Trans.*). The package can be used on its own (see the Control.Monad.Trans.Class documentation for examples), or with packages adding type classes. * mtl-2 (the current monads-fd) depends on transformers and adds type classes using functional dependencies. It has the same modules as mtl-1 and usage is very close, except for the differences listed below. == Incompatibilities == The proposed interface of mtl-2 is close to that of mtl-1, but with the following differences (illustrated with Reader): * instances of Applicative and Alternative have been added as appropriate, e.g. instance (Applicative m) => Applicative (ReaderT r m) where ... instance (Alternative m) => Alternative (ReaderT r m) where ... Rationale: These classes postdate the MTL, and such instances have been repeatedly defined in various packages. They belong together with the type constructors. * Functor instances for monad transformers no longer require Monad where Functor is sufficient. Unfortunately this is incompatible because Functor is not a superclass of Monad, e.g. instance (Monad m) => Functor (ReaderT r m) where ... is replaced by instance (Functor m) => Functor (ReaderT r m) where ... Rationale: These instances are more general, and are consistent with the instances of other classes. * simple monads are now aliases for monad trasformers applied to Identity, e.g. newtype Reader r a = Reader { runReader :: r -> a } is replaced by type Reader r = ReaderT r Identity reader :: (r -> a) -> Reader r a reader f = ReaderT (Identity . f) runReader :: Reader r a -> r -> a runReader m = runIdentity . runReaderT m Rationale: This avoids repetition in the interfaces of both transformers and the proposed mtl-2. It makes transformers more useful on its own, and also saves clients of mtl from defining instances for both Reader r and ReaderT r and ensuring that they are consistent. * The instance Error String is restructured to avoid a type synonym instance: instance Error String where noMsg = "" strMsg = id is replaced by instance ErrorList a => Error [a] where strMsg = listMsg class ErrorList a where listMsg :: String -> [a] instance ErrorList Char where listMsg = id Rationale: This makes the instance Haskell 98, so it can be included in the transformers package. == Transition issues == In early September 2010, of the 510 buildable packages in hackage that directly depended on mtl, * 312 built unchanged with the proposed mtl-2 * 102 had a bounded mtl dependency (or a dependent package had) that excluded mtl-2 * 2 failed because of the recent move of the Monad (Either e) instance from mtl to base * 41 failed with the new mtl: * 11 because they defined their own Applicative instances (which can now be deleted) * 11 because of the changed constraint on Functor instances * 15 that used the constructors of base monads (which can be trivially replaced) * 3 that defined instances for base monads * 1 that defined an overlapping Error instance * 53 failed because they depended on one of the other failures The attached test report lists the packages involved. == Other issues == Some other issues have been raised with mtl over the years, but they are orthogonal to this proposal: * The MonadCont instance for StateT is not compatible with the monad transformer. The transformers package provides the correct lifting (in which callcc causes the state to rollback on entering the saved continuation), but also provides the MTL lifting for compatibility, and this is used by monads-fd. It could be switched to the correct lifting later. * The ErrorT monad transformer has an Error constraint, so that errors can be passed to the fail method of the Monad class. * ListT only works on commutative monads. Attachments * mtl-2.0.0.0.tar.gz (13.4 kB) -"proposed mtl-2.0.0.0.tar.gz", added by ross on 09/14/10 19:01:21. * test-Sep-2010 (21.3 kB) -"test of mtl-using packages in Sep 2010", added by ross on 09/15/10 20:05:56.

16 39

xhtml: Unable to generate valid HTML with radio buttons
by Joachim Breitner 23 Oct '10

23 Oct '10

Hi, the xhtml function "radio", like any other form widged generating function, takes one parameter, which is used both for the name and for the id. For the radio buttons, one usually has multiple widgets with the same name. Having also the same id is invalid HTML. Of course this can be avoided by changing the id or not using the "radio" function. But I think it would be more sensible to change the behavior of the form widgets to _not_ add the id attribute by themselves. Thanks, Joachim -- Joachim "nomeata" Breitner mail: mail(a)joachim-breitner.de | ICQ# 74513189 | GPG-Key: 4743206C JID: nomeata(a)joachim-breitner.de | http://www.joachim-breitner.de/ Debian Developer: nomeata(a)debian.org

2 2

Proposal: Add throwSTM and generalize catchSTM
by Bas van Dijk 19 Oct '10

19 Oct '10

Dear all, Currently the only way to throw an exception in an STM transaction is via throw. The IO monad has the throwIO function which guarantees ordering with respect to other IO actions. It would be nice to have a similar function for the STM monad: throwSTM :: Exception e => e -> STM a I propose adding this to Control.Monad.STM. Additionally I propose to generalize: catchSTM :: STM a -> (SomeException -> STM a) -> STM a to: catchSTM :: Exception e => STM a -> (e -> STM a) -> STM a to make it consistent with the IO catch function: catch :: Exception e => IO a -> e -> IO a -> IO a and allow packages like exception-monads-fd/tf to define an instance MonadException STM. I don't have a patch because I think these changes also require modifying/extending the rts which I don't feel comfortable with doing right now. Discussion deadline: Three weeks, until Sunday 17th October (because of ICFP). Ticket: http://hackage.haskell.org/trac/ghc/ticket/4343 Regards, Bas

6 13

Proposal: Move 'split' into a separate class in System.Random
by Thomas DuBuisson 11 Oct '10

11 Oct '10

The "split" routine in the RandomGen seems to be a sore spot for some people and is perceived to have few users (even as a percentage of RandomGen users). I propose: 1) Making a class "SplittableGen": class SplittableGen g where split :: g -> (g, g) 2) (re)moving the "split" routine from the RandomGen class. See ticket 4314 [1] for the patch. Period of discussion: Till October 8 (3.5 weeks, ending just over 1 week after ICFP) Cheers, Thomas [1] http://hackage.haskell.org/trac/ghc/ticket/4314

17 29

Proposal: Generalize the RandomGen and Random classes
by Thomas DuBuisson 10 Oct '10

10 Oct '10

Hello, RandomGen and Random classes assume generators produce Int values. This is non-ideal as many high speed generators produce special values (ex: doubles) or generic values (bit streams / bytestrings) that can be converted directly to types easier than coercing to Int then to an 'a' via the Random class. See 4315 [1] for the patch. Period of discussion: Till October 8 (3.5 weeks, giving a little time after ICFP for last minute debate) Specifically, this proposal: 1) Alters RandomGen: from: class RandomGen g where next :: g -> (Int, g) genRange :: g -> (Int, Int) to class RandomGen g v | g -> v where next :: g -> (v, g) genRange :: g-> (v,v) 2) Alters Random: From: class Random a where randomR :: RandomGen g => (a,a) -> g -> (a,g) random :: RandomGen g => g -> (a, g) randomRs :: RandomGen g => (a,a) -> g -> [a] randoms :: RandomGen g => g -> [a] randomRIO :: (a,a) -> IO a randomIO :: IO a to class Random a where randomR :: RandomGen g v => (a,a) -> g -> (a,g) random :: RandomGen g v => g -> (a, g) randomRs :: RandomGen g v => (a,a) -> g -> [a] randoms :: RandomGen g v => g -> [a] Additional Points of Debate 1) Because random[R]IO can not be part of the new Random instance with a sensible default, these have been moved to top-level functions: randomRIO :: (Random a Int) => (a,a) -> IO a randomIO :: (Random a Int) => IO a Other options exist and I'm open to them. I'm just being upfront about what the patch currently does. 2) All pre-existing instances of "Random x" for some concrete 'x' have been modified to be "instance Random x Int". As 'Int' was the previous (hardcoded) default for RandomGen this is simply matching the behavior. More instances are possible and probably make sense now. Alternatively, one could argue for zero default instance as they can collide with how a particular user wishes types to be coerced. 3) Not-so-new extensions are used to enable these changes. Extensions include MultiParamTypeClasses, FlexibleContexts, and FunDeps. 4) A patch is included bumping the version from 1.0.0.x to 1.1.0.0. Cheers, Thomas [1] http://hackage.haskell.org/trac/ghc/ticket/4315

12 20

Replaced throw to throwIO where type is IO
by Bas van Dijk 08 Oct '10

08 Oct '10

Hello, Attached is a small patch to: Control/Exception/Base.hs which replaces all uses of 'throw' to 'throwIO' where the type is IO. It would be nice if someone can review and apply it. Regards, Bas

5 12