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

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 wrote:

On Sat, Jun 14, 2014 at 5:10 PM, Sjoerd Visscher 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@haskell.org http://www.haskell.org/mailman/listinfo/libraries

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