June 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

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

Re: [commit: unix] master: change notes (1461d21)
by Ian Lynagh 23 Aug '13

23 Aug '13

On Fri, Feb 08, 2013 at 01:56:28PM +0000, Simon Marlow wrote: > On 03/02/13 20:48, Simon Marlow wrote: > >On 02/02/13 14:11, Ian Lynagh wrote: > >> > >>The unix version number is still 2.6.1.0, but doesn't the new policy > >>http://hackage.haskell.org/trac/ghc/wiki/Repositories#Modifyinglocalpackages > >> > >>mean that it should be bumped to 2.7.0.0 now? Actually, having just tried to do this, I'm not sure how it's meant to work in practice. Bumping unix's version requires relaxing the dependencies in Cabal and haskeline on unix. One way to do this is to get upstream to relax the dependency and updating our lagging repo. That will mean a version of the library will be uploaded to hackage with the relaxed dependency. But we don't know what the release 2.7.0.0 of unix will look like yet; perhaps by the time it is released it will not work with the current Cabal/haskeline code. The other way is to make local ghc-only changes to relax the dependencies, but that would increase the risk that we'd release with a ghc branch of the library by mistake. Wouldn't it be better to go back to the previous scheme, where we didn't update version numbers until release time? Thanks Ian

5 7

Proposal to solve the `EitherT` problem.
by Gabriel Gonzalez 15 Aug '13

15 Aug '13

As an application writer I'm a big fan of Edward's `either` package because his `EitherT` does not require an `Error` constraint. As a library writer, I am wary of heavy dependencies and I would prefer something more light-weight that I can depend on. Normally I would just directly contact Edward about reducing the number of dependencies but there was a previous discussion here about possibly merging his work into `transformers`, so I'm renewing that discussion and bringing up a few approaches for consideration. There are three approaches that I'd like to submit for consideration and receive feedback on: * Approach 1: Remove the `Error` constraint from `transformers` Disadvantage: This silently breaks all existing uses of `fail`. I don't know any way to add a compiler warning to notify downstream libraries of this change. * Approach 2: Add `EitherT` to `transformers` alongside `ErrorT` and have them both implement `MonadError`. Disadvantage: Bloat from having two almost identical monad transformers. However, there is precedent from duplicating `StateT`, `WriterT` and `RWST` for both strict and lazy instances. * Approach 3: Convince Edward to reduce the dependencies of the `either` package and submit the simplified version to the Haskell platform. Disadvantage: One extra import instead of just importing `transformers`. * Approach 4: None of the above. Disadvantage: Packages that depend on `either` have very low prospects of making it into the Haskell platform. If you have time, just take a moment to vote on which approach you favor or propose another alternative if you have another idea that I haven't listed.

17 36

Re: new-typeable, new cast?
by José Pedro Magalhães 01 Aug '13

01 Aug '13

Hi, On Mon, Mar 4, 2013 at 4:51 PM, Richard Eisenberg <eir(a)cis.upenn.edu> wrote: > Unless I'm missing something, this all looks very straightforward. The > implementation is there, already, in the guise of (gcast Refl). We would > just shuffle the definitions around a bit. Am I indeed missing something? > I think that is the case indeed. Though I agree that it would be a nice addition to Data.Typeable. Cheers, Pedro > > As for the name, I agree that :~: is awkward to type. But, I think == > should be saved for type-level Boolean equality, as a closer analogue to > its term-level meaning. I don't have a better suggestion than :~:. Or, if > we just allow Constraint/* polymorphism, than we can simply use ~, as that > *already* is a GADT wrapping around an even more primitive denotation of > equality. (Just kidding about the Constraint/* polymorphism…) > > Richard > > On Mar 4, 2013, at 10:30 AM, Simon Peyton-Jones wrote: > > > ok good. Since this is in the intersection of singletons and Typeable, I > wonder if Pedro and Richard might together lead on driving this to a > conclusion and implementing it? > > > > Simon > > > > | -----Original Message----- > > | From: Stephanie Weirich [mailto:sweirich@cis.upenn.edu] > > | Sent: 04 March 2013 14:24 > > | To: Shachaf Ben-Kiki > > | Cc: Simon Peyton-Jones; libraries(a)haskell.org; Richard Eisenberg > > | (eir(a)cis.upenn.edu) Dimitrios Vytiniotis; Iavor Diatchki; Conor > > | McBride; Pedro Magalhães > > | Subject: Re: new-typeable, new cast? > > | > > | Nice! I agree that having a (poly-kinded!) function of type > > | > > | >> eqT :: forall (a :: k) (b :: k). (Typeable a, Typeable b) => Maybe > (a > > | >> :~: b) > > | > > | around is The Right Way to Go. I'd call this function "eqT" or > > | "eqTypeable", after the similar operation in Data.Type.Equality. Thanks > > | for pointing out that we can get such a function so easily from gcast. > > | (Note that gcast itself can be polykinded now, I'm writing down the > > | kinds to make them obvious.) > > | > > | gcast :: forall (a :: k) (b::k) (c::k ->*). (Typeable a, Typeable b) -> > > | c a -> Maybe (c b) > > | > > | WRT to gcast1 and gcast2, these functions can be subsumed by eqT, but > > | not by polykinded gcast due to the restrictions on higher-order > > | polymorphism. > > | > > | gcast1 can convert [b Int] to [Maybe Int], but gcast cannot. eqT can do > > | so with a pattern match. This behavior does seem rather special-purpose > > | though---eqT is much more flexible. > > | > > | With singletons, we could imagine two different polykinded operations, > > | that differ only in whether their arguments are explicit/implicit. > > | > > | eqTypeable :: (Typeable a, Typeable b) => Maybe (a :~: b) > > | > > | eqSing :: Sing a -> Sing b -> Maybe (a :~: b) > > | > > | Again, Sing should be kind-indexed, so that we can have Sing True, Sing > > | 0, and (eventually) Sing Int. > > | > > | --Stephanie > > | > > | > > | On Mar 4, 2013, at 8:46 AM, Shachaf Ben-Kiki wrote: > > | > > | > On Mon, Mar 4, 2013 at 4:24 AM, Simon Peyton-Jones > > | > <simonpj(a)microsoft.com> wrote: > > | >> | λ> data a :~: b where Refl :: a :~: a > > | >> | λ> :t gcast Refl > > | >> | gcast Refl :: forall a b. (Typeable a, Typeable b) => Maybe > > | >> | ((:~:) * a b) > > | >> > > | >> That is a ferociously-unintuitive use of 'gcast'! It too me dome > > | while to convince myself that it was right. Though it does indeed > > | work. I'd see (gcast Refl) as the primitive, with 'gcast' itself as a > > | simple derived function. > > | >> > > | >> I'm not sure what name to give the new cast function > > | >> ?? :: Typeable a, Typeable b) => Maybe (a :~: b) > > | >> > > | >> > > | >> Do we need gcast1 and gcast2 any more, in our new polykinded world? > > | Can they be depreceated? > > | >> > > | >> Simon > > | >> > > | > > > | > A couple of people have suggested "same". (I wonder if this would > also > > | > subsume eqSingNat/eqSingSym?). > > | > > > | > By the way -- since (:~:) seems to be in HEAD now, but not yet > > | > released, is there a chance of renaming it? ":~:" is pretty awkward > to > > | > type, given all the new TypeOperators options these days; how about > > | > "=="? > > | > > > | > Shachaf > > | > > > > > > >

7 17

Proposal: Strict scanl, scanl1 and mapAccumL
by Bas van Dijk 18 Jul '13

18 Jul '13

Hi, Data.List exports strict versions of foldl an foldl1. I think it should also export these strict versions of scanl, scanl1 and mapAccumL: scanl' :: (a -> b -> a) -> a -> [b] -> [a] scanl' f q ls = q : (case ls of [] -> [] x:xs -> let q' = f q x in q' `seq` scanl f q' xs) scanl1' :: (a -> a -> a) -> [a] -> [a] scanl1' f (x:xs) = scanl' f x xs scanl1' _ [] = [] mapAccumL' :: (acc -> x -> (acc, y)) -> acc -> [x] -> (acc, [y]) mapAccumL' _ s [] = (s, []) mapAccumL' f s (x:xs) = (s'',y:ys) where (s', y ) = f s x (s'',ys) = s' `seq` mapAccumL' f s' xs Is there a good reason they're not included? Discussion deadline: 2 weeks (till Monday 26 November). Regards, Bas

9 18

A single general modification function for Map and IntMap proposal
by Nikita Volkov 15 Jul '13

15 Jul '13

There is a list of problems with the current "Map" and "IntMap" modification interfaces: - they are filled with quirky and too specialized functions - they are not consistent in terms of how equally named functions behave: http://hackage.haskell.org/packages/archive/containers/latest/doc/html/Data… - they still don't cover some important scenarios of use Because of the above I have very often found myself in requirement for the following function: withItem :: (Ord k) => k -> (Maybe i -> (r, Maybe i)) -> Map k i -> (r, Map k i) withItem k f m = let item = Map.lookup k m (r, item') = f item m' = Map.update (const item') k m in (r, m') It covers all the imaginable scenarios of modification operations: delete, update, replace, - yet it also provides one with ability to extract the modified data and not only. The problem is that this implementation involves a repeated lookup for the same item: first with "lookup", then with "update" - but the "containers" library exposes no functionality to get around that. So I suggest to implement an efficient version of "withItem" in the library. This function turns out to be far more generalized than any of the currently present in the library, so it can become a basic building block for all sorts of modifying functions, including all the already existing ones, e.g.: alter :: Ord k => (Maybe a -> Maybe a) -> k -> Map k a -> Map k a alter f k = snd . withItem k (\i -> ((), f i)) delete :: Ord k => k -> Map k a -> Map k a delete k = snd . withItem k (const ((), Nothing)) updateLookupWithKey :: (Ord k) => (k -> a -> Maybe a) -> k -> Map k a -> (Maybe a, Map k a) updateLookupWithKey f k = withItem k $ \i -> case i of Just i -> case f k i of Nothing -> (Just i, Nothing) Just i' -> (Just i', Just i') _ -> (Nothing, Nothing) You can see how easy it makes to achieve any sort of specialized functionality. So, besides the evident benefits, this function can also become a replacement for a whole list of confusing specialized ones, thus greatly lightening the library. You might have also noticed how this function is based around the standard "a -> (b, a)" pattern of the "State" monad, thus making it easily composable with it using the "state" and "runState" functions. Summarizing, my suggestions are: 1. Implement an efficient version of "withItem" for lazy and strict versions of "Map" and "IntMap". 2. Change the order of parameters from "lambda -> key" to "key -> lambda". The "updateLookupWithKey" example implementation shows how this change can be benefitial. 3. Begin the deprecation process of the following functions: insertWith, insertWithKey, insertLookupWithKey, adjust, adjustWithKey, update, updateWithKey, updateLookupWithKey, alter. A deadline for discussion is set to 6 weeks. For a formatted version of this message please visit https://github.com/haskell/containers/issues/28.

11 18