Proposal: add `on` to the Prelude

[Edward Kmett]

The number of name conflicts here has me rather conflicted.

To date, we've been treating the Prelude is a very precious common
namespace.

Every name it takes is a significant cost because now every other use of
the name, pre-existing or not, has to explicitly _hide_ the import from the
Prelude, not just in their library code, but in all the code that uses the
library.

By comparison, the Data.List.singleton issue was comparatively clash-free
as most uses of a combinator with the same name were already qualified, and
we were able to mitigate the remaining issues, by deciding that the module
in question was intended to become qualified after a short cycle, so no
"global" name is being used up.

Here, we're finding several conflicting combinators, and the cost is
significantly higher for each of the existing consumers of that name to
work around.

It strikes me that in the end there'd be a lot of churn, as all existing
users of conflicting versions of this very short punchy name would have to
move to a new name or endure a ton of Prelude hiding clauses all over their
code, in both library and consumer code.

This leaves me inclined to a -1.

There are combinators I'm somewhat inclined to push into Prelude after an
appropriate referendum, e.g. traverse_ or sequence_ which do a lot of work
and are quite conspicuous in their absence, when a
worse-for-many-applications but comparable tool is closer to hand, but the
slight pain of explicitly importing 'on' seems pretty reasonable given the
combination of its somewhat confusing at first idiomatic usage, and the
somewhat broadly spread existing name conflicts.

-Edward

On Tue, Sep 10, 2019 at 3:59 PM David Feuer <david.feuer at 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 at 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 at gmail.com> wrote:
>>
>>> +1
>>>
>>> On Tue, Sep 10, 2019, 5:53 PM David Feuer <david.feuer at 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 at haskell.org
>>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>>>>
>>> _______________________________________________
>>> Libraries mailing list
>>> Libraries at haskell.org
>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>>>
>> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20190910/e40a5905/attachment.html>