December 2014 - Libraries

Merge either into transformers
by Yitzchak Gale 29 Dec '14

29 Dec '14

Roman Cheplyaka wrote in February 2014: >> I proposed to merge either into transformers more than a year ago[1], >> and everyone seemed to agree. Could you please do it? >> >> [1]: http://www.haskell.org/pipermail/libraries/2012-December/019027.html Ross Paterson responded: > Not everyone agreed when we discussed this last August. My proposal then > was to introduce a new constructor ExceptT on the same pattern as ReaderT, > etc, and to deprecate ErrorT, and that's what I intend to include in the > next major release, after GHC 7.8 comes out. First of all, GHC 7.8 is well past. Now we are well into the 7.10 zone. I re-read the original thread and did not find anyone who disagreed with this, so I'm not sure what you mean by that. I also didn't find any mention of ExceptT there. The discussion was about merging the either library into transformers as is, with the bits that are problematic due to non-base dependencies written out by hand where possible or else omitted. That said, I think everyone will support you, without bikeshedding, if you decide to change any of the names and/or deprecate ErrorT. Thanks, Yitz

4 5

Proposal: add intersperse and intercalate to Data.Sequence
by David Feuer 28 Dec '14

28 Dec '14

It seems there's enough interest to make it official. The usual two-week period begins now. Intersperse can be given very pleasant performance characteristics for sequences: the result can constructed incrementally as it is consumed. Intercalate cannot perform so pleasantly, but it seems odd to add one but not the other.

3 4

Resurrecting yarr
by Dominic Steinitz 27 Dec '14

27 Dec '14

I am trying to resurrect the yarr package (https://hackage.haskell.org/package/yarr) Thanks to all the very helpful folk in the Haskell community it now compiles under 7.8.3 and the tests run apart from > ~/Dropbox/Private/yarr/tests $ ./canny 1 50 100 tree.png > luminosity 8.41 ms, 5.33 tics per index > canny: Oops! Entered absent arg $dVector1{v a6vi} [lid] Vector{tc rrL} > (VecList{tc rrR} (S{tc ruZ} Z{tc ruI})) > (VecList{tc rrR} > (S{tc ruZ} > (S{tc ruZ} (S{tc ruZ} (S{tc ruZ} (S{tc ruZ} Z{tc ruI}))))) > (Word{(w) tc 32R} > -> Word{(w) tc 32R} -> IO{tc 32I} Word{(w) tc 32R})) > canny: thread blocked indefinitely in an MVar operation Now according to the notes left by the original developer, this used to work under ghc 7.6.1. What is this message telling me? Let me know if I should provide more information. Many thanks Dominic Steinitz dominic(a)steinitz.org http://idontgetoutmuch.wordpress.com

1 2

GHC 7.10.x migration guide
by Herbert Valerio Riedel 27 Dec '14

27 Dec '14

Hello! I've started collecting the most common compile-errors (and their respective fixes) I have encountered while compiling Hackage packages with GHC 7.10 in https://ghc.haskell.org/trac/ghc/wiki/Migration/7.10 Feel free to contribute to this migration guide. HTH, hvr

1 0

Fwd: Latest Template Haskell Breaks Package
by Dominic Steinitz 25 Dec '14

25 Dec '14

I realise I should have sent this to the libraries list. Dominic Steinitz dominic(a)steinitz.org http://idontgetoutmuch.wordpress.com Begin forwarded message: > From: Dominic Steinitz <dominic(a)steinitz.org> > Subject: Latest Template Haskell Breaks Package > Date: 23 December 2014 13:14:26 GMT > To: Haskell-Cafe <haskell-cafe(a)haskell.org> > > Hello Fellow Haskellers, > > I have become a maintainer for yarr (https://hackage.haskell.org/package/yarr) This no longer compiles with ghc-7.8.3 because it specifies base == 4.6. Relaxing this to base >=4.6 && <4.8 tells me I need a newer version of Template Haskell > >> rejecting: template-haskell-2.7.0.0, 2.6.0.0, 2.5.0.0, 2.4.0.1, 2.4.0.0, >> 2.3.0.1, 2.3.0.0, 2.2.0.0 (conflict: yarr => template-haskell>=2.8 && <2.9) > > If I now relax the constraint for Template Haskell I get a compiler error as there has been a breaking change from Template Haskell 2.9 to 2.10. > >> Data/Yarr/Utils/FixedVector/VecTuple.hs:45:16: >> Couldn't match expected type ‘TypeQ -> Q Dec’ >> with actual type ‘Q Dec’ >> The function ‘tySynInstD’ is applied to three arguments, >> but its type ‘Name -> TySynEqnQ -> DecQ’ has only two > > And indeed looking at the changes in http://git.haskell.org/packages/template-haskell.git/commitdiff/ccd7891c536… I can see that the function in question has changed. > >> -tySynInstD :: Name -> [TypeQ] -> TypeQ -> DecQ >> -tySynInstD tc tys rhs = >> +tySynInstD :: Name -> [TySynEqnQ] -> DecQ >> +tySynInstD tc eqns = > > Did I miss some announcement of this breaking change and the advice on what to do about it? > > If I did can someone please point me at the relevant document. If not then I feel sad and would be very grateful if someone could help me as I know very little about Template Haskell. > > Many thanks > > Dominic Steinitz > dominic(a)steinitz.org > http://idontgetoutmuch.wordpress.com >

5 16

Proposal: (a -> Bool) -> a -> f a
by Nikita Volkov 24 Dec '14

24 Dec '14

I propose to add the following utility function into Control.Applicative: cond :: (Alternative f) => (a -> Bool) -> a -> f a cond p a = if p a then pure a else empty Following is a typical use case: \x -> fromMaybe 0 $ cond (> 0) $ x - 10 which is the same as \x -> let y = x - 10 in if y > 0 then y else 0 Why the first one is better: 1. The control flow is evident and goes from right to left step by step. It’s not scattered around like in the second example. 2. No need to interrupt to imagine a name for a temporary variable. 3. Less noise. Now, since it’s generalised to Alternative one can imagine tons of other useful cases for this. Alternative titles: - conditional - partial Best regards, Nikita

7 7

GHC 7.10.1 / cabal-install 1.22 Ubuntu-PPA pre-RC snapshots available!
by Herbert Valerio Riedel 23 Dec '14

23 Dec '14

To early adopters & multi-ghc-travis users, I've uploaded pre-RC snapshots for GHC 7.10.1 and cabal-install 1.22 to my GHC PPA[1], so you can start extending your .travis.yml files w/ CABALVER=1.22 GHCVER=7.10.1 There are no official RCs yet for GHC 7.10/cabal-install 1.22, these are merely snapshots from the respective Git branches which I'll keep updating regularly (every 1-3 days) till the final proper release for GHC 7.10.1 and cabal-install 1.22.0.0 occur, at which point those packages (`ghc-7.10-*` & `cabal-install-1.22`) will install the final release versions. The usual official release-candidates (including respective announcements) for GHC & cabal will follow soon. So please, help us finding issues/bugs with these pre-RC snapshots of GHC & cabal-install. Obviously, it's desirable to become aware of any serious issues ASAP, as opposed to shortly before the planned final release date... As these are Git snapshots, when reporting bugs/issues, please also provide the snapshot's Git commit id (which uniquely identifies the GHC source-tree state), which can be queried via a new GHC CLI option, e.g.: $ ghc --print-project-git-commit-id a8c556dfca3eca5277615cc2bf9d6c8f1f143c9a Here's an example build using 7.10.1 to show those packages actually work: https://travis-ci.org/haskell/unix/builds/44919992 [1]: https://github.com/hvr/multi-ghc-travis https://launchpad.net/~hvr/+archive/ubuntu/ghc Cheers, hvr PS: If you happen to run into compile errors for Hackage packages which claim to work with GHC 7.10.1 (e.g. by allowing `base-4.8`), I'd be interested to hear about it.

1 0

Discussion: Strict maps
by David Feuer 23 Dec '14

23 Dec '14

The containers package has Data.Map.Strict and Data.IntMap.Strict, offering functions for handling maps that are strict in the values stored. But these modules are lies, as comments in the source explain: -- API of this module is strict in the keys, but lazy in the values. -- If you need value-strict maps, use "Data.Map.Strict" instead. -- The 'Map' type itself is shared between the lazy and strict modules, -- meaning that the same 'Map' value can be passed to functions in -- both modules (although that is rarely needed). -- Be aware that the 'Functor', 'Traversable' and 'Data' instances -- are the same as for the "Data.Map.Lazy" module, so if they are used -- on strict maps, the resulting maps will be lazy. Yuck. This is not nice. Clearly, the current interfaces need to stay around for compatibility, but I think we should add some unbroken ones too. There are two and a half sane ways to do this: 1. Make strict types that just wrap the lazy ones in newtype wrappers. The benefits: a) They can reuse all the code from Data.Map.Strict or Data.IntMap.Strict, producing tiny little wrapper modules. b) They can support cheap strictToLazy and unsafeLazyToStrict operations (newtype unwrappers/wrappers). c) They support lazyToStrict operations with no significant new code (reusing the NFData code). 2. Make entirely separate strict types. The benefits: a) The code implementing them does not have to be careful to force everything as it goes in, so the strictness is maintained automatically; changes to the code don't need careful strictness auditing. b) Values only need to be forced on insertion, and GHC should be able to recognize that returned values will have been forced. This should speed things up when lookups are common and updates are rare. c) There may (I'm not sure) be more opportunities for GHC to unbox values when their types are known. 2.5. Do both of the above.

4 6

bind :: Monad m => (a -> m b) -> m a -> m b
by Christopher Done 16 Dec '14

16 Dec '14

Is this defined anywhere in base, and if not could it be placed in Control.Monad? I often find myself writing: fmap (mu bar) (foo zot) Then I decide to change the type of x, so instead I want to just write: bind (mu bar) (foo zot) Which is just like fmap but the function can run in the monad. Similar to traverse: (Traversable t, Applicative f) => (a -> f b) -> t a -> f (t b) As someone who isn’t a fan of operators, I generally am appreciative of alternative regular plain English word versions of functions, which I find easier to type, read and edit. Currently without defining such a handy name, I have to transform the code to this: mu bar =<<foo zot The name for this function is a no-brainer: bind :: Monad m => (a -> m b) -> m a -> m bbind = (=<<) For comparison, the not-very-pleasant <$> and <*> each have word alternatives, fmap and ap. Even <> has mappend. I don’t hold much hope for this, Haskellers love operators as much as Perl programmers so few on this list will see the value in plain old words, but at least I can link to this email in the archives for future reference. Ciao

20 35

getDirectoryContents without special directories "." and ".."
by Henning Thielemann 13 Dec '14

13 Dec '14

Whenever I call System.Directory.getDirectoryContents, the first thing I do is to filter out "." and "..". Is there a portable and simple way to do this? I even think that "." and ".." should not be part of the result at all, but that's a different discussion.

3 4