October 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

Applicative instance for ST
by Daniel Peebles 29 Dec '10

29 Dec '10

Hi all, Strangely enough, ST has a Functor and a Monad instance, but no Applicative instance (I guess it was pre-Applicative). I propose to add one. It doesn't seem very controversial, but I guess a normal discussion period for these proposals is two weeks? Thanks, Dan

6 10

[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

Proposal: Export String from Data.String (and two related proposals)
by Bas van Dijk 01 Dec '10

01 Dec '10

Hello, I would like to make three proposals, in order of importance IMHO: 1. Export String from Data.String. Most modules in base and on Hackage of the form: Data.<type> also export <type>. I think it's surprising and confusing that Data.String doesn't conform to this pattern. 2. Unexport String from Data.Char. I feel less strongly about this one, but in general I think it is good that a symbol is exported from as few modules as possible. 3. Export the String operations: lines, words, unlines and unwords from Data.String. I feel even less strongly about this one. However these are operations on Strings so it makes sense to export them from Data.String. As a counter argument you could say these operations either receive or produce a _list_ of Strings so they only belong in Data.List. If we accept 3 then in the spirit of "export a symbol from as few modules as possible", you may expect a fourth proposal: Unexport the String operations: lines, words, unlines and unwords from Data.List. However I think this will break lots of programs. I have no problem also discussing this one though. Discussion deadline: 3 weeks from now: Wednesday 10 November. Ticket with patches: http://hackage.haskell.org/trac/ghc/ticket/4422 Regards, Bas

5 10

Proposal: Add IsString and Monoid instances for Doc
by Bas van Dijk 13 Nov '10

13 Nov '10

Hello, Since we're discussing a proposal for the pretty package I would like to make another one: The proposal is to add the following to Text.PrettyPrint.HughesPJ: instance IsString Doc where fromString = text This allows users to use string literals as Doc values using the OverloadedStrings language extension. I would also like to add: instance Monoid Doc where mempty = empty mappend = (<>) If there's enough demand (because it's a lot of work) I can find out if this change breaks anything by analyzing pretty's direct reverse dependencies: http://bifunctor.homelinux.net/~roel/cgi-bin/hackage-scripts/revdeps/pretty… to see if some of them define an orphaned instance for IsString or Monoid. The patch that implements this is attached to the ticket: http://hackage.haskell.org/trac/ghc/ticket/4378 Deadline: 2 weeks (Friday 22 October 2010) Regards, Bas

2 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

Re: [Haskell-cafe] Bug in HTTP (bad internal error handling)
by Ganesh Sittampalam 03 Nov '10

03 Nov '10

On Fri, 22 Oct 2010, Sigbjorn Finne wrote: > On Fri, Oct 22, 2010 at 9:35 AM, Sittampalam, Ganesh < > ganesh.sittampalam(a)credit-suisse.com> wrote: > >> libraries@, what's the right way to proceed? Can I make a Debian-style >> "non-maintainer upload" with minimal changes to fix urgent issues like >> these? >> > > I'd be much obliged if you could, and I do apologise for leaving all of this > just hanging. I've just done this. Thanks for the blessing. 4000.0.10 should fix the reported issue with fail and Either, and bumps the base dep to build with GHC 7.0 > No time available for Haskell projects these days unfortunately, Opera > engine development taking up most of my waking hours. Getting someone to > take over HTTP would be best, or maybe rewrite it altogether..it is not the > prettiest thing around :) I'm not particularly keen on taking over maintainership, but I guess if noone else wants it I could take it over and do at least minimal updates like this. Any other volunteers? Cheers, Ganesh

2 2

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

Merging network and network-bytestring: license question
by Johan Tibell 31 Oct '10

31 Oct '10

Hi, While looking into merging the network and network-bytestring packages, I noticed that their licenses differ slightly. I've attached both licenses in the end of this email for reference. How do I merge the two licenses? I own the copyright on network-bytestring, so I could change that license to be the same as the one used for network. Is this the right way to go? Is it possible to move the whole resulting library to the two-clause BSD license, which is more common on Hackage? Would that mean getting approval from everyone who has ever contributed to the code base? Johan ------------------------------ network license ============== The Glasgow Haskell Compiler License Copyright 2002, The University Court of the University of Glasgow. All rights reserved. Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met: - Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer. - Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution. - Neither name of the University nor the names of its contributors may be used to endorse or promote products derived from this software without specific prior written permission. THIS SOFTWARE IS PROVIDED BY THE UNIVERSITY COURT OF THE UNIVERSITY OF GLASGOW AND THE CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE UNIVERSITY COURT OF THE UNIVERSITY OF GLASGOW OR THE CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. network-bytestring license ========================= Copyright Johan Tibell 2007 All rights reserved. Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met: * Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer. * Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution. THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

8 13