November 2010 - Libraries

Re: Data.Functor module naming?
by Louis Wasserman 08 Nov '10

08 Nov '10

The Functor type class generalizes Applicative and Monad, but it also generalizes Foldable and Traversable, which are in Data.Foldable and Data.Traversable. Since some Applicative functors are also "data" (as opposed to operators), like the list functor, it seems like a reasonable compromise to put it in Data.Functor. Louis Wasserman wasserman.louis(a)gmail.com http://profiles.google.com/wasserman.louis

1 0

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