February 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

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

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: 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

PolyKinds, Control.Category and GHC 7.6.1
by Edward Kmett 30 May '13

30 May '13

Would it be possible to add something like {-# LANGUAGE CPP #-} #if defined(__GLASGOW_HASKELL__) && __GLASGOW_HASKELL__ >= 704 {-# LANGUAGE PolyKinds #-} #endif to the top of Control.Category before the 7.6.1 final release? Control.Category.Category is pretty much the only type in base that directly benefits from PolyKinds without any code changes, but without enabling the extension there nobody can define categories for kinds other than *, and most interesting categories actually have more exotic kinds. I only noticed that it wasn't there in the release candidate just now. -Edward Kmett

5 11

Proxy and new-typeable
by Shachaf Ben-Kiki 19 Apr '13

19 Apr '13

I see that the new-typeable branch in GHC is using "typeRep :: forall a. Typeable a => Proxy a -> TypeRep" rather than "typeOf :: forall a. Typeable a => a -> TypeRep". This is clearly a big improvement over using undefined everywhere. I'd like to suggest a small change, if it hasn't been brought up before -- "typeRep :: forall proxy a. Typeable a => proxy a -> TypeRep". This makes typeRep compatible with any other Proxy type, since it doesn't use any properties of the concrete type -- it just uses it to pass information about the "a". Things that consume a Proxy don't ever need to refer to Proxy explicitly. This would make Typeable compatible with other Proxy libraries, like the one in "tagged". It would also make it compatible with any other type of kind * -> * -- for example, "typeRep ([] :: [Int])" would be a valid, and arguable more convenient, syntax for using typeRep. "Nothing :: Maybe Int" and so on would work too. So things that produce a "proxy" don't need to refer to Proxy explicitly either. Possibly this would make the Proxy type entirely unnecessary. If it stays, though, I suggest that it belongs in a module other than Data.Typeable.Internal -- it's a useful type for many other things, and as long as it's in base and exposed to users, it might as well be treated as a type in its own right. It's also a monad, can provide a variant of `asTypeOf`, and so on. Shachaf

7 24

instance Applicative Data.Map
by Henning Thielemann 17 Mar '13

17 Mar '13

An ZipList-like Applicative instance for Data.Map would be nice. I have an application where I like to write liftA3 f amap bmap cmap meaning Map.intersectionWith ($) (Map.intersectionWith f amap bmap) cmap But I cannot complete the instance implementation because there is no sensible definition for 'pure' for Data.Map. :-(

14 31

A more useful Monoid instance for Data.Map
by Daniel Peebles 13 Mar '13

13 Mar '13

Hi all, Currently Data.Map has a Monoid instance, but it's rather lossy and not as general as it could be: instance (Ord k) => Monoid (Map k v) where mempty = empty mappend = union mconcat = unions The instance would be much nicer if it required a Monoid on v and used unionWith mappend instead of just union. The current behavior could be emulated by using First/Last as the Monoid (or ideally a semigroup, but that's or another discussion), but other more interesting Monoid instances could also be used for the values. I realize that changing instances could break code, but I'd be curious to see how many people even use the current monoid instance. Does anyone have any system for testing hypotheses like this (by typechecking a large randomized chunk of hackage or something)? It looks like the idea has been around for at least five years: http://hackage.haskell.org/trac/ghc/ticket/1460 but the proposal was abandoned, so I wanted to see if I could get people to start talking about it again. Thanks, Dan

13 29

Can we move bytestring to github?
by Bryan O'Sullivan 07 Mar '13

07 Mar '13

Hi, Duncan - The subject says it all. I'd like to contribute some patches to bytestring, but darcs is a big wall at this point, and the package has no bug tracker. I'd like to move it under http://github.com/haskell, a place that has served several of our core packages well. I know you're fond of darcs, but it's well established by experience that we'll get many more contributions (both patches and problem reports) on github. So... pretty pretty please.

16 25