The issue with a more generalized Functor is that inference _does_ suffer for it and moreover it takes you outside of Haskell 98/2010/prime by requiring MPTCs (and to be honest, fundeps/TFs to make it suck less.) The very loose proposal put forward remains entirely within the 98+2010 garden precisely to avoid the type inference bogeyman. -Edward On Tue, May 21, 2013 at 2:06 AM, Gabriel Gonzalez wrote:

** On 05/20/2013 10:41 PM, Carter Schonwald wrote:

could you elaborate on the other useful generalizations please? :-)

For example, mapM defines a functor in the Kleisli category:

mapM return = return

mapM (f >=> g) = mapM f >=> mapM g

So then why not have a generalized Functor class that works on arbitrary categories:

class CFunctor c f where cmap :: c a b -> c (f a) (f b)

instance (Traversable t) => CFunctor Kleisli t where ...

Or consider that `mapM` leaks space for large traversables. Another alternative generalization that doesn't leak space is to use pipes. This is not as far-fetched as it sounds, considering that `pipes` are `ListT` done right when viewed through the `RespondT` newtype:

-- i.e. the same as `ProduceT` in `pipes` type ListT = RespondT ProxyCorrect C () ()

-- Just pretend we lived in a parallel Haskell world with this definition type [] = ListT Identity

Then `mapM` becomes `(RespondT . lift .)` when viewed through the lens of the `pipes`-based `ListT m` (except with no more space leaks). Then you'd have the theoretically pure version that does not leak space, but as much as I like `pipes` not a single beginner would ever think to use that.

APIs are like monad tutorials: it's better to teach people starting from something simple and concrete than something abstract. If the Prelude is not for teaching purposes, then what is?

On Tue, May 21, 2013 at 1:41 AM, Gabriel Gonzalez wrote:

...

I want to apologize to wren (and everybody else). I was tired and overreacted when the discussion started veering into making more breaking changes.

I don't mind the Foldable changes too much. My main concerns are:

* loss of monomorphism makes teaching more difficult * They can be generalized in other useful ways

However, I don't consider those concerns show-stoppers.

_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

On 05/20/2013 10:41 PM, Carter Schonwald wrote:

could you elaborate on the other useful generalizations please? :-)

Sorry, I made yet another mistake. The implementation and type should be: mapM :: (a -> m b) -> ListT m a -> ListT m b mapM f m = m >>= lift . f That will not leak and is almost always what people actually want when they use `mapM`, whether or not they use `pipes` to implement `ListT`. It also obeys a different set of functor laws: mapM return = id mapM (f >=> g) = mapM f . mapM g Anyways, sorry for the spam. This is just to show that there are many ways you can generalize something and `Foldable`/`Traversable` are not the last word.

On Tue, May 21, 2013 at 1:41 AM, Gabriel Gonzalez mailto:gabriel439@gmail.com> wrote:

I want to apologize to wren (and everybody else). I was tired and overreacted when the discussion started veering into making more breaking changes.

I don't mind the Foldable changes too much. My main concerns are:

* loss of monomorphism makes teaching more difficult * They can be generalized in other useful ways

However, I don't consider those concerns show-stoppers.

_______________________________________________ Libraries mailing list Libraries@haskell.org mailto:Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries