I agree too. I use the name (~>) whenever I have some profunctor-like type variable. Putting it in a library would be like defining "x" or "a" in a library. Certainly natural transformations are helpful to have a library around, but they should be given a better name. On Mon, Nov 14, 2016 at 1:48 PM, John Wiegley wrote:

...

...

...

...

...

"EM" == Eric Mertens writes:

EM> I'd prefer that we didn't prescribe a meaning to this generally useful EM> type operator. This type synonym is very easy to define in any module EM> where it's appropriate.

I agree. Taking "~>" for natural transformations seems too specific.

-- John Wiegley GPG fingerprint = 4710 CF98 AF9B 327B B80F http://newartisans.com 60E1 46C4 BD1A 7AC1 4BA2 _______________________________________________ Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

-- Live well, ~wren

I'm -1 on the proposal of adding this type to base. One one hand, natural-transformation already provides this definition in a "centralized" locale for folks who really do want to share it with a ridiculously stripped down set of dependencies, which provides a place for those who really want to get it from a central location as well. Not as nice as no dependency at all in a world where we could all agree this is the best thing to add to base, but darn close. On the other: As a type alias there is no real compatibility gain to be had. If both of us define (~>) as above, then types written with types against my (~>) and types written against your (~>) are *freely interchangeable*, even if you might have to play with your import lists more carefully. We can't hang any instances off of it, so almost all of the standard arguments for moving it "closer to base" fail to take effect. On the other, other hand, something like newtype f ~> g = Nat { runNat :: forall a. f a -> g a } is slightly easier to make a case for, because you can hang instances off of it and share more than one line of code, but I'd be -1 on that as well, because there are a host of issues with that definition as well not being "one size fits all" either. There are several viable definitions for a natural transformation depending on how general you want to get -- and this one (like the one in natural-transformation) conflates parametricity with naturality, so rapidly stops being good enough as you drift into PolyKinds and then start wanting a more accurate Category and Functor notions, which then force you to parameterize over the underlying `->` in the definition. Both of these definitions occupy awkward suboptimal points in the design space, so I'd rather not see us locked into their use by enshrining either one in base. -Edward On Tue, Nov 15, 2016 at 4:01 AM, Oleg Grenrus wrote:

FWIW, i personally use `natural-transformation` library [1], which provides this exact type alias, and also newtype around it (which is occasionally useful).

I’d rather promote the usage of the library (which has only `base` as dependency!).

- [1]: https://hackage.haskell.org/package/natural- transformation-0.3.1/docs/Control-Natural.html

On 14 Nov 2016, at 20:11, Baldur Blöndal wrote:

What the subject says, add

type f ~> g = forall a. f a -> g a

to ‘base’. Further motivation (and arguments against) in GHC Trac ticket 12772 [1].

[1] https://ghc.haskell.org/trac/ghc/ticket/12772 _______________________________________________ Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

_______________________________________________ Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries