I don't use `on` because my usecases are covered by `sortOn` and `groupWith`; I can only recall a couple of cases when I had to resort to `on`, and I don't often see it in others' code either, or if I do it's often in conjuction  with `sort` anyway.

I have, however, seen people use `on` because it's /cute/, and it's definitely not something I would want to encourage.

On the other hand, `for` and `when` and `and` and other common words are taken already and it almost never creates any problems for me, so I would not mind having `on` stolen either.

So, I'm -0.5 on the proposal.

On Thu, Sep 12, 2019, 18:20 Elliot Cameron <eacameron@gmail.com> wrote:
Bleh. Now we have two functions that do the same thing, both in base... I don't want "on" in prelude but this seems far worse to me than the original proposal. Let's stick with that one for now and if it dies you can propose this separately? :D

On Thu, Sep 12, 2019 at 11:15 AM David Feuer <david.feuer@gmail.com> wrote:
No, there's certainly no need to remove the existing function.

On Thu, Sep 12, 2019, 10:57 AM Elliot Cameron <eacameron@gmail.com> wrote:
You might be on2 something.

But then you rename it in Data.Function too and break backward compat??

On Thu, Sep 12, 2019 at 10:55 AM David Feuer <david.feuer@gmail.com> wrote:
For whatever it's worth, the unidiomatic but arguably more logical name `on2` has no hits on Hoogle.

On Tue, Sep 10, 2019, 6:59 PM David Feuer <david.feuer@gmail.com> wrote:
Indeed, there are a lot more conflicts than I'd have expected. Ignoring functions with the same type, Hoogle shows this name in the below packages. I have no sense of the overall significance of the specific packages or (equally importantly) of the `on` function within each.

haskell-gi-base:
on :: forall object info m . (GObject object, MonadIO m, SignalInfo info) => object -> SignalProxy object info -> HaskellCallbackType info -> m SignalHandlerId

brick:
on :: Color -> Color -> Attr

esqueletto:
on :: SqlExpr (Value Bool) -> SqlQuery ()

relational-query (both):
on :: MonadQuery m => Predicate Flat -> m ()
on :: MonadQuery m => QueryA m (Predicate Flat) ()

threepenny-gui:
on :: (element -> Event a) -> element -> (a -> UI void) -> UI ()

miso:
on :: MisoString -> Decoder r -> (r -> action) -> Attribute action

wild-bind:
on :: i -> v -> Binder i v ()

massiv-io:
on :: Pixel X Bit

selda-postgresql:
on :: Text -> Text -> PGConnectInfo


On Tue, Sep 10, 2019, 6:42 PM Ryan Trinkle <ryan.trinkle@gmail.com> wrote:
One note: this does conflict with some other libraries, for instance GTK2HS

On Tue, Sep 10, 2019 at 6:26 PM chessai . <chessai1996@gmail.com> wrote:
+1

On Tue, Sep 10, 2019, 5:53 PM David Feuer <david.feuer@gmail.com> 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
_______________________________________________
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
_______________________________________________
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