Apologies

[Edward Kmett]

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 at 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 at 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 at haskell.org
>> http://www.haskell.org/mailman/listinfo/libraries
>>
>
>
>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://www.haskell.org/mailman/listinfo/libraries
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20130521/dfc872db/attachment.htm>