March 2015 - Libraries

Missing instances for Eq1 (Const a), Ord1 (Const a), Show1 (Const a), Ord1 (Const a)
by Edward Kmett 08 Mar '15

08 Mar '15

I was looking at switching a chunk of my code over from prelude-extras to transformers 0.5, but the classes in http://hackage.haskell.org/package/transformers-0.4.2.0/docs/Data-Functor-C… are currently missing instances for Control.Applicative.Const. =/ -Edward

2 1

Re: ApplicativeZip
by Oleg Grenrus 08 Mar '15

08 Mar '15

After thinking for a while (and looking onto MonadZip [] instance), I realised that: `MonadZip []` is the same as `Applicative ZIpList`, not `Applicative []` I guess that answers my question. Also Information preservation law: liftM (const ()) ma = liftM (const ()) mb excludes the default implementation of munzip for non-deterministic computations, as the information is “multiplied". The naturality law follows from Applicative laws. — After some thinking (and re-reading the "Monadic zipping (used for monad comprehensions)” comment in the documentation), this is obvious. But I’ll try to make a documentation improvement patch, so no-one have to wonder this that much again. - Oleg > On 06 Mar 2015, at 10:30, David Feuer <david.feuer(a)gmail.com> wrote: > > It was already discussed, I think, but I don't remember the conclusion! > > On Mar 6, 2015 3:27 AM, "Oleg Grenrus" <oleg.grenrus(a)iki.fi> wrote: > After Edward Kmett mentioned that we should add MonadZip to Data.Monoid instances, that got me thinking about: > > Why we don’t have ApplicativeZip? > > class Applicative f => ApplicativeZip f where > {-# MINIMAL azip | azipWith #-} > azip :: m a -> m b -> m (a,b) > azip = azipWith (,) > > -- This is `liftA2` but can be done more efficiently for some instances (is it true?) > azipWith :: (a -> b -> c) -> m a -> m b -> m c > azipWith f = azip (uncurry f) > > aunzip :: m (a,b) -> (m a, m b) > aunzip mab = (fst <$> mab, liftM <$> mab) > > and > > class (Monad m, ApplicativeZip m) => MonadZip m where > mzip :: m a -> m b -> m (a,b) > mzip = azip > > mzipWith :: (a -> b -> c) -> m a -> m b -> m c > mzipWith = azipWith > > munzip :: m (a,b) -> (m a, m b) > munzip = aunzip > > IMHO that should been done during AMP-reform, sorry if this topic is already discussed. > > - Oleg > > _______________________________________________ > Libraries mailing list > Libraries(a)haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >

1 0

Should foldl' be added to the post-"Plan FTP" Prelude
by Bob Ippolito 07 Mar '15

07 Mar '15

(Cross-posted from haskell-cafe as suggested by Carter Schonwald) I would love to have foldl' as part of the Prelude. I use it quite frequently and it seems like a beginner trap to have foldl but not foldl' (which is almost always the better choice). I see that foldMap has been added (in addition to all of Monoid and Traversable), why was foldl' left out? It might be good measure to add foldr' as well, although I use that much less frequently. -bob

8 10

Data.Graph (and Data.Tree) improvements
by Edward Z. Yang 06 Mar '15

06 Mar '15

Data.Graph has always been a bit of an unloved module in containers. However, at GHC HQ the graph has always been a bit of an important data type, and we've been maintaining basically another version of the module under the name Digraph. I was refactoring this module to use Data.Graph and I noticed that there were a few functions which were conspicuously missing from the module proper. So here they are: For Data.Graph: - Generalized reachable :: Graph -> [Vertex] -> [Vertex] (compare to reachable :: Graph -> Vertex -> [Vertex] - Returns an undirected version of a graph which, for any edge a -> b, an edge b -> a also exists. undirected :: Graph -> Graph - Extract a list of groups of elements of a graph such that each group has no dependence except on nodes in previous groups (i.e. they may not depend on nodes in their own group) such that the groups are maximal. No solution exists for cyclic graphs vertexGroups :: Graph -> [[Vertex]] For Data.Tree - preorderF :: Forest a -> [a] (or perhaps flattenF, to keep naming consistent with existing flatten :: Tree a -> [a] which does a preorder) Furthermore, we have a few "low level" functions implementing algorithms for classifying edges, finding connected and biconnected components that were contributed by Sigbjorn Finne in 1997, although GHC does not use them. Finally, I think GHC's node-parametrized variant of graphs (to which it gives the name 'Graph', as opposed to Data.Graph style graphs which it calls 'IntGraph'; is far more useful to clients: data Graph node = Graph { gr_int_graph :: IntGraph, gr_vertex_to_node :: Vertex -> node, gr_node_to_vertex :: node -> Maybe Vertex } and I think it is well worth considering implementing this is the standard library. If no one else, GHC will happily use such an implementation. Thanks, Edward

1 0

fgl-5.5.0.1
by C Maeder 06 Mar '15

06 Mar '15

Hi Ivan, could you make a new release of fgl that works with ghc-7.10? I could compile it locally after the following changes: Data/Graph/Inductive/Query/Monad.hs +import Control.Applicative +import Control.Monad (ap, liftM) +instance Monad m => Functor (GT m g) where + fmap = liftM + +instance Monad m => Applicative (GT m g) where + pure = return + (<*>) = ap Data/Graph/Inductive/Monad/IOArray.hs -{-# LANGUAGE MultiParamTypeClasses, FlexibleInstances #-} +{-# LANGUAGE MultiParamTypeClasses, FlexibleInstances, FlexibleContexts #-} I'm not sure why FlexibleContexts is now needed and I'm not sure how the package version number should change. Cheers Christian

6 8

ApplicativeZip
by Oleg Grenrus 06 Mar '15

06 Mar '15

After Edward Kmett mentioned that we should add MonadZip to Data.Monoid instances, that got me thinking about: Why we don’t have ApplicativeZip? class Applicative f => ApplicativeZip f where {-# MINIMAL azip | azipWith #-} azip :: m a -> m b -> m (a,b) azip = azipWith (,) -- This is `liftA2` but can be done more efficiently for some instances (is it true?) azipWith :: (a -> b -> c) -> m a -> m b -> m c azipWith f = azip (uncurry f) aunzip :: m (a,b) -> (m a, m b) aunzip mab = (fst <$> mab, liftM <$> mab) and class (Monad m, ApplicativeZip m) => MonadZip m where mzip :: m a -> m b -> m (a,b) mzip = azip mzipWith :: (a -> b -> c) -> m a -> m b -> m c mzipWith = azipWith munzip :: m (a,b) -> (m a, m b) munzip = aunzip IMHO that should been done during AMP-reform, sorry if this topic is already discussed. - Oleg

1 0

On the scope of 'directory' (and which issue tracker to use)
by Phil Ruffwind 03 Mar '15

03 Mar '15

Looking at the current API, it seems that the 'directory' library has been extended to more than just mere directory-related operations: it includes several file-related utilities as well. It looks to me that 'directory' has become a place for consolidating filesystem-related operations for *nix and Windows platforms. Given the state of things, would it be more appropriate to call it a "platform-agnostic library for filesystem operations" rather than a "library for directory manipulation"? (Of course, the name of the library and its modules would remain slightly misleading but oh well.) On an unrelated issue, seeing as most of the issues are on GitHub rather than Trac (and I personally find the former simpler to use) perhaps the .cabal file should point to the GitHub issue tracker instead? -- Phil

2 1

Error -> Except migration
by Ganesh Sittampalam 03 Mar '15

03 Mar '15

Hi, In recent versions of transformers, 'ErrorT' has been deprecated in favour of 'ExceptT': https://hackage.haskell.org/package/transformers-0.4.2.0/docs/Control-Monad… This doesn't seem like a trivial like-for-like replacement since the implementation of 'fail' is different - in ErrorT it produces an exception within the ErrorT itself, and in ExceptT it just calls fail in the underlying monad. Is there any guidance or simple trick to find if a program is relying on the old behaviour? Otherwise migrating could be rather painful/dangerous, particularly as tests often don't cover exceptional cases well. I've spent a while searching for past discussion of the change, but haven't found anything, so please do point me at anything relevant if this has already been discussed. Cheers, Ganesh

2 2

Proposal to deprecate and then drop fromJust
by Erik de Castro Lopo 02 Mar '15

02 Mar '15

Hi all, We currently have in the Data.Maybe module from base: fromJust :: Maybe a -> a which newbies often find using hoogle or other search tools and is a huge trap. *Every* usage of the above can be replaced by using fromMaybe :: a -> Maybe a -> a which forces the user to provide a default value for the case where the Maybe a is a Nothing. The idea would be to deprecate fromMaybe for 7.12 and remove it completely later. Comments? Erik -- ---------------------------------------------------------------------- Erik de Castro Lopo http://www.mega-nerd.com/

30 67