Proposal: Use (.) and id from Control.Category in Prelude

[John Meacham]

Yeah, type errors get really confusing with too much overloading and
you start to have to use type annotations way more often. I recently
"de-overloaded" a fair bit of the jhc codebase I wrote back when I
thought it was cute to use typeclasses just to reuse syntax.

Actually, a change I'd like to see is just make sure that no modules
re-export anything that prelude exports. that way you can do a import
prelude hiding (blah) and not have to add the hiding clause to other
imports that happen to re-export prelude names.

    John

On Sat, Jun 14, 2014 at 7:43 PM, Dan Doel <dan.doel at gmail.com> wrote:
> On Sat, Jun 14, 2014 at 5:10 PM, Sjoerd Visscher <sjoerd at w3future.com>
> wrote:
>>
>> Packages like lens now jump through hoops to be able to do composition
>> with the Prelude (.), making proper abstraction impossible, resulting in
>> horrible error messages spewing the internals of the library to the
>> unsuspecting user.
>
>
> Category is inadequate for the type of composition that goes on in lens.
> lens relies on the type class system to induce subtyping between the various
> types it defines (aliases). If you create abstraction barriers around things
> like Iso, Lens, Prism, Traversal, etc. then each of these will only compose
> with like things, and one of the major features of lens would be lost.
>
> Category also doesn't work for the four-parameter versions of things
> required for full generality.
>
> So lens isn't a very compelling motivation for Category composition.
>
> -- Dan
>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://www.haskell.org/mailman/listinfo/libraries
>



-- 
John Meacham - http://notanumber.net/