I agree with your general conservatism, but I think some of these things are not like the others. I like `on` for the Prelude because, despite its size, it carries with it the idea of carrying a relationship between two values through a function. Notably, for *any* function f,

    eq `on` f defines a decidable equivalence relation if eq does.
    cmp `on` f defines a decidable partial order if cmp does.
    d `on` f is a pseudometric if d is.

What a beautiful and useful concept! I find it much harder to get excited about the idea of flipping function application.

On Tue, Sep 10, 2019, 9:50 PM Elliot Cameron <eacameron@gmail.com> wrote:
Part of me would too...but I just don't know when this line of reasoning stops. Do we add (>>>) and (<<<) from Category too? Then (&&&)? Of course then we might want first, second... Oh and (<$) isn't exported but ($>) is? Fix that too. Then come join, fix, void, when, unless, bool, fromMaybe..... I've come to the conclusion that Prelude should err on the side of very small because Haskell is just too diverse a place to expect everyone to agree on all these little things. We should all be making project-specific Preludes instead IMO.

On Tue, Sep 10, 2019 at 9:41 PM chessai . <chessai1996@gmail.com> wrote:
I would also prefer if (&) and `for` were exported from the Prelude. 

On Tue, Sep 10, 2019, 9:33 PM Elliot Cameron <eacameron@gmail.com> wrote:
Hilariously, I'm mild -1 on this. Haskell is an extremely import-heavy language. Anyone who isn't willing to just write their own mini-Prelude should be ready to import things like `on`. Why isn't `for` exported in Prelude? What about `&`? Both of these are extremely useful and common, even moreso than *on*! And their implementation is *even shorter*. It's a slippery slope.

On Tue, Sep 10, 2019 at 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