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 <gabriel439@gmail.com> 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 <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
http://www.haskell.org/mailman/listinfo/libraries



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