July 2012 - Libraries

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

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

Proposal: refactor Arrow class
by Ross Paterson 09 Jan '13

09 Jan '13

I propose to refactor the Arrow class, so that GHC's arrow notation can be a bit more general. (The module Control.Arrow itself would remain standard Haskell.) Please comment by 12th August. In detail, the proposal is to change the Arrow class from class Category a => Arrow a where arr :: (b -> c) -> a b c first :: a b c -> a (b,d) (c,d) -- various functions made methods to allow efficient specializations by introducing a new class -- | A binary type constructor that is contravariant in its first argument, -- that is, -- -- * @'premap' id a = a@ -- -- * @'premap' (f . g) a = 'premap' g ('premap' f a)@ -- class PreArrow a where premap :: (b -> b') -> a b' c -> a b c with instances instance PreArrow (->) where premap f g = g . f instance PreArrow (Kleisli m) where premap f (Kleisli g) = Kleisli (g . f) and redefining the Arrow class as class (Category a, PreArrow a) => Arrow a where arr :: (b -> c) -> a b c arr f = premap f id first :: a b c -> a (b,d) (c,d) -- rest unchanged The proposed PreArrow class has more instances than Arrow, in particular composing a PreArrow with a Functor yields another PreArrow. The principal client for the new class would be the arrow notation, as implemented in GHC. With this class, there would be a simple rule for determining which instances are needed, based on the keywords used: * all commands ("proc" and operator arguments) need PreArrow * "do" needs Arrow * "rec" needs ArrowLoop * "case" or "if" need ArrowChoice One might object that the second argument of the PreArrow class is superfluous, and this is just a complicated Contravariant class. That is true, and in semantic terms a covariant functor would be sufficient, but Haskell's type system makes it impossible to have commonality between a Contravariant class of unary type constructors and the Arrow class used by arrow notation.

6 16

Changes to Typeable
by Simon Peyton-Jones 26 Nov '12

26 Nov '12

Friends (Ian pointed out that I should have sent this to the libraries list): The page describes an improved implementation of the Typeable class, making use of polymorphic kinds. Technically it is straightforward, but it represents a non-backward-compatible change to a widely used library, so we need to make a plan for the transition. http://hackage.haskell.org/trac/ghc/wiki/GhcKinds/PolyTypeable Comments? You can fix typos or add issues directly in the wiki page, or discuss by email Simon

25 54

Proposal: Remove Control.Concurrent{QSem,QSemN,,SampleVar,mergeIO,nmergeIO} from base
by Ian Lynagh 12 Nov '12

12 Nov '12

Hi all, I propose that we remove Control.Concurrent.QSem Control.Concurrent.QSemN Control.Concurrent.SampleVar Control.Concurrent.mergeIO Control.Concurrent.nmergeIO from base. Rationale: There is no real need for them to be in base, and they are not being well-maintained there (e.g. see [3160]). Chris Kuklewicz has already made a SafeSemaphore package that provides fixed versions of the 3 modules. Patch is attached (but basically it just removes the above). Suggested discussion deadline: Fri 22 June 2012. [3160] http://hackage.haskell.org/trac/ghc/ticket/3160 Thanks Ian

15 22

Haskell Platform proposal: Add the vector package
by Johan Tibell 08 Oct '12

08 Oct '12

Hi, I am, with Roman's support, making a formal proposal to have the vector package included in the Haskell Platform: http://trac.haskell.org/haskell-platform/wiki/Proposals/vector See the wiki page for details, and a list of open issues for discussion. The vector package itself can be found on Hackage: http://hackage.haskell.org/package/vector I have set the deadline to 13 August 2012 (~2 months' time), with comments due by 13 July 2012 (~one month). There's plenty of time before the next platform release anyway (scheduled for 12 November 2012). -- Johan

16 82

Proposal: unsnoc, unsafeInit and unsafeLast for the bytestring library
by Mikhail Vorozhtsov 28 Aug '12

28 Aug '12

Hi. I propose to add the missing counterparts of `uncons` and `unsafeHead/Tail` functions to the bytestring library. Discussion deadline: 2 weeks The patch is attached.

5 10

Re: safe vs. unsafe (Was: Haskell Platform proposal: Add the vector package)
by Simon Marlow 30 Jul '12

30 Jul '12

On 13/07/2012 01:31, Bardur Arantsson wrote: > On 07/12/2012 11:16 PM, Simon Marlow wrote: >> Hi Thomas, >> >> All these questions are answered by the Haskell Symposium paper, which >> we'll post very shortly. > > THANK YOU! This discussion has been ridiculuously abstract and confusing > without any real (canonical) definition of the terms that are being > bandied about. Here it is: http://community.haskell.org/~simonmar/papers/safe-haskell.pdf Cheers, Simon

2 2

Proposal: Add the missing instances for Traversable (Either b) and Traversable ((,) b)
by Edward Kmett 29 Jul '12

29 Jul '12

The following instances are missing and have only one sensible definition. I've been bitten by their lack repeatedly and there is no place outside of base that they can live without needlessly being orphaned. I would like to propose adding the following instances to Data.Foldable and Data.Traversable. instance Foldable (Either e) where foldMap f (Right m) = f m foldMap _ (Left _) = mempty instance Traversable (Either e) where traverse _ (Left e) = pure (Left e) traverse f (Right x) = Right <$> f x instance Foldable ((,) e) where foldMap f (_,x) = f x instance Traversable ((,) e) where traverse f (e ,x) = (,) e <$> f x I had thought honestly thought we'd already added them long ago. Discussion Period: 2 Weeks -Edward Kmett On Tue, Jan 3, 2012 at 7:50 PM, Ben Millwood <haskell(a)benmachine.co.uk>wrote: > Yeah, I noticed this the other day, and a couple of other instances > which aren't defined, but could be: > > http://hpaste.org/56005 > > I won't pretend I have much use for the Const instance, but it seems > like it should be there anyway, just for completeness (I think it's > possible to define Traversable instances for compositions of functors, > possibly sums and products as well, so Const could be useful in that > context). I think the Either one makes sense, though, as a natural > analogue of the Maybe instance. > > On Tue, Jan 3, 2012 at 11:41 PM, Conal Elliott <conal(a)conal.net> wrote: > > Thanks much for the answers, Conor. They all make sense to me, > particularly > > about the typical information discarding in Foldable. > > > > Regards, - Conal > > > > > > On Tue, Jan 3, 2012 at 3:30 PM, Conor McBride < > conor(a)strictlypositive.org> > > wrote: > >> > >> > >> On 3 Jan 2012, at 23:12, Conal Elliott wrote: > >> > >>> I wanted a Traversable instance for pairing, so I defined one: > >>> > instance Traversable ((,) o) where > >>> > sequenceA (o,fa) = (o,) <$> fa > >> > >> > >> That looks right. Of course, we should really have a BiTraversable > >> class of which (,) is an instance. > >> > >> > >>> > >>> However, Foldable is a superclass of Traversable, so I get an error > >>> message: > >>> > >>> Could not deduce (Foldable ((,) o)) from the context () > >>> arising from the superclasses of an instance declaration > >>> > >>> The best I've thought of is the following: > >>> > >>> > instance Foldable ((,) o) where > >>> > fold (_,m) = m > >> > >> > >> The best (upto efficiency considerations) is always > >> > >> > >> instance Foldable ((,) o) where > >> foldMap = foldMapDefault > >> > >> which amounts to what you chose. > >> > >> SHE makes this a default superclass instance. > >> > >> > >>> However, I don't like how it discards information. > >> > >> > >> But these folds always do discard information, discarding the shape > >> information and accumulating over the contents. For ((,) o), seen as > >> a functor, the first component is shape information and the second is > >> the content. > >> > >> > >>> Some questions: > >>> > >>> * Why is Foldable a superclass of Traversable? > >> > >> > >> Because the constant-monoid Applicative makes every Traversable > >> Foldable in a uniform way. > >> > >> > >>> * Is there a good choice of a Foldable instance of ((,) o)? > >> > >> > >> Yes, the one you chose. > >> > >> > >>> * Are there any other problems with the Traversable instance above > >>> (besides foldability)? > >> > >> > >> Nope. It's the Traversable instance which picks out exactly the > >> contents that correspond to the elements abstracted by the Functor. > >> > >> All the best > >> > >> Conor > >> > > > > > > _______________________________________________ > > Libraries mailing list > > Libraries(a)haskell.org > > http://www.haskell.org/mailman/listinfo/libraries > > > > _______________________________________________ > Libraries mailing list > Libraries(a)haskell.org > http://www.haskell.org/mailman/listinfo/libraries >

4 4