I propose to deprecate Data.FunctorM in favour of Data.Traversable: http://www.haskell.org/ghc/dist/current/docs/libraries/base/Data-Traversable...
On Thu, Mar 02, 2006 at 12:41:22PM +0000, Ross Paterson wrote:
I propose to deprecate Data.FunctorM in favour of Data.Traversable:
http://www.haskell.org/ghc/dist/current/docs/libraries/base/Data-Traversable...
I have no particular objection, The applicative stuff looks interesting, though I have not explored it too much. my only request is that we add 'mapM_' and 'sequence_' to the traversable class, there are many monads for which they are vital for controlling space leaks. John -- John Meacham - ⑆repetae.net⑆john⑈
On Thu, Mar 02, 2006 at 05:02:39AM -0800, John Meacham wrote:
On Thu, Mar 02, 2006 at 12:41:22PM +0000, Ross Paterson wrote:
I propose to deprecate Data.FunctorM in favour of Data.Traversable:
I have no particular objection, The applicative stuff looks interesting, though I have not explored it too much.
my only request is that we add 'mapM_' and 'sequence_' to the traversable class, there are many monads for which they are vital for controlling space leaks.
They're in Data.Foldable, though not as class methods: http://www.haskell.org/ghc/dist/current/docs/libraries/base/Data-Foldable.ht... e.g. Set is an instance of Foldable but not Traversable.
On Thu, Mar 02, 2006 at 01:10:42PM +0000, Ross Paterson wrote:
On Thu, Mar 02, 2006 at 05:02:39AM -0800, John Meacham wrote:
On Thu, Mar 02, 2006 at 12:41:22PM +0000, Ross Paterson wrote:
I propose to deprecate Data.FunctorM in favour of Data.Traversable:
I have no particular objection, The applicative stuff looks interesting, though I have not explored it too much.
my only request is that we add 'mapM_' and 'sequence_' to the traversable class, there are many monads for which they are vital for controlling space leaks.
They're in Data.Foldable, though not as class methods:
http://www.haskell.org/ghc/dist/current/docs/libraries/base/Data-Foldable.ht...
e.g. Set is an instance of Foldable but not Traversable.
They should definitly be made class methods somewhere. They usually have to be custom written for a given datatype and RULES pragmas arn't powerful enough to know when somethings monadic result is not used. John -- John Meacham - ⑆repetae.net⑆john⑈
Hello,
The library looks nice. I use a number of the operations in the
applicative module (sadly with different names :-). I was wondering,
why does 'Applicative' introduce a new mapping operator, instead of
inheriting one from 'Functor'? Also I have mentioned before, that I
think that 'forEach' is a better name for 'mapM' with the arguments
swapped. I find it makes code more readable, but of course this is
just a personal preference. Other related operators that I find
useful and use quite a bit are:
forEach2 :: Monad m => [a] -> [b] -> (a -> b -> m c) -> m [c] -- (aka zipWithM)
forEach2' :: same type, but uses lazy pattern matching in the second argument.
The second operator is quite useful if the one list is recursively
created, and it is important
that it is not forced too early. Do you think at least 'forEach2'
should also be in the 'Traversable' class, or does it perhaps belong
to some other class?
-Iavor
On 3/2/06, Ross Paterson
I propose to deprecate Data.FunctorM in favour of Data.Traversable:
http://www.haskell.org/ghc/dist/current/docs/libraries/base/Data-Traversable...
_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries
participants (3)
-
Iavor Diatchki -
John Meacham -
Ross Paterson