On 06/14/2014 02:31 PM, Johan Tibell wrote:

On Sat, Jun 14, 2014 at 10:15 PM, Carter Charbonneau mailto:zcarterc@gmail.com> wrote:

(.) and id are generalized in the Category class in Control.Category. In the past, many libraries have instructed users to use (.) and id from Control.Category for composition of their types. Importing these types into Prelude shouldn't break existing code, and makes libraries that use Category easier to use.

Discussion period: 4 weeks

-1

This would benefit very few Haskell users and make error messages terrible.

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

In real use of Category with only the (->) instance in scope, I don't run into complex error messages often, if ever. Do you have an example where complex error messages come into play?

-2. Please don't. The status quo works well enough, and is sufficient for many many cases (in fact all I've ever encountered). Folks who need more already have a perfectly reasonable way to get it: simply use the overloaded operators from `Control.Category`. -Iavor On Sat, Jun 14, 2014 at 2:10 PM, Sjoerd Visscher wrote:

I strongly disagree, this would benefit all Haskell users, and will improve error messages!

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.

Composition is very important for modular code, and should be made as accessible to all users as possible.

Sjoerd

On 14 Jun 2014, at 22:31, Johan Tibell wrote:

On Sat, Jun 14, 2014 at 10:15 PM, Carter Charbonneau wrote:

...

(.) and id are generalized in the Category class in Control.Category. In the past, many libraries have instructed users to use (.) and id from Control.Category for composition of their types. Importing these types into Prelude shouldn't break existing code, and makes libraries that use Category easier to use.

Discussion period: 4 weeks

-1

This would benefit very few Haskell users and make error messages terrible.

_______________________________________________ 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

On 15 Jun 2014, at 16:13, Herbert Valerio Riedel wrote:

I wonder if Haskell could be extended to be able to write something like

import Data.Category

and have the more general versions of (.) and id automatically shadow the monomorphic versions brought in scope by the Prelude.

Just a thought (which is probably not that new)

There was a brief discussion about it some time ago: http://comments.gmane.org/gmane.comp.lang.haskell.glasgow.user/23719

I'm somewhat neutral on the proposal. On the plus side, generalizing Category fits with the current goal of having base export one version of each combinator. On the minus side, Category is far less used than the other abstractions we're bringing into Prelude in 7.10. Utimately? I'm ever so slightly in the 'we shouldn't do it' camp -- a very weak -1 -- from the standpoint that Category is currently PolyKinded, which is incredibly useful, and so far, nothing we export or are planning to export from Prelude is. It is currently very easy to propose the new Prelude we're building to the folks on the Haskell' committee for standardization going forward. With PolyKinds that becomes a rather bigger leap. Now, having implemented PolyKinds in another compiler, they aren't too hard, just slightly tricky, so that may be a thing we do want to do eventually, but I'd have a hard time putting it forward for standardization with a straight face today. I'd feel a bit more comfortable getting through the current wave of generalization for 7.10, then revisiting if we should do this for 7.12 once the community has had a chance to adapt. If there was a huge upswell of support for this we could do it, but so far the response has been one of measured indifference. -Edward On Mon, Jun 16, 2014 at 5:09 AM, Erik Hesselink wrote:

On Sun, Jun 15, 2014 at 4:13 PM, Herbert Valerio Riedel wrote:

...

I wonder if Haskell could be extended to be able to write something like

import Data.Category

and have the more general versions of (.) and id automatically shadow the monomorphic versions brought in scope by the Prelude.

We use a custom prelude that almost gives us this. You have to do:

{-# LANGUAGE NoImplicitPrelude #-}

import Prelude.Polymorphic

This gives us Foldable/Traversable/Category polymorphic variants of the prelude functions. It's been a pretty good experience. The largest problem, as Edward already mentioned, are the re-exports of Control.Monad from the mtl package.

I'm -1 on making (.) polymorphic by default though. The errors can be kind of intimidating for the beginning Haskeller. Let's first see how it goes with Foldable/Traversable in the prelude...

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

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/

On Sun, Jun 15, 2014 at 09:26:19AM +0300, Roman Cheplyaka wrote:

* John Meacham [2014-06-14 19:54:16-0700]

...

Actually, a change I'd like to see is just make sure that no modules re-export anything that prelude exports.

Do you have any examples of this?

Data.List has a lot of them. Others include: Control.Monad: Functor(fmap), Monad((>>=), (>>), return, fail) Data.Functor: Functor(fmap) Data.Maybe: Maybe(Nothing, Just), maybe Data.Ratio: Rational

On Sat, Jun 14, 2014 at 10:54 PM, John Meacham wrote:

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.

I could personally get behind this policy. mtl is probably the worst offender, and I receive regular complaints from users about it. It is very hard to hide something when 10 of your imports want to re-export it ;) Moreover, many of these cases will cease to make sense in 7.8. e.g. Data.List.foldr as a re-export would be a lot harder to motivate when that is re-exporting the Foldable version, while having it export a monomorphic version would break virtually every user of Data.List -Edward