Proposal: add `on` to the Prelude

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
38 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Proposal: add `on` to the Prelude

David Feuer
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
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: add `on` to the Prelude

chessai .
+1

On Tue, Sep 10, 2019, 5:53 PM David Feuer <[hidden email]> 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
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: add `on` to the Prelude

Helmut Schmidt
In reply to this post by David Feuer

Am Di., 10. Sept. 2019 um 21:53 Uhr schrieb David Feuer <[hidden email]>:
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?

Agreed. This function makes only sense to have if the cost of getting it into scope doesn't outweigh its benefit and therefore I support this proposal which makes a lot more sense than the pointless singleton proposal.




_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: add `on` to the Prelude

Ryan Trinkle-3
In reply to this post by chessai .
One note: this does conflict with some other libraries, for instance GTK2HS

On Tue, Sep 10, 2019 at 6:26 PM chessai . <[hidden email]> wrote:
+1

On Tue, Sep 10, 2019, 5:53 PM David Feuer <[hidden email]> 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
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: add `on` to the Prelude

David Feuer
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 <[hidden email]> wrote:
One note: this does conflict with some other libraries, for instance GTK2HS

On Tue, Sep 10, 2019 at 6:26 PM chessai . <[hidden email]> wrote:
+1

On Tue, Sep 10, 2019, 5:53 PM David Feuer <[hidden email]> 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
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: add `on` to the Prelude

Elliot Cameron-2
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 <[hidden email]> 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 <[hidden email]> wrote:
One note: this does conflict with some other libraries, for instance GTK2HS

On Tue, Sep 10, 2019 at 6:26 PM chessai . <[hidden email]> wrote:
+1

On Tue, Sep 10, 2019, 5:53 PM David Feuer <[hidden email]> 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
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: add `on` to the Prelude

chessai .
I would also prefer if (&) and `for` were exported from the Prelude. 

On Tue, Sep 10, 2019, 9:33 PM Elliot Cameron <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> wrote:
One note: this does conflict with some other libraries, for instance GTK2HS

On Tue, Sep 10, 2019 at 6:26 PM chessai . <[hidden email]> wrote:
+1

On Tue, Sep 10, 2019, 5:53 PM David Feuer <[hidden email]> 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
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: add `on` to the Prelude

Elliot Cameron-2
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 . <[hidden email]> wrote:
I would also prefer if (&) and `for` were exported from the Prelude. 

On Tue, Sep 10, 2019, 9:33 PM Elliot Cameron <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> wrote:
One note: this does conflict with some other libraries, for instance GTK2HS

On Tue, Sep 10, 2019 at 6:26 PM chessai . <[hidden email]> wrote:
+1

On Tue, Sep 10, 2019, 5:53 PM David Feuer <[hidden email]> 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
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: add `on` to the Prelude

Edward Kmett-2
In reply to this post by David Feuer
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 <[hidden email]> 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 <[hidden email]> wrote:
One note: this does conflict with some other libraries, for instance GTK2HS

On Tue, Sep 10, 2019 at 6:26 PM chessai . <[hidden email]> wrote:
+1

On Tue, Sep 10, 2019, 5:53 PM David Feuer <[hidden email]> 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
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: add `on` to the Prelude

David Feuer
In reply to this post by Elliot Cameron-2
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 <[hidden email]> 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 . <[hidden email]> wrote:
I would also prefer if (&) and `for` were exported from the Prelude. 

On Tue, Sep 10, 2019, 9:33 PM Elliot Cameron <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> wrote:
One note: this does conflict with some other libraries, for instance GTK2HS

On Tue, Sep 10, 2019 at 6:26 PM chessai . <[hidden email]> wrote:
+1

On Tue, Sep 10, 2019, 5:53 PM David Feuer <[hidden email]> 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
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: add `on` to the Prelude

Elliot Cameron-2
That's certainly true but I'm not sure what that has to do with being in Prelude. If anything, I'd expect Prelude to be home to the *least* exciting things because no one wants to bother talking about them.

On Tue, Sep 10, 2019, 10:20 PM David Feuer <[hidden email]> wrote:
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 <[hidden email]> 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 . <[hidden email]> wrote:
I would also prefer if (&) and `for` were exported from the Prelude. 

On Tue, Sep 10, 2019, 9:33 PM Elliot Cameron <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> wrote:
One note: this does conflict with some other libraries, for instance GTK2HS

On Tue, Sep 10, 2019 at 6:26 PM chessai . <[hidden email]> wrote:
+1

On Tue, Sep 10, 2019, 5:53 PM David Feuer <[hidden email]> 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
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: add `on` to the Prelude

Helmut Schmidt
In reply to this post by chessai .

+1

Am Mi., 11. Sept. 2019 um 01:41 Uhr schrieb chessai . <[hidden email]>:
I would also prefer if (&) and `for` were exported from the Prelude. 

On Tue, Sep 10, 2019, 9:33 PM Elliot Cameron <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> wrote:
One note: this does conflict with some other libraries, for instance GTK2HS

On Tue, Sep 10, 2019 at 6:26 PM chessai . <[hidden email]> wrote:
+1

On Tue, Sep 10, 2019, 5:53 PM David Feuer <[hidden email]> 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
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: add `on` to the Prelude

Helmut Schmidt
In reply to this post by Edward Kmett-2


Am Mi., 11. Sept. 2019 um 02:18 Uhr schrieb Edward Kmett <[hidden email]>:
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.
 
This slight pain of writing "import Data.Function (on)" as you call is why I and probably most other people don't bother using "on". But why is such a trivial combinator that's cheaper to define locally than to import even defined in the base library if the pain of using it outweighs its usefulness and there's just a handful of people at best using it?



_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: add `on` to the Prelude

Dmitrii Kovanikov
In reply to this post by David Feuer
+1 from me

We export `on` from `relude` by default and didn't have any problems so far:


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 <[hidden email]> 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
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: add `on` to the Prelude

Herbert Valerio Riedel-3
Hello everyone,

To provide another data-point; in my "Prelude module replacement" package


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:


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 <[hidden email]> wrote:
+1 from me

We export `on` from `relude` by default and didn't have any problems so far:


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 <[hidden email]> 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
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: add `on` to the Prelude

Elliot Cameron-2
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 <[hidden email]> wrote:
Hello everyone,

To provide another data-point; in my "Prelude module replacement" package


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:


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 <[hidden email]> wrote:
+1 from me

We export `on` from `relude` by default and didn't have any problems so far:


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 <[hidden email]> 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
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: add `on` to the Prelude

Ivan Lazar Miljenovic
-1 from me; I have no problem with long import lists as I'd prefer to know _where_ a function comes from than keeping track of "what's in Prelude this month?" (looking at you random Monoid, Semigroup, etc. additions to Prelude).

I use `on` a _lot_ and have never once considered doing a custom Prelude or anything like that.

On Wed, 11 Sep. 2019, 9:00 pm Elliot Cameron, <[hidden email]> wrote:
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 <[hidden email]> wrote:
Hello everyone,

To provide another data-point; in my "Prelude module replacement" package


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:


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 <[hidden email]> wrote:
+1 from me

We export `on` from `relude` by default and didn't have any problems so far:


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 <[hidden email]> 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
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: add `on` to the Prelude

Oliver Charles-3
-1, for the same reasons as Ivan.

I would prefer *everything* to have an explicit import "binding site",
and I'd also rather that not be a huge single line from one module
(though of course, I can break the import up other multiple lines).

On Wed, Sep 11, 2019 at 3:11 PM Ivan Lazar Miljenovic
<[hidden email]> wrote:

>
> -1 from me; I have no problem with long import lists as I'd prefer to know _where_ a function comes from than keeping track of "what's in Prelude this month?" (looking at you random Monoid, Semigroup, etc. additions to Prelude).
>
> I use `on` a _lot_ and have never once considered doing a custom Prelude or anything like that.
>
> On Wed, 11 Sep. 2019, 9:00 pm Elliot Cameron, <[hidden email]> wrote:
>>
>> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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
>>>>> [hidden email]
>>>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>>>>
>>>> _______________________________________________
>>>> Libraries mailing list
>>>> [hidden email]
>>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>>>
>>> _______________________________________________
>>> Libraries mailing list
>>> [hidden email]
>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>>
>> _______________________________________________
>> Libraries mailing list
>> [hidden email]
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>
> _______________________________________________
> Libraries mailing list
> [hidden email]
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: add `on` to the Prelude

Helmut Schmidt

What do you mean by "I'd also rather that not be a huge single line from one module"? Can you elaborate how this relates to the proposal?

Am Mi., 11. Sept. 2019 um 14:45 Uhr schrieb Oliver Charles <[hidden email]>:
I would prefer *everything* to have an explicit import "binding site",
and I'd also rather that not be a huge single line from one module
(though of course, I can break the import up other multiple lines).

_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: add `on` to the Prelude

Oliver Charles-3
I would ignore that comment actually, it's not well thought out.

(I was roughly meaning that I don't want to write `import Prelude (x1,
x2, ..., x500)`, but this isn't a valid argument as I don't actually
explicitly import `Prelude` anyway).

That said, I would still prefer as many symbols as possible to have
explicit binding sites, which means I would prefer to be explicit
about my import to `on` rather than assume it from the Prelude.

On Wed, Sep 11, 2019 at 3:49 PM Helmut Schmidt
<[hidden email]> wrote:
>
>
> What do you mean by "I'd also rather that not be a huge single line from one module"? Can you elaborate how this relates to the proposal?
>
> Am Mi., 11. Sept. 2019 um 14:45 Uhr schrieb Oliver Charles <[hidden email]>:
>>
>> I would prefer *everything* to have an explicit import "binding site",
>> and I'd also rather that not be a huge single line from one module
>> (though of course, I can break the import up other multiple lines).
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
12