- Libraries - Haskell.org

Bumping package version numbers in the HP (Was: Haskell Platform Proposal: add transformers and revise the mtl package to depend on it)
by Johan Tibell 08 Nov '10

08 Nov '10

Hi all, On Tue, Nov 2, 2010 at 2:47 PM, Ross Paterson <ross(a)soi.city.ac.uk> wrote: > The ones that depend on mtl are: > > cgi-3001.1.7.3 (latest version 3001.1.8.1) > fgl-5.4.2.3 > QuickCheck-2.1.1.1 (latest version 2.3.0.2) > regex-base-0.93.2 > regex-compat-0.93.1 > regex-posix-0.94.2 > HTTP-4000.0.9 (latest version 4000.0.10) How do we decide whether to include new versions of packages in the next HP release. For bugfix releases it should be a no-brainer, just include them. What about API additions? Didn't we chose to not use a new version of some package because it added a bunch of modules in the Data.* namespace? As you see above two packages have increased the minor version number (cgi and HTTP) and one has increased the major version number (QuickCheck). In addition to the above three packages, the network package recently grew two new modules (adopted from network-bytestring). Johan

3 2

Status update: HP 2011.x and GHC 7
by Don Stewart 08 Nov '10

08 Nov '10

I have built a very early candidate for the Haskell Platform 2011 set, ignoring any active proposals, using GHC 7. Issues that were raised: = Haskell Platform packages that have broken the HP policy, by adding new dependencies that are not part of the Haskell Platform set: * cgi (known issue) + adds MonadCatchIO-mtl (12 packages use it) dependency. + last compliant version 3001.1.7.4 * GLUT (known issue) + adds StateVar -any (9 packages use it), Tensor -any (4 packages use it) + last compliant version 2.1.2.1 * OpenGL (known issue) + adds OpenGLRaw >=1.1.0.0 (6 users) GLURaw >=1.1.0.0, (1 user) StateVar -any, (9 users) ObjectName -any, (2 users) Tensor -any (4 users) + last compliant version 2.2.3.0 = Haskell Platform packages that will break with GHC 7, because base 3 has gone away: * haskell src-1.0.1.3 ++ libraries will have to fix this = Other inconsistencies with currently released packages: * time 1.2.0.3 was excluded because cabal-install-0.8.2 requires time ==1.1.* ++ assuming new cabal-install release soon? * haddock 0.8.1 is out, but ghc 7 RC is shipping with haddock 0.8.0 * stm 2.2.0.1 uses throwSTM, which wasn't in the release candidate.

4 4

Summary and call for discussion on text proposal
by Duncan Coutts 08 Nov '10

08 Nov '10

Thomas and I would like to summarise the current point of contention in the text library proposal with the aim of resolving the issue and getting the package accepted. It seems clear that we all want the package accepted, the disagreement is over details of the API. The problem here is not the amount of work to make the changes some people have been suggesting, the problem is disagreement over whether change is necessary and if so what change. There is essentially just one point of contention, over about 10 out of the 80+ functions in the Data.Text module. The issue is about which functions should get the nice names and about consistency between modules. (There is one other minor issue that Ross raised but we will deal with the most substantive issue first) There are two axes in which Text functions are generalised: * character predicate (e.g. searching for first char matching a predicate) * substring (e.g. searching for a substring) These are orthogonal directions of generalisation. There is no simple way to encompass both (regular expressions are not simple, naive generalisations cannot be implemented efficiently). The fact that there are these two forms of most functions is different from the List library which only has the element predicate direction, not the sub-sequence direction. This is the prelude to the problem, because the List library has already taken the common names for the character predicate versions. The design of the Text library encourages the use of substring operations because these are expected to be more commonly used and because correct handling of Unicode often requires substring operations (due to issues with combining characters). There are a number of options. To illustrate them let us pick an example function that breaks a text into two. There are two versions: * break based on a character predicate * break based on a substring Option 1 (current Text lib design) ---------------------------------- break :: Text -> Text -> (Text, Text) breakBy :: (Char -> Bool) -> Text -> (Text, Text) This gives the short name 'break' to the substring version, and the longer name 'breakBy' to the character predicate version. The argument for doing this is that the substring version should be the common encouraged one and so it should get the nice name. The argument against is that this is inconsistent with the List library which gives the name 'break' to the element predicate version: break :: (a -> Bool) -> [a] -> ([a], [a]) Option 2 -------- breakSubstring :: Text -> Text -> (Text, Text) break :: (Char -> Bool) -> Text -> (Text, Text) This gives the short name 'break' to the character predicate version and the longer 'breakSubstring' to the substring version. The argument for doing this is that it is consistent with the List library in its use of the name 'break'. The argument against is that the short name is now given to the version that is discouraged, and the version that is encouraged now has a very long and ugly name: this API is encouraging users to make the wrong choices. Decisions --------- There appears to be no consensus over which of these two options to pick. If this situation persists then the default position is for the package not to be accepted at all. We think there is consensus that the package should go into the platform in some form -- that the worst of all the options is for the package not to go in a all. We are now at the third stage of the consensus protocol. At this stage discussion should be limited to resolving one concern at a time. Anyone may contribute to this discussion. The people required to take part are the proposal author (Don) and anyone who has concerns with the package going in as is. People with concerns should restate those concerns and if necessary questions should be asked to clarify the concerns. In particular, if the summary above is not an accurate expression of peoples concerns then they should say so. Don will update the wiki proposal page with the details of the remaining concerns (or simply the summary above if this is accurate). The steering committee (in this case Thomas and I) will follow the discussion. If we are still stuck in one week (14th Nov) then the steering committee will re-evaluate the situation. To kick off the discussion focused on this narrow issue, Thomas and I would like to suggest a 3rd alternative option: Option 3 -------- breakStr :: Text -> Text -> (Text, Text) breakChr :: (Char -> Bool) -> Text -> (Text, Text) This give neither version the short name 'break', but gives both reasonably short names with a suffix to indicate the character predicate vs substring. This addresses the complaint that a name from the List library is being used but with an inconsistent type (because the name is not being used at all). It removes the problem that the character predicate versions are being promoted over the substring versions by the use of the shorter names. It makes explicit the fact that all the functions come in two forms, whereas with List there is just one form. There is still a strong connection with the List library by using the same root names. So people can still carry over their experience of the List library API to help them find the right Text functions. They will have to make one choice between the character predicate and substring versions, which is reasonable given that the substring versions are preferred. Duncan & Thomas (with their platform steering committee hats on)

19 31

Definition of emptiness for SampleVar
by Simon Hengel 08 Nov '10

08 Nov '10

Hello, I'm somewhat confused about the definition of emptiness for SampleVar: A sample var is /empty/ if it contains no value _and_ if there are no blocked readers[1]. With this definition, the following program prints `False': import Control.Concurrent main = do var <- newEmptySampleVar forkIO $ readSampleVar var threadDelay 1000000 isEmptySampleVar var >>= print Is this intended behavior? And if yes, what is the rational behind this? If this is intended behavior, I'd tend to clarify the documentation? Something like: Returns True if the SampleVar is currently empty and if there are no readers waiting. Any thoughts on that? Cheers, Simon [1] http://hackage.haskell.org/packages/archive/base/4.1.0.0/doc/html/src/Contr…

1 0

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 call for consensus: add 'text' package
by Don Stewart 07 Nov '10

07 Nov '10

Hello! This is a call for consensus for the following proposal: http://trac.haskell.org/haskell-platform/wiki/Proposals/text Are there any unresolved concerns? Deadline: 2 weeks (Nov 21) -- Don P.S. the steps in the process for adding a package are: * described here: http://trac.haskell.org/haskell-platform/wiki/AddingPackages#Consensus * timetable for 'text' here: http://trac.haskell.org/haskell-platform/ticket/145 P.P.S.: work is happening at BelHac to fix the status of the trac wiki on the community server, which is rather flakey.

4 9

Re: Haskell Platform decision: time to bless parsec 3?
by Isaac Dupree 07 Nov '10

07 Nov '10

On 11/06/10 11:53, Dmitry Astapov wrote: > One one hand, parsec 3 is more versatile, on the other hand, parsec 2 is > often faster. Is this even since parsec 3.1, whose main claim to fame was making parsec3 performance be comparable to parsec2 performance? http://www.haskell.org/pipermail/haskell-cafe/2010-March/074076.html -Isaac

1 0

Entering the consensus call period: reminder on process
by Don Stewart 06 Nov '10

06 Nov '10

Hey all, Just a reminder from your friendly Haskell Platform infrastructure team: we are now entering the "call for consensus" period for the current round of Haskell Platform changes. What consensus is, and how we achieve it, is described here: * http://trac.haskell.org/haskell-platform/wiki/AddingPackages#Consensus As a reminder, the key points are: * People who participate in the review process for a package are expected to participate in the call for consensus. * Each time there is a call for consensus, everyone has three options: + Say nothing. This indicates you're prepared to accept the current proposal. + Stand aside. An email to say that you do have unresolved concerns but you are prepared to see the proposal accepted to further community goals. + Raise objection. Objections need accompanying reasoning so that others can try to work with that reasoning to find a resolution to the issue. And remember, **our goal is to give the greatest benefit to the community, not to achieve perfection.** Once we've done a few of these, I expect libraries@ to become quite efficient: just keep the goals of the Haskell Platform, and the Haskell community in mind. ------------------------------------------------------------------------ The discussion period (Stage 1) extended from September 1 through November 1, which ends with the consensus calls. The two proposals under consideration (our very first additions to the HP in 2 years of work! ... ) are: text * http://trac.haskell.org/haskell-platform/ticket/145 mtl * http://trac.haskell.org/haskell-platform/ticket/152 The mtl proposal has officially entered the consensus phase now, text will follow shortly. All discussion should be finalized by Dec 15 at the latest, after which the package set is frozen for the January release. -- Don

1 0

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