November 2010 - Libraries

Re: Functor => Pointed => Applicative => Monad
by John Lato 04 Dec '10

04 Dec '10

> > From: David Menendez <dave(a)zednenem.com> > Subject: Re: Functor => Pointed => Applicative => Monad > To: Isaac Dupree <ml(a)isaac.cedarswampstudios.org> > Cc: libraries(a)haskell.org > Message-ID: > <AANLkTinkqQXYTN6ATqGawbdeVvtfq_6z51sADN8i_O8P(a)mail.gmail.com> > Content-Type: text/plain; charset=ISO-8859-1 > > On Mon, Nov 29, 2010 at 11:26 AM, Isaac Dupree > <ml(a)isaac.cedarswampstudios.org> wrote: > > On 11/29/10 03:39, John Smith wrote: > >> > >> Is there any intention to reorganise the standard class hierarchy, > >> arranging them logically instead of in order of invention? I plagiarised > >> the following example from > >> http://stackoverflow.com/questions/1634911/can-liftm-differ-from-lifta > >> and Trac: > >> > >> class Functor f where > >> map :: (a -> b) -> f a -> f b > >> > >> class Functor f => Pointed f where > >> pure :: a -> f a > > > > Is it useful to have Pointed non-Functors? > > Is Pointed useful at all? The last time this discussion came up, I > asked for algorithms which were generic over pointed functors (in the > same way that traverse is generic over applicative functors) and no > one could think of any. > It's useful for 'singleton' on probabilistic data structures (e.g. a Bloom filter). John

7 10

RFC: Adding a Hashable type class and HashMap/HashSet data types to HP
by Johan Tibell 02 Dec '10

02 Dec '10

Hi all, This is a request for early feedback on something that I'd like to propose for the next major HP release. Milan Straka showed [1] that it's possible to design a persistent set (and thus also map) for string-like keys that's about twice as fast as the current Data.Set using hashing and a Patricia tree (i.e. IntMap). The Clojure community has also managed to create a fast persistent map, based on Bagwell's hash array mapped trie. I'd like to propose that we get the necessary infrastructure in place for creating fast and easy to use hash-based data structure. Here's what I think is needed: * A type class for things that can be hashed, Hashable. class Hashable a where hash :: a -> Word An alternative would be to have `hash` return an Int, which would make the method easier to use with Haskell data structures, which are indexed using Ints, but Word feels like the more correct type to me. The Hashable type class would have to go in either base, containers, or a new package (there's currently a hashable package on Hackage.) * Instances of Hashable for common types, in particular ByteString and Text. I already have fast instances for Text and ByteString, based on MurmurHash2 [2]. * Two new data types in the containers package, Data.HashMap and Data.HashSet. These would be persistent data structures, initially based on IntMap, and have the same or similar API to Data.Map and Data.Set.. In the future we could also add mutable HashTables, operating in the ST monad, or other hash-based data types (persistent or mutable). Any comments? Johan 1. http://research.microsoft.com/~simonpj/papers/containers/containers.pdf 2. http://sites.google.com/site/murmurhash/

14 31

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

Re: [Gtk2hs-devel] move Gtk2HsSetup.hs to gtk2hs-buildtools
by Axel Simon 30 Nov '10

30 Nov '10

Dear Libraries, this message is on shortcomings of cabal with respect to automatically installing the gtk package which (a) depends on a package that contains only build tools (i.e. only binaries) and (b) has a big custom Haskell file Gtk2HsSetup.hs that Setup.hs has to import (and which is required in any package in the Gtk2Hs suite). This file is copied into every package of the Gtk2Hs suite which is a pain to maintain. On 25.11.2010, at 10:50, Lazycat Manatee wrote: > ---------- Forwarded message ---------- > From: Jens Petersen <petersen(a)haskell.org> > Date: 2010/11/25 > Subject: Re: [Gtk2hs-devel] move Gtk2HsSetup.hs to gtk2hs-buildtools > To: Andy Stewart <lazycat.manatee(a)gmail.com> > > >> Jens Petersen <petersen(a)haskell.org> writes: >> >>> I suggest moving Gtk2HsSetup.hs into a library, it could be part >>> of gtk2hs-buildtools perhaps. How about it? >> It can't work. >> >> Because we need Gtk2HsSetup.hs generate Signals.chs and Types.chs >> *before* >> any cabal depend check. > > Hmm I haven't tested but don't really understand. > You mean it will break builds with cabal-install? > Doesn't gtk2hs-buildtools already do that? :) > Yes, but these are two separate show-stoppers: a) the gtk2hs-buildtools contains only binaries. It does not register as a package with ghc. Thus, if we make the gtk package depend on gtk2hs-buildtools, cabal would complain that (even after installing gtk2hs-buildtools) the gtk2hs-buildtools library is not there b) putting Gtk2HsSetup.hs in either gtk2hs-buildtools or any other library means that ./Setup.hs has to run to realize that this library is missing and that it needs to be downloaded. However, ./Setup.hs cannot be run because it imports Gtk2HsSetup.hs which is not yet available. I don't know if (b) can be solved by e.g. conditionally importing Gtk2HsSetup.hs if it is there and only installing libraries and re- invoking Setup.hs one this is done. This is a common trick in Makefiles, e.g. one could call make recursively to first build dependencies. Any suggestions welcome. Regards, Axel

4 5

Versions of bracket without masking acquire action
by Mitar 30 Nov '10

30 Nov '10

Hi! With new mask/restore concept it is impossible to unblock exceptions in acquire action which is quite often useful (acquire can be a lengthily action). So it could be a good idea to introduce a variant which has acquire action unmasked. http://hackage.haskell.org/trac/ghc/ticket/4810 Mitar

1 0

ANNOUNCE: iteratee-compress 0.1.2
by Maciej Piechotka 28 Nov '10

28 Nov '10

Iteratee-compress provides compressing and decompressing enumerators including flushing. Currently only gzip is provided but at bzip and LZMA are planned. This is bug-fixing release Changes from previous version: - Fix infinite loop/segfault bug - Fix bug in which part of the output was lost - Support for iteratee 0.5 and 0.6 Next goals: - BZip support - LZMA support - Generic interface for flushing To think about: - Should inner iteratee be able to request flushing? Regards

1 1

ANNOUNCE: iteratee-compress 0.1.2
by Maciej Piechotka 28 Nov '10

28 Nov '10

Iteratee-compress provides compressing and decompressing enumerators including flushing. Currently only gzip is provided but at bzip and LZMA are planned. This is bug-fixing release Changes from previous version: - Fix infinite loop/segfault bug - Fix bug in which part of the output was lost Next goals: - BZip support - LZMA support - Generic interface for flushing To think about: - Should inner iteratee be able to request flushing? Regards

1 0

Re: RFC: Adding a Hashable type class and HashMap/HashSet data types to HP
by wren ng thornton 27 Nov '10

27 Nov '10

On 11/24/10 11:41 AM, Duncan Coutts wrote: > On 22 November 2010 01:19, wren ng thornton wrote: >> +1. Especially given the recent trend towards breaking things out of base, >> moving this in is suspect. As folks have been moving towards base-4 we've >> been able to finally start getting rid of the slew of Cabal flags for >> figuring out when base does or does not include various libraries. Don't >> start inventing new ones :) > > It's not a simple question of "put stuff in base" vs "take stuff out > of base" one has to look at what it is that it makes sense to put in / > take out. The things we have been removing from base have mainly been > independent implementations of things, not standard interfaces. There > is a pretty reasonable argument that standard interfaces -- especially > type classes -- should go in base, while almost all implementation do > not need to be. Right. My implication was that the module in question doesn't seem like the kind of thing that should go in base. Generally used classes (sans implementations) tend toward moving into base because having the class sans implementation in its own package is cumbersome[1], and having the class with its implementations introduces unnecessary dependencies. However, that doesn't mean that all widely used classes should move into base. For instance, consider the popular library Foo which defines a FooClass; because Foo is widely used, FooClass will be too, but if Foo is a graphics library or some other domain-specific thing, then FooClass may not have the kind of generality that's appropriate for base classes. While the idea of hashing is certainly general enough, I don't know that this particular class definition of the idea is.[2] Compare against the current development of classes for randomly generating values. The base class is problematic, as has been known for some time, but the new classes aren't settled in stone yet either. Not to mention that QuickCheck, SmallCheck, etc have classes with similar goals of constructing values "out of nothing" but whose goal is very different than the statistically random generation of types like Int or Double. I anticipate similar issues happening with hashing a few years down the road once people have played around with the hashable/hashmap packages more, and therefore do not think it should be included in base. [1] Though not necessarily a bad idea. If each independent family of classes were in their own package, then we could give those families version numbers of their own instead of trying to remember which version of base/quickcheck/... added or removed some particular method. This, on the whole, strikes me as a good idea since it puts the version numbers where they belong and makes it clearer for using CPP to conditionalize parts of the implementation. Unfortunately, it's a heavyweight solution and cabal doesn't seem like quite the right tool to be tracking this sort of thing. [2] Things like groups, fields, etc have well-defined interfaces and so it's easy to see whether they are complete and appropriate or not (ignoring debates about whether the algebraic classes are the right generalizations to be used). Even things like a class for monad transformers are defined almost entirely based on the types that things must have. But hashing doesn't have the same kind of well-defined structure as either of these. -- Live well, ~wren

1 0

HP 2011 alpha
by Don Stewart 26 Nov '10

26 Nov '10

Test build with the following changes appears to be consistent, using GHC 7 RC2: HTTP 4000.0.9 -> 4000.1.0 HUnit 1.2.2.1 -> 1.2.2.3 QuickCheck 2.1.1.1 -> 2.4.0.1 cgi 3001.1.7.3 -> 3001.1.7.4 deepseq 1.1.0.0 -> 1.1.0.2 haskell-src 1.0.1.3 -> 1.0.1.4 mtl 1.1.0.2 -> 2.0.1.0 #### network 2.2.1.7 -> 2.3 parallel 2.2.0.1 -> 3.1.0.1 parsec 2.1.0.1 -> 3.1.0 #### regex-posix 0.94.2 -> 0.94.4 text Added: 0.10.0.0 transformers Added: 0.2.2.0

4 4

an update on the text package proposal and a call for consensus
by Duncan Coutts 24 Nov '10

24 Nov '10

All, Following the recent discussions about some details in the text package we have had a revision to the proposal. I am confident that we will now be able to achieve a consensus on the last issue of contention and thus we will be able to accept the package as a whole for the next HP release. This email is to summarise the issue, to detail the proposed resolution and to call for consensus on accepting the text package into the Haskell platform. Summary ------- Out of around 90 functions in the Data.Text module, a number of people had concerns about the names and types of 10 of them. In particular the concern was about whether names and types should match between the standard List module and other "list like" modules such as Text (but other examples include ByteString etc). Some functions in the Text API that involve selecting a location in a Text (e.g. to break it at that point). Some of these functions come in two variants: * one based on searching for a character satisfying a predicate * one based on searching for a substring In the standard List module there are only equivalents for the first variant. Taking the example of the functions that break a text into two, in the original proposal the two variants were named as: break :: Text -> Text -> (Text, Text) breakBy :: (Char -> Bool) -> Text -> (Text, Text) This gave 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 short 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]) Updated proposal ---------------- The updated proposal accepts the point that the names should be consistent with the List library. The substring versions are given new names with a suffix to distinguish them. In the break example the two variants are now: breakOn :: Text -> Text -> (Text, Text) break :: (Char -> Bool) -> Text -> (Text, Text) The full set of names and types that have changed are as follows The substring functions are now named with the 'On' suffix: breakOn :: Text -> Text -> (Text, Text) breakOnEnd :: Text -> Text -> (Text, Text) breakOnAll :: Text -> Text -> [(Text, Text)] splitOn :: Text -> Text -> [Text] The character predicate functions now match the List names: break :: (Char -> Bool) -> Text -> (Text, Text) span :: (Char -> Bool) -> Text -> (Text, Text) partition :: (Char -> Bool) -> Text -> (Text, Text) find :: (Char -> Bool) -> Text -> Maybe Char split :: (Char -> Bool) -> Text -> [Text] Minor function -------------- One last function that some people raised minor concerns about is the function count :: Text -> Text -> Int This function is not in the List library. It was added to the ByteString library with the type BS.count :: Word8 -> ByteString -> Int The suggestion from some reviewers was that the type be equivalent between ByteString and Text. The current text proposal leaves the count function as it is. If the consensus is that these functions should have equivalent types then my proposal (as a maintainer of the bytestring package) is that we should generalise the type of the count function in the bytestring package. Feel free to comment on this issue. On a procedural note, I see no problem with including a change to the bytestring package into this proposal for the text package. Call for consensus ------------------ http://trac.haskell.org/haskell-platform/wiki/AddingPackages#Consensus Are there any unresolved concerns? If not then the text package will be accepted with the changes outlined above. Duncan (with his Haskell Platform Steering Committee hat on)

2 3