Proposal: add `on` to the Prelude

[Elliot Cameron]

Perhaps this question should be answered: What is the guiding principle for
Prelude? Why does it exist?

This is probably the most contentious module in all of Haskell's ecosystem.
Everyone wants to vie for their definition of "idiomatic" and getting
something into Prelude is how you "win". But we all already have things in
Prelude we don't like... Like head... How did that get in there? I'm sure
many of us would love to go back and remove it. But once something is in
Prelude it's "idiomatic" so becomes extremely hard to remove.

So, What guides Prelude? Why does Prelude exist?

If there's an answer to that in the report or something, I sense it would
make these discussions so much simpler. If there is no answer then there is
no metric by which to judge any comment in this thread.


On Wed, Sep 11, 2019, 7:53 AM Herbert Valerio Riedel <hvriedel at gmail.com>
wrote:

> Hello everyone,
>
> To provide another data-point; in my "Prelude module replacement" package
>
> http://hackage.haskell.org/package/Prelude
>
> which encodes a common standard vocabulary from `base` I've observed in my
> own projects over the years where I often keep a "local prelude" module for
> the purpose of establishing a project-specific common vocabulary. Under
> these constraints,  `on` as well as `&` happens to be such a common
> vocabulary which I expect to have in my default scope, and thus is
> reexported from the "Prelude" module:
>
> http://hackage.haskell.org/package/Prelude-0.1.0.1/docs/Prelude.html#g:21
>
> But then again, since it's so easy to implement your own opinionated
> "Prelude" replacement (either project-local or as a package on Hackage),
> and subjective tastes differ greatly as the recent controversial
> "singleton" proposal showed, and even though reexporting `on` from Prelude
> has an objective merit in contrast, and I can definitely sympathise with
> *this* proposal,  I'm not sure if we really need to modify `base` to
> achieve the stated goal of having a more convenient function in scope.
>
> But to be clear; at this point, I'm neither for nor against the proposal
> to reexport names from Data.Function from the `base` Prelude.
>
> On Wed, Sep 11, 2019 at 1:32 PM Dmitrii Kovanikov <kovanikov at gmail.com>
> wrote:
>
>> +1 from me
>>
>> We export `on` from `relude` by default and didn't have any problems so
>> far:
>>
>> *
>> http://hackage.haskell.org/package/relude-0.5.0/docs/Relude-Function.html#v:on
>>
>> I believe that this proposal hits the same wall like all other proposals
>> regarding changes to the standard library — it's not clear, what are
>> Prelude goals. Should it be minimal and provide only fundamental things, or
>> should it enforce commonly used idioms? I think that the `on` function from
>> this proposal is the most widely used version of any other function with
>> the same name. When I see `on` in the code, I first expect the version from
>> `base`, not from some external library with a different type. Implementing
>> your own `on` in your library and forcing users to use it makes code hard
>> to read and reason about. Especially when people are using implicit imports
>> — good luck figuring out which one `on` is used! I believe that if `on` was
>> already imported by `Prelude`, fewer people would introduce identifiers
>> with this name. Which means that exporting `on` from `Prelude` is an
>> excellent thing to do if `Prelude` wants to force idiomatic usage of this
>> function.
>>
>> On Wed, Sep 11, 2019 at 1:53 AM 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/20190911/368cc365/attachment.html>