January 2015 - Libraries

Proposal: removeDirectoryRecursive should not follow symlinks
by Edward Z. Yang 09 Jan '15

09 Jan '15

Discussion period: one month I propose to backwards incompatibly change the behavior of removeDirectoryRecursive to not follow symlinks. We could optionally add a replacement function under a new name which does follow symlinks. This would bring its behavior inline with rm -rf. I also opened a ticket here: https://ghc.haskell.org/trac/ghc/ticket/9266 Thanks, Edward

26 51

Version of the pretty-printing library in GHC 7.10.1
by Andrés Sicard-Ramírez 09 Jan '15

09 Jan '15

Hi, While preparing Agda for supporting GHC 7.10.1, I found the following situation: * In GHC 7.8.4, the version of the pretty library is 1.1.1.1. * In GHC 7.10.1 RC1, the version of the pretty library is 1.1.1.3. * I need to use conditional compilation when using GHC 7.10.1 RC1 because in the version 1.1.1.2 of the pretty library was added a new Eq instance which is currently defined in the Agda source code. * I cannot use the Cabal macro MIN_VERSION_package_(A,B,C) because this macro only supports three components (A, B, C) in the version number, and the change in the version of the pretty library was in the fourth component, i.e. 1.1.1.1 -> 1.1.1.2. (I could use the symbol __GLASGOW_HASKELL__ instead, but I don't want to use this symbol for changes related to the libraries.) Is going GHC 7.10.1 to be released with a version of the pretty library where I can use the MIN_VERSION_package_(A,B,C) macro? Best, -- Andrés

2 1

Discussion: Can we make evaluate easier to find?
by David Feuer 09 Jan '15

09 Jan '15

The evaluate function is defined in GHC.IO, and exported publicly by Control.Exception. This strikes me as an extremely strange place for it. Can we find another place to put it that would seem more sensible? I don't think it should be removed from Control.Exception, but rather that maybe it should be added somewhere else as well. Digging all around, I've come up with one idea that might work, if we give evaluate a more general type: evaluate :: PrimMonad m => a -> m a evaluate a = primitive (\s -> seq# a s) With this type, we could easily put it in Control.Monad.Primitive. There may be some challenges wiggling module dependencies around, but hopefully not huge ones. David

4 8

Adding Read instances for HList
by David Feuer 08 Jan '15

08 Jan '15

One option looks something like the code below. Another option would mirror the current Show instances by pushing "H[" back onto the state each time an item is parsed (I don't think that's a particularly clean approach, but it's an option). {-# LANGUAGE DataKinds ,KindSignatures ,FlexibleContexts ,FlexibleInstances ,TypeOperators ,GADTs ,ScopedTypeVariables #-} module MyHList where import GHC.Read import Text.ParserCombinators.ReadPrec import qualified Text.Read.Lex as L -- This declaration is copied from `Data.HList.HList`. data HList (l::[*]) where HNil :: HList '[] HCons :: e -> HList l -> HList (e ': l) infixr 2 `HCons` instance Read (HList '[]) where readPrec = parens ( do expectP (L.Ident "H") expectP (L.Punc "[") expectP (L.Punc "]") return HNil ) instance forall e . Read e => Read (HList (e ': '[])) where readPrec = parens ( do expectP (L.Ident "H") expectP (L.Punc "[") e <- reset $ (readPrec::ReadPrec e) expectP (L.Punc "]") return (e `HCons` HNil) ) instance forall e f (l::[*]) . (Read e, ReadTl (HList (f ': l))) => Read (HList (e ': f ': l)) where readPrec = parens ( do expectP (L.Ident "H") expectP (L.Punc "[") e <- reset $ (readPrec::ReadPrec e) expectP (L.Punc ",") rest <- readTl :: ReadPrec (HList (f ': l)) return (e `HCons` rest) ) class ReadTl l where readTl :: ReadPrec l instance forall e . Read e => ReadTl (HList (e ': '[])) where {-# INLINE readTl #-} readTl = do e <- reset $ (readPrec::ReadPrec e) expectP (L.Punc "]") return $ e `HCons` HNil instance forall e f (l::[*]) . (Read e, ReadTl (HList (f ': l))) => ReadTl (HList (e ': f ': l)) where {-# INLINE readTl #-} readTl = do e <- reset $ (readPrec::ReadPrec e) expectP (L.Punc ",") rest <- readTl return (e `HCons` rest)

1 0

Proposal: generalize evaluate
by David Feuer 07 Jan '15

07 Jan '15

Apparently, there was an issue with my last messages about this for some people, so here's the idea again: We could generalize Control.Exception.evaluate to evaluate :: PrimMonad m => a -> m a evaluate a = primitive (\s -> seq# a s) and then export it from Control.Monad.Primitive as well, which seems to me a much more natural place for it. The only challenge is that the PrimMonad class would need to be moved to base.

2 2

Upgrade MaybeT to AMP, and otherwise clean it up
by David Feuer 04 Jan '15

04 Jan '15

http://stackoverflow.com/questions/22750315/applicative-instance-for-maybet… noted that instance (Functor m, Monad m) => Applicative (MaybeT m) instance (Functor m, Monad m) => Alternative (MaybeT m) is not exactly ideal. An answer to the question explained why MaybeT isn't really so important for Applicative, but that doesn't seem to be a good reason to leave the status quo in place. If I'm not very much mistaken, there are two issues: 1. The Functor constraint is never used, and of course every valid monad is also a valid functor with fmap=liftM. So for pre-AMP base, the signatures should have had only a Monad constraint, and not a Functor one. 2. For AMP, the constraints should be changed to require Applicative instead of Monad.

2 3

replace definition of error with errorWithStackTrace
by Carter Schonwald 03 Jan '15

03 Jan '15

http://hackage.haskell.org/package/base-4.7.0.1/docs/GHC-Stack.html#v:error… has been in GHC for for >=1 major version, and for normal builds, acts just like error, BUT, when an error is thrown in a profiled build, it appends a stack trace with some basic source location data to the end of the error message! I think this change would benefit many! My current understanding is that the DWARF based approach to stack traces wont make it into GHC 7.10 , and while this variant would only provide extra info in profiling builds (and strictly less than the dwarf work), its something that can definitely be done in a single small patch that could easily be swapped out for that improved approach once it lands. discussion period: 2 weeks unless theres a clear unanimous agreement to make the change ASAP, OR if the stack trace error stuff is landing in 7.10 and I'm misinformed! cheers -Carter

11 19

change of strictness in zipWith
by Henning Thielemann 02 Jan '15

02 Jan '15

$ ghci-7.8.4 -Wall Prelude> zipWith (==) "" undefined [] $ ghci-7.10.0.20141227 -Wall Prelude> zipWith (==) "" undefined *** Exception: Prelude.undefined I found the difference because my mapAdjacent function uses 'tail' in the second argument of 'zipWith': mapAdjacent :: (a -> a -> b) -> [a] -> [b] mapAdjacent f xs = zipWith f xs (tail xs) I get: $ ghci-7.10.0.20141227 -Wall *Prelude> Data.List.HT.mapAdjacent (==) ([] :: [Int]) *** Exception: Prelude.tail: empty list

3 5

Proposal: improve the Data.Tree API
by João Cristóvão 01 Jan '15

01 Jan '15

Hello, The Data.Tree API seems rather poor. Some research on hackage shows some additional functions being defined in very unrelated packages: http://hackage.haskell.org/package/debian-3.81/docs/Debian-Apt-Dependencies… http://hackage.haskell.org/package/hledger-lib-0.22.1/docs/Hledger-Utils.ht… I propose the addition of the following functions, that seem rather straigh forward to me: -- | get the sub-tree rooted at the first (left-most, depth-first) occurrence -- of the specified node value lookupTree :: Eq a => a -> Tree a -> Maybe (Tree a) -- | get the sub-tree rooted at the first (left-most, depth-first) value that -- matches the provided condition findTree :: (a -> Bool) -> Tree a -> Maybe (Tree a) -- | keep only the elements that match the provided condition filter :: (a -> Bool) -> Tree a -> Tree a The 'Tree' is appended in the name, to distinguish from the Foldable instances, that return the value, and not a sub-tree. Additionally, the following two functions might also be useful (even if the implementation is very simple in the second case): -- | get the sub-tree for the specified node value in the first tree in -- forest in which it occurs. lookupTreeInForest :: Eq a => a -> [Tree a] -> Maybe (Tree a) -- | Length of the tree length :: Tree a -> Int There are probably more useful functions to add, so suggestions are welcomed. Previous discussion: https://github.com/haskell/containers/issues/39#issuecomment-35799628 Discussion period: 2 weeks Cheers, João

12 35