April 2012 - Libraries

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

17 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

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

14 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

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

27 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: unsnoc, unsafeInit and unsafeLast for the bytestring library
by Mikhail Vorozhtsov 29 Aug '12

29 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

Proposal: add Functor instance to Control.Exception.Handler
by Patrick Palka 04 Jul '12

04 Jul '12

A Functor instance for Handler could be useful: e.g. foo :: IO (Maybe a) handlers :: [Handler ()] foo `catches` map (Nothing <$) handlers Proposed instance definition: instance Functor Handler where fmap f (Handler h) = Handler (fmap f . h) Deadline: 2 weeks

2 2

Re: [Haskell] Types of when and unless in Control.Monad
by Ivan Lazar Miljenovic 06 Jun '12

06 Jun '12

On 22 April 2012 21:39, Christian Höner zu Siederdissen <choener(a)tbi.univie.ac.at> wrote: > * Julian Gilbey <julian(a)d-and-j.net> [22.04.2012 09:22]: >> On Sat, Apr 21, 2012 at 08:28:27PM -0500, Strake wrote: >> > On 21/04/2012, Andreas Abel <andreas.abel(a)ifi.lmu.de> wrote: >> > > to avoid silly "return ()" statements like in >> > > >> > > when cond $ do >> > > monadicComputationWhoseResultIWantToDiscard >> > > return () >> > >> > (when cond ∘ void) monadicComputationWhoseResultIWantToDiscard >> > or >> > when cond $ () <$ monadicComputationWhoseResultIWantToDiscard >> >> How is that simpler than >> >> when cond monadicComputationWhoseResultIWantToDiscard >> >> which it would be with the suggested new type? >> >> Julian > > Wouldn't "when_" and "unless_" or similar be better? I'd probably like > to have the compiler annoy me, since it is not clear that I want to > discard the result. If I really want to discard, I should have to make > it clear as there is probably a good reason for the inner function to > return a result in the first place? Agreed; I'm not sure if I agree with having such functionality (Henning makes some good points), but if people deem it desirable then I think it would be better to have them with new names for the reasons you state. -- Ivan Lazar Miljenovic Ivan.Miljenovic(a)gmail.com http://IvanMiljenovic.wordpress.com

4 7

Intersect by and union documentation in base
by Bram Neijt 28 May '12

28 May '12

Dear library maintainers, I've used both intersectBy and unionBy from the Base.List module. For intersectBy the documentation did not mention which element will be used when an element is in both lists. The attached patch adds a line to the documentation of intersectBy, where I think it makes sense to add this information. The unionBy documentaiton has the same kind of problem, however I did not patch that because I'm not sure whether this is part of the contract union whats to take on (I mean being deterministic in which list is the preferred source of elements). Please consider updating the documentation and feel free to contact me for more information if needed. Greetings, Bram

2 1

Proposal: unify constant functors
by wren ng thornton 08 May '12

08 May '12

Hello all, I recently (re)noticed the following duplication: base:Control.Applicative newtype Const a b = Const { getConst :: a } instance Functor (Const m) where... instance Monoid m => Applicative (Const m) where... transformers:Data.Functor.Constant newtype Constant a b = Constant { getConstant :: a } instance Functor (Constant a) where... instance Foldable (Constant a) where... instance Traversable (Constant a) where... instance (Monoid a) => Applicative (Constant a) where... I don't see any reason for this redundancy. I propose we: (1) add the Foldable and Traversable instances to base, and (2) deprecate transformers:Data.Functor.Constant This will cause breakage to any orphan instances of Foldable/Traversable for Const, but that seems fine by me. Eventually we'll want to remove transformers:Data.Functor.Constant (or have it re-export the Const stuff from base:Control.Applicative); but that can be handled later. Deadline: 14 May 2012. -- Live well, ~wren

13 22

Should folds in containers package remain INLINE
by Milan Straka 08 May '12

08 May '12

Hi all, this came up when discussing increasing size of GHC binary. Currently all folds in containers package are marked as INLINE. This has following effects: 1) the code using folds can be (much) more efficient -- for example, when calling statically known function. If the unfolding of that function is available, GHC can spot strictness and unbox values -- so `foldl (+) (0::Int)` evaluated the sum strictly and without allocating space for intermediate Ints. 2) the resulting binary size increases. If the folds in containers package are not INLINEd, the stripped GHC binary shrinks by 303kB, which is 0.8% of its size. Therefore we have speed vs. code size trade-off. FYI, Prelude.foldr is always inlined, Prelude.foldl is inlined only when GHC thinks it is worth it. Simon Marlow suggested that folds could be marked INLINABLE. Then they would probably not be inlined automatically, but one could say inline foldr to inline the fold on the call sites she chooses. Personally I am a bit in favor of keeping the folds INLINE. That allows the users of containers to get best performance without any change to the code (i.e., adding explicit `inline`). The price to pay is code size increase, which I consider minor (0.8% for GHC binary). Any other thoughts? Cheers, Milan

7 12

haskeline should also work with new mt-2.1.1
by Christian Maeder 29 Apr '12

29 Apr '12

Hi, trying to install haskeline together with other packages using cabal-install-0.14.0 resulted in a failure due to a too restrictive constraint. > cabal install mtl haskeline --dry-run Resolving dependencies... In order, the following would be installed (use -v for more details): haskeline-0.4 # because mtl-2.1.1 is already installed This installation of haskeline-0.4 fails! > cabal install transformers haskeline --dry-run Resolving dependencies... In order, the following would be installed (use -v for more details): mtl-1.1.1.1 haskeline-0.6.4.6 # transformers-0.3.0.0 is already installed > cabal install haskeline --dry-run Resolving dependencies... In order, the following would be installed (use -v for more details): transformers-0.2.2.0 mtl-2.0.1.0 haskeline-0.6.4.6 Cheers Christian

2 1