<div dir="ltr"><div>Hello everyone,</div><br><div>To provide another data-point; in my "Prelude module replacement" package</div><div><br></div><div><a href="http://hackage.haskell.org/package/Prelude">http://hackage.haskell.org/package/Prelude</a><br></div><div><br></div><div>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:</div><div><br></div><div><a href="http://hackage.haskell.org/package/Prelude-0.1.0.1/docs/Prelude.html#g:21">http://hackage.haskell.org/package/Prelude-0.1.0.1/docs/Prelude.html#g:21</a><br></div><div><br></div><div>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.</div><div><br></div><div>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.</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Sep 11, 2019 at 1:32 PM Dmitrii Kovanikov <<a href="mailto:kovanikov@gmail.com">kovanikov@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">+1 from me<br><div><br></div><div>We export `on` from `relude` by default and didn't have any problems so far:</div><div><br></div><div>* <a href="http://hackage.haskell.org/package/relude-0.5.0/docs/Relude-Function.html#v:on" target="_blank">http://hackage.haskell.org/package/relude-0.5.0/docs/Relude-Function.html#v:on</a></div><div><br></div><div>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.</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Sep 11, 2019 at 1:53 AM David Feuer <<a href="mailto:david.feuer@gmail.com" target="_blank">david.feuer@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="auto">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?<div dir="auto"><br></div><div dir="auto"><div dir="auto"> on :: (b -> b -> c) -> (a -> b) -> a -> a -> c</div><div dir="auto"> (.*.) `on` f = \x y -> f x .*. f y</div></div></div>
_______________________________________________<br>
Libraries mailing list<br>
<a href="mailto:Libraries@haskell.org" target="_blank">Libraries@haskell.org</a><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries</a><br>
</blockquote></div>
_______________________________________________<br>
Libraries mailing list<br>
<a href="mailto:Libraries@haskell.org" target="_blank">Libraries@haskell.org</a><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries</a><br>
</blockquote></div>