August 2013 - Libraries

Proposal: merge either into transformers
by Roman Cheplyaka 03 Jan '17

03 Jan '17

I propose to add the sole module of the 'either' package[1], Control.Monad.Trans.Either, to the transformers package. It provides EitherT, a very basic and fundamental data type. The difference between EitherT and ErrorT is that the latter has an Error constraint, which is used to imlement 'fail'. Note that 'either' depends on the 'semigroupoids' and 'semigroup' packages to provide appropriate instances. The proposal is not to add those instances to 'transformers' to avoid additional dependencies. The instances can then be left in the 'either' package or moved to the 'semigroupoids' and 'semigroup' packages respectively. ('semigroupoids' already depends on 'transformers', while 'semigroups' does not). Compared to the 'either' package, Show, Read, Eq and Ord instances will be dropped to keep the code Haskell2010 (those instances require FlexibleInstances, FlexibleContexts, and UndecidableInstances). The patch is attached. [*] [*] against transformers-0.3.0.0, because the darcs version is not buildable (Control/Monad/Signatures.hs is not in the repository). Roman

22 72

Proposal: Use time rather than old-time in directory
by Ian Lynagh 16 Sep '14

16 Sep '14

Hi all, This proposal is to change directory to use the time package rather than the old-time package. This will hopefully be a significant step towards actually making the transition in general. I'm not sure if POSIXTime or UTCTime is the better type to use. Does anyone know? I started off with UTCTime, then switched to POSIXTime as UTCTime didn't have a Show instance. I've since found that actually UTCTime has both Show and Read instances, but they are orphaned. So actually, if UTCTime is the better type then switching back to UTCTime would allow us to fix this comment in hpc: -- We would rather use ClockTime in Mix, but ClockTime has no Read instance and simplify the code slightly. Attached are patches for directory, hpc and ghc. Suggested discussion period: Until 5th Nov 2011. Thanks Ian

14 35

Proposal: Add Data.Semigroup to base, as a superclass of Monoid
by John Wiegley 11 Aug '14

11 Aug '14

1. I propose that we add the following package to base: http://hackage.haskell.org/packages/archive/semigroups/0.9.2/doc/html/Data-… This is somewhat in the spirit of the AMP proposal: further improving the correctness of our algebraic abstractions. 2. That we make Semigroup a superclass of Monoid, so that (minimally): class Semigroup a where (<>) :: a -> a -> a class Semigroup a => Monoid a where mempty :: a mconcat :: [a] -> a mconcat = foldr (<>) mempty mappend :: Semigroup a => a -> a -> a mappend = (<>) 3. (Optional, recommended) There are other useful functions that can be added to Semigroup, such as sconcat and times1p, but I will let Edward speak to whether those should be proposed at this time. 4. (Optional, recommended) That we fix the Monoid instance for Maybe to be: instance Semigroup a => Semigroup (Maybe a) where Just x <> Just y = Just (x <> y) _ <> _ = Nothing instance Semigroup a => Monoid (Maybe a) where mempty = Nothing For some clarification on what semigroups are and why we'd want to change Monoid, I excerpt here a selection from Brent Yorgey's "Monoids and Variations" paper: Semigroups A semigroup is like a monoid without the requirement of an identity element: it consists simply of a set with an associative binary operation.... Of course, any monoid is automatically a semigroup (by forgetting about its identity element). In the other direction, to turn a semigroup into a monoid, simply add a new distinguished element to serve as the identity, and extend the definition of the binary operation appropriately. This creates an identity element by definition, and it is not hard to see that it preserves associativity.... Adding a new distinguished element to a type is typically accomplished by wrapping it in Maybe. One might therefore expect to turn an instance of Semigroup into an instance of Monoid by wrapping it in Maybe. Sadly, Data.Monoid does not define semigroups, and has a Monoid instance for Maybe which requires a Monoid constraint on its argument type... This is somewhat odd: in essence, it ignores the identity element of [the type] and replaces it with a different one. -- John Wiegley FP Complete Haskell tools, training and consulting http://fpcomplete.com johnw on #haskell/irc.freenode.net

9 9

Re: Proposal: Add hasBitSize to Data.Bits.Bits
by John Lato 19 Sep '13

19 Sep '13

> From: Edward Kmett <ekmett(a)gmail.com> > > On Fri, Jul 27, 2012 at 3:42 PM, Ian Lynagh <igloo(a)earth.li> wrote: > >> On Fri, Jul 27, 2012 at 03:06:04PM -0400, Edward Kmett wrote: >> > There is currently no way to know whether or not calling >> > Data.Bits.bitSizewill crash your program. >> > >> > I propose extending the Bits class to include: >> > >> > hasBitSize :: Bits b => b -> Bool >> > >> > such that it returns False for Integer and True for the other instances > > Would it be better to move bitSize into a separate class? > > > I don't think so. Ultimately, you should be able to know for every numeric > type if it has a fixed or variable number of bits. In a perfect world 'd > rather just have bitSize return a Maybe that way we don't have to truck > with partial functions in the API. > > However, the case for just adding hasBitSize is that it avoids breaking > existing code. Given that existing code using bitSize can already cause a crash when used with Integer or other infinite types, wouldn't it be better to break existing code so authors can fix (or at least examine) their use of bitSize? I'm in favor of changing the type of bitSize, although since none of my code uses that function it's an easy position for me to take. John L.

13 40

Proposal: infixr 9 `Compose`
by Bas van Dijk 13 Sep '13

13 Sep '13

I was just bitten by the fact that the type constructor Compose from Data.Functor.Compose associates to the left instead of to the right like function composition. I would like to propose adding the following to Data.Functor.Compose: infixr 9 `Compose` -- analogous to the fixity of (.) This will likely break existing code which uses Compose infix like in the following type: a `Compose` b `Compose` c Discussion deadline: 13 September 2013. Bas

2 5

Data instance for Data.Version
by David Lazar 13 Sep '13

13 Sep '13

Hi, Can we derive Data for Data.Version.Version? It would benefit Cabal. Thanks, David

4 4

Proposal: Improving the IsString String instance
by Edward Kmett 09 Sep '13

09 Sep '13

I've been chewing on this one for a long time, and finally decided to post it after being bitten by it *again*. Right now we have a very fragile instance in base for instance IsString String where fromString = id This is fragile because once you turn on OverloadedStrings length "hello" won't work any more, because all it knows is that it has a [a] such that it needs an IsString [a] instance, but it can't use defaulting to select the [Char] instance we've defined, and so you have to burden it with a type annotation. >>> :set -XOverloadedStrings >>> length "hello" <interactive>:3:8: No instance for (Data.String.IsString [a0]) arising from the literal `"hello"' The type variable `a0' is ambiguous Possible fix: add a type signature that fixes these type variable(s) Note: there is a potential instance available: instance Data.String.IsString [Char] -- Defined in `Data.String' Possible fix: add an instance declaration for (Data.String.IsString [a0]) In the first argument of `length', namely `"hello"' In the expression: length "hello" In an equation for `it': it = length "hello" I would like to replace this instance with instance a ~ Char => IsString [a] where fromString = id This will make OverloadedStrings work much better with the list-specific combinators, reducing the number of type annotations required by users who hack on, say, web-apps in Haskell where both OverloadedStrings is a common extension and, frankly, the users are often the least equipped to deal with and understand the issue. The cost of this instance is that someone else can't come along and make an instance of IsString for another 'character-like' type and get the String-like behavior with magic list interoperability without some kind of wrapper. However, I've yet to see any such instances, and I'd likely look down my nose at such an instance in the first place. ;) The current pain is real and the space of instances affected seems both largely theoretical and a bad idea to begin with. The instance is already guarded from use by NHC by an #ifdef, which limits objections on portability grounds. Discussion Period: 2 Weeks

24 49

Pointed and Traversable
by Henning Thielemann 30 Aug '13

30 Aug '13

There was a lot of discussion about separating "pure" from Applicative and putting it into a Pointed class. If I remember correctly, the main counter argument was that 'pure' alone does not satisfy interesting laws. There are only such laws in connection with the Applicative class. Now, in some situations I liked to have a generalized unfoldr. I can build this from "pure" and "sequenceA" using the State monad: unfoldr :: (Pointed t, Traversable t) => (s -> (a, s)) -> s -> t a unfoldr = evalState . sequenceA . pure . state One could state a law like: traverse f (pure a) == traverse id (pure (f a)) Would this justify to move "pure" into a new Pointed class?

5 4

Fwd: Re: Pointed and Traversable
by Petr Pudlák 30 Aug '13

30 Aug '13

I forgot to add "libraries" as a recipient, so I'm forwarding the mail. PP -------- Pu*vodní zpráva -------- Pr(edme(t: Re: Pointed and Traversable Datum: Fri, 30 Aug 2013 16:59:45 +0200 Od: Petr Pudlák <petr.mvd(a)gmail.com> Komu: Edward Kmett <ekmett(a)gmail.com> Kopie: Henning Thielemann <schlepptop(a)henning-thielemann.de>, Frantisek Farka <ffarka(a)gmail.com> Dne 08/26/2013 10:26 PM, Edward Kmett napsal(a): > I can't speak well to SHE's implementation but there are a few > tensions in the design space of how to handle default superclass > instances in a language like Haskell that makes them not perfectly > solve the issue that Haskell generally sucks at dealing with deep > accurate typeclass hierarchies. > > 1.) When you have a complex lattice of types rather than a linear > chain, you're going to get a lot of ways to derive the common default > functionality. > > class Functor f => Applicative f > gives one way to automatically define fmap > > class Functor f => Traversable f > gives another way to define fmap for free > > class Functor f => Comonad f > gives a third way to define fmap for free > > In general when you have a lattice of properties points above you in > the lattice will start getting an exploding number of definitions from > classes below them, leading to limited utility for any 'hiding' based > mechanism as you've traded n definitions for n hiding declarations. True, that's an important issue to solve, I'll have to think about it. One idea that emerges is to borrow some concepts from OOP/Java and to distinguish "interface"-like type classes that have no defaults (just the ones we have now) and "class"-like type classes that can have defaults. And "class"-like could "descend" only from at most one other "class"-like type class. (This is perhaps somewhat similar to http://repetae.net/recent/out/classalias.html, which distinguishes classes from class aliases.) > > 2.) As typeclass hierarchies become deeper with more refined notions, > say, Functor, Semiapplicative, Semimonad, Pointed, Applicative, Monad > (note the last 2 only have laws with no methods in the perfect world), > you wind up being able to get fewer default/mutual definitions to work > at any individual level of the hierarchy. > > 3) Product-like constructions, monad transformers, etc. still need > definitions for every point in the typeclass lattice. Since almost all > of my code is polymorphic in this style, it turns out I almost never > get to use the instances that would be supplied by a default > superclass system. Could you please give an example? You mean that if let's say we introduce Applicative => Monad with the default superclass system, you'd still have to refactor your code? > > I generally favor the notion of adding default definitions for > superclass methods and adding 'default instances', I just think it is > necessary to point out that it doesn't help nearly as much as everyone > thinks it will, when it comes to the pains induced by retroactively > adding a finer grained inheritance hierarchy. > > Culturally, it is a hard sell to the average Haskeller to get them to > embrace a class that doesn't give them any new methods, so we wind up > with an awkward culture that favors a few powerful abstractions over > the full menagerie of accurate types. I'd say it depends how it's presented. The main selling point for adding fine grained hierarchy is that more things get a common type class. Like we could say we don't need Functors or Applicatives because most of them are Monads anyway, but still people agree that Functors are useful and needed. So I think the main objection of the average Haskeller is that introducing a new type class breaks (his) stuff. If we can find a mechanism how to avoid that, I'd say (s)he wouldn't mind (perhaps even care). Best regards, Petr > > -Edward > > > > On Mon, Aug 26, 2013 at 2:18 PM, Petr Pudlák <petr.mvd(a)gmail.com > <mailto:petr.mvd@gmail.com>> wrote: > > One of our students is currently exploring how to extend Haskell > so that splitting classes into more fine-grained hierarchy won't > cause these problems: > https://groups.google.com/forum/#!topic/haskell-cafe/W1NbrikzgCQ > <https://groups.google.com/forum/#%21topic/haskell-cafe/W1NbrikzgCQ> > along the lines of > http://ghc.haskell.org/trac/ghc/wiki/DefaultSuperclassInstances > Unfortunately, it seems his message went unnoticed by Haskell > community. > > Best regards, > Petr Pudlak > > Dne 08/26/2013 07:16 PM, Edward Kmett napsal(a): >> There are several uses of Pointed as a separate beast from >> Applicative. In particular it comes up when we talk about "affine >> traversals", and would let us refine the type hierarchy of lens, >> so you'd think I'd be for it. >> >> However, to move it into its own class would require literally >> everyone who currently has an Applicative instance to clutter >> their code with CPPs. >> >> Even as the author of the Pointed class, I personally find that >> the benefit of the change doesn't warrant the impact of the change. >> >> -Edward >> >> >> On Mon, Aug 26, 2013 at 12:59 PM, Henning Thielemann >> <schlepptop(a)henning-thielemann.de >> <mailto:schlepptop@henning-thielemann.de>> wrote: >> >> There was a lot of discussion about separating "pure" from >> Applicative and putting it into a Pointed class. If I >> remember correctly, the main counter argument was that 'pure' >> alone does not satisfy interesting laws. There are only such >> laws in connection with the Applicative class. >> >> Now, in some situations I liked to have a generalized >> unfoldr. I can build this from "pure" and "sequenceA" using >> the State monad: >> >> unfoldr :: (Pointed t, Traversable t) => (s -> (a, s)) -> s >> -> t a >> unfoldr = evalState . sequenceA . pure . state >> >> One could state a law like: >> >> traverse f (pure a) == traverse id (pure (f a)) >> >> Would this justify to move "pure" into a new Pointed class? >> >> _______________________________________________ >> Libraries mailing list >> Libraries(a)haskell.org <mailto:Libraries@haskell.org> >> http://www.haskell.org/mailman/listinfo/libraries >> >> >> >> >> _______________________________________________ >> Libraries mailing list >> Libraries(a)haskell.org <mailto:Libraries@haskell.org> >> http://www.haskell.org/mailman/listinfo/libraries > >

1 0

sequence causing stack overflow on pretty small lists
by Niklas Hambüchen 28 Aug '13

28 Aug '13

On #haskell we recently had a discussion about the following: import System.Random list <- replicateM 1000000 randomIO :: IO [Int] I would think that this gives us a list of a million random Ints. In fact, this is what happens in ghci. But with ghc we get: Stack space overflow: current size 8388608 bytes. Use `+RTS -Ksize -RTS' to increase it. This is because sequence is implemented as sequence (m:ms) = do x <- m xs <- sequence ms return (x:xs) and uses stack space when used on some [IO a]. >From a theoretical side, this is an implementation detail. From the software engineering side this disastrous because the code is * obviously correct by itself * the first thing people would come up with * not exaggerating: a million elements is not much * used a lot of places: mapM, replicateM are *everywhere* and yet it will kill our programs, crash our airplanes, and give no helpful information where the problem occurred. Effectively, sequence is a partial function. (Note: We are not trying to obtain a lazy list of random numbers, use any kind of streaming or the likes. We want the list in memory and use it.) We noticed that this problem did not happen if sequence were implemented with a difference list. What do you think about this? Should we "fix" functions like this, probably trading off a small performance hit, or accept that idiomatic Haskell code can crash at any time?

8 10