Proposal: add `on` to the Prelude

Elliot Cameron eacameron at
Fri Sep 13 13:32:45 UTC 2019

> It's not only about top-level functions named 'on'. If I use 'on' as a
local variable, then I get warnings about local redefinitions of the global

Oh heavens how did we not think of this point immediately? This frankly has
me terrified of this proposal. This is such a cute name it's hard to
imagine that it's not a local binding in numerous, invisible places.

(Just last week I had to fix a package not on Hackage because it locally
defined (<>)...)

On Fri, Sep 13, 2019, 7:54 AM Henning Thielemann <
lemming at> wrote:

> On Tue, 10 Sep 2019, David Feuer wrote:
> > Every time I reach for Data.Function.on, I feel like a total dolt for
> having to import a module to get a function
> > whose implementation is barely longer than the import. And it's a really
> good function too! Can we please add it
> > to the Prelude?
> >   on :: (b -> b -> c) -> (a -> b) -> a -> a -> c
> >   (.*.) `on` f = \x y -> f x .*. f y
> Most of the time I would use this I can use the more specific 'equating'
> and 'comparing'.
> I remember there was a lengthy discussion about the right name of 'on' and
> adding it to Data.Function. I had no need for that function because at
> this point I already had:
> If I am right the short name 'on' was only adopted because it was not
> (automatically) exported by
> Prelude._______________________________________________
> Libraries mailing list
> Libraries at
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the Libraries mailing list