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

John Meacham john at
Sun Jun 15 02:54:16 UTC 2014

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.


On Sat, Jun 14, 2014 at 7:43 PM, Dan Doel <dan.doel at> wrote:
> On Sat, Jun 14, 2014 at 5:10 PM, Sjoerd Visscher <sjoerd at>
> 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

John Meacham -

More information about the Libraries mailing list