Proposal: Export (#.) and (.#) from Data.Coerce

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

Proposal: Export (#.) and (.#) from Data.Coerce

Daniel Cartwright
(#.) :: Coercible b c => (b -> c) -> (a -> b) -> (a -> c)
(#.) _ = coerce
{-# INLINE (#.) #-}

(.#) :: Coercible a b => (b -> c) -> (a -> b) -> (a -> c)
(.#) f _ = coerce f
{-# INLINE (.#) #-}

The first of these is exported from Data.Functor.Util, and used in many places inside of base for efficiency over '.' (compose), However no module in base actually exports these. I have recently been using Data.Coerce more frequently and think it would be useful to go ahead and export these from somewhere in base.

For convenience, I will paste the note about (#.) from Data.Functor.Util:

"Note [Function coercion]
~~~~~~~~~~~~~~~~~~~~~~~

Several functions here use (#.) instead of (.) to avoid potential efficiency
problems relating to #7542. The problem, in a nutshell:

If N is a newtype constructor, then N x will always have the same
representation as x (something similar applies for a newtype deconstructor).
However, if f is a function,

N . f = \x -> N (f x)

This looks almost the same as f, but the eta expansion lifts it--the lhs could
be _|_, but the rhs never is. This can lead to very inefficient code.  Thus we
steal a technique from Shachaf and Edward Kmett and adapt it to the current
(rather clean) setting. Instead of using  N . f,  we use  N #. f, which is
just

coerce f `asTypeOf` (N . f)

That is, we just *pretend* that f has the right type, and thanks to the safety
of coerce, the type checker guarantees that nothing really goes wrong. We still
have to be a bit careful, though: remember that #. completely ignores the
*value* of its left operand.
"

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

Re: Proposal: Export (#.) and (.#) from Data.Coerce (Libraries Digest, Vol 176, Issue 8)

Li-yao Xia-2
That seems useful indeed! Using only 'coerce' requires too many type
annotations.

Would it make sense to generalize the type so it's clear that one
argument is unused?

(#.) :: Coercible b c => p b c -> (a -> b) -> (a -> c)
(.#) :: Coercible a b => (b -> c) -> p a b -> (a -> c)

Li-yao

On 04/20/2018 03:56 PM, Daniel Cartwright wrote:

> (#.) :: Coercible b c => (b -> c) -> (a -> b) -> (a -> c)
> (#.) _ = coerce
> {-# INLINE (#.) #-}
>
> (.#) :: Coercible a b => (b -> c) -> (a -> b) -> (a -> c)
> (.#) f _ = coerce f
> {-# INLINE (.#) #-}
>
> The first of these is exported from Data.Functor.Util, and used in many
> places inside of base for efficiency over '.' (compose), However no module
> in base actually exports these. I have recently been using Data.Coerce more
> frequently and think it would be useful to go ahead and export these from
> somewhere in base.
>
> For convenience, I will paste the note about (#.) from Data.Functor.Util:
>
> "Note [Function coercion]
> ~~~~~~~~~~~~~~~~~~~~~~~
>
> Several functions here use (#.) instead of (.) to avoid potential efficiency
> problems relating to #7542. The problem, in a nutshell:
>
> If N is a newtype constructor, then N x will always have the same
> representation as x (something similar applies for a newtype deconstructor).
> However, if f is a function,
>
> N . f = \x -> N (f x)
>
> This looks almost the same as f, but the eta expansion lifts it--the lhs
> could
> be _|_, but the rhs never is. This can lead to very inefficient code.  Thus
> we
> steal a technique from Shachaf and Edward Kmett and adapt it to the current
> (rather clean) setting. Instead of using  N . f,  we use  N #. f, which is
> just
>
> coerce f `asTypeOf` (N . f)
>
> That is, we just *pretend* that f has the right type, and thanks to the
> safety
> of coerce, the type checker guarantees that nothing really goes wrong. We
> still
> have to be a bit careful, though: remember that #. completely ignores the
> *value* of its left operand.
> "
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <http://mail.haskell.org/pipermail/libraries/attachments/20180420/c5646504/attachment-0001.html>
>
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Export (#.) and (.#) from Data.Coerce (Libraries Digest, Vol 176, Issue 8)

Andrew Martin
Generalizing the type like that helps a lot. I had skimmed the documentation before, but I didn’t immediately comprehend what it meant. When I read the type signatures you gave them, it immediately made sense.

Also, +1 on exporting these.

Sent from my iPhone

> On Apr 21, 2018, at 10:06 AM, Li-yao Xia <[hidden email]> wrote:
>
> That seems useful indeed! Using only 'coerce' requires too many type annotations.
>
> Would it make sense to generalize the type so it's clear that one argument is unused?
>
> (#.) :: Coercible b c => p b c -> (a -> b) -> (a -> c)
> (.#) :: Coercible a b => (b -> c) -> p a b -> (a -> c)
>
> Li-yao
>
>> On 04/20/2018 03:56 PM, Daniel Cartwright wrote:
>> (#.) :: Coercible b c => (b -> c) -> (a -> b) -> (a -> c)
>> (#.) _ = coerce
>> {-# INLINE (#.) #-}
>> (.#) :: Coercible a b => (b -> c) -> (a -> b) -> (a -> c)
>> (.#) f _ = coerce f
>> {-# INLINE (.#) #-}
>> The first of these is exported from Data.Functor.Util, and used in many
>> places inside of base for efficiency over '.' (compose), However no module
>> in base actually exports these. I have recently been using Data.Coerce more
>> frequently and think it would be useful to go ahead and export these from
>> somewhere in base.
>> For convenience, I will paste the note about (#.) from Data.Functor.Util:
>> "Note [Function coercion]
>> ~~~~~~~~~~~~~~~~~~~~~~~
>> Several functions here use (#.) instead of (.) to avoid potential efficiency
>> problems relating to #7542. The problem, in a nutshell:
>> If N is a newtype constructor, then N x will always have the same
>> representation as x (something similar applies for a newtype deconstructor).
>> However, if f is a function,
>> N . f = \x -> N (f x)
>> This looks almost the same as f, but the eta expansion lifts it--the lhs
>> could
>> be _|_, but the rhs never is. This can lead to very inefficient code.  Thus
>> we
>> steal a technique from Shachaf and Edward Kmett and adapt it to the current
>> (rather clean) setting. Instead of using  N . f,  we use  N #. f, which is
>> just
>> coerce f `asTypeOf` (N . f)
>> That is, we just *pretend* that f has the right type, and thanks to the
>> safety
>> of coerce, the type checker guarantees that nothing really goes wrong. We
>> still
>> have to be a bit careful, though: remember that #. completely ignores the
>> *value* of its left operand.
>> "
>> -------------- next part --------------
>> An HTML attachment was scrubbed...
>> URL: <http://mail.haskell.org/pipermail/libraries/attachments/20180420/c5646504/attachment-0001.html>
> _______________________________________________
> 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: Export (#.) and (.#) from Data.Coerce (Libraries Digest, Vol 176, Issue 8)

Edward Kmett-2
Note: this way of indicating which argument is unused means that this confusingly looks almost precisely backwards relative to the more general code that created those names and usage pattern in the first place. (I don't have a particularly strong objection to allowing the same sort of tweak to that code, assuming type inference works out in practice for the major consumers of the combinators there. I don't really foresee a problem, but I've been surprised by interactions before.)

I do have some concern that exporting these incompatible versions from Data.Coerce would break a subset of the code that is using the more general combinators in profunctors. e.g. in the lens library these were coined for the code for prisms imports both.

This is why they were placed in a more obscure internal location to begin with as just the special case was needed by base and it was easier to write a copy locally than merge Profunctor to base.

-Edward

On Sat, Apr 21, 2018 at 10:16 AM, Andrew Martin <[hidden email]> wrote:
Generalizing the type like that helps a lot. I had skimmed the documentation before, but I didn’t immediately comprehend what it meant. When I read the type signatures you gave them, it immediately made sense.

Also, +1 on exporting these.

Sent from my iPhone

> On Apr 21, 2018, at 10:06 AM, Li-yao Xia <[hidden email]> wrote:
>
> That seems useful indeed! Using only 'coerce' requires too many type annotations.
>
> Would it make sense to generalize the type so it's clear that one argument is unused?
>
> (#.) :: Coercible b c => p b c -> (a -> b) -> (a -> c)
> (.#) :: Coercible a b => (b -> c) -> p a b -> (a -> c)
>
> Li-yao
>
>> On 04/20/2018 03:56 PM, Daniel Cartwright wrote:
>> (#.) :: Coercible b c => (b -> c) -> (a -> b) -> (a -> c)
>> (#.) _ = coerce
>> {-# INLINE (#.) #-}
>> (.#) :: Coercible a b => (b -> c) -> (a -> b) -> (a -> c)
>> (.#) f _ = coerce f
>> {-# INLINE (.#) #-}
>> The first of these is exported from Data.Functor.Util, and used in many
>> places inside of base for efficiency over '.' (compose), However no module
>> in base actually exports these. I have recently been using Data.Coerce more
>> frequently and think it would be useful to go ahead and export these from
>> somewhere in base.
>> For convenience, I will paste the note about (#.) from Data.Functor.Util:
>> "Note [Function coercion]
>> ~~~~~~~~~~~~~~~~~~~~~~~
>> Several functions here use (#.) instead of (.) to avoid potential efficiency
>> problems relating to #7542. The problem, in a nutshell:
>> If N is a newtype constructor, then N x will always have the same
>> representation as x (something similar applies for a newtype deconstructor).
>> However, if f is a function,
>> N . f = \x -> N (f x)
>> This looks almost the same as f, but the eta expansion lifts it--the lhs
>> could
>> be _|_, but the rhs never is. This can lead to very inefficient code.  Thus
>> we
>> steal a technique from Shachaf and Edward Kmett and adapt it to the current
>> (rather clean) setting. Instead of using  N . f,  we use  N #. f, which is
>> just
>> coerce f `asTypeOf` (N . f)
>> That is, we just *pretend* that f has the right type, and thanks to the
>> safety
>> of coerce, the type checker guarantees that nothing really goes wrong. We
>> still
>> have to be a bit careful, though: remember that #. completely ignores the
>> *value* of its left operand.
>> "
>> -------------- next part --------------
>> An HTML attachment was scrubbed...
>> URL: <http://mail.haskell.org/pipermail/libraries/attachments/20180420/c5646504/attachment-0001.html>
> _______________________________________________
> 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: Export (#.) and (.#) from Data.Coerce (Libraries Digest, Vol 176, Issue 8)

David Feuer
I don't personally think the slightly confusing appearance is worth worrying about. If inference works out, I like Li-yao's approach a lot.

On Apr 21, 2018 7:27 PM, "Edward Kmett" <[hidden email]> wrote:
Note: this way of indicating which argument is unused means that this confusingly looks almost precisely backwards relative to the more general code that created those names and usage pattern in the first place. (I don't have a particularly strong objection to allowing the same sort of tweak to that code, assuming type inference works out in practice for the major consumers of the combinators there. I don't really foresee a problem, but I've been surprised by interactions before.)

I do have some concern that exporting these incompatible versions from Data.Coerce would break a subset of the code that is using the more general combinators in profunctors. e.g. in the lens library these were coined for the code for prisms imports both.

This is why they were placed in a more obscure internal location to begin with as just the special case was needed by base and it was easier to write a copy locally than merge Profunctor to base.

-Edward

On Sat, Apr 21, 2018 at 10:16 AM, Andrew Martin <[hidden email]> wrote:
Generalizing the type like that helps a lot. I had skimmed the documentation before, but I didn’t immediately comprehend what it meant. When I read the type signatures you gave them, it immediately made sense.

Also, +1 on exporting these.

Sent from my iPhone

> On Apr 21, 2018, at 10:06 AM, Li-yao Xia <[hidden email]> wrote:
>
> That seems useful indeed! Using only 'coerce' requires too many type annotations.
>
> Would it make sense to generalize the type so it's clear that one argument is unused?
>
> (#.) :: Coercible b c => p b c -> (a -> b) -> (a -> c)
> (.#) :: Coercible a b => (b -> c) -> p a b -> (a -> c)
>
> Li-yao
>
>> On 04/20/2018 03:56 PM, Daniel Cartwright wrote:
>> (#.) :: Coercible b c => (b -> c) -> (a -> b) -> (a -> c)
>> (#.) _ = coerce
>> {-# INLINE (#.) #-}
>> (.#) :: Coercible a b => (b -> c) -> (a -> b) -> (a -> c)
>> (.#) f _ = coerce f
>> {-# INLINE (.#) #-}
>> The first of these is exported from Data.Functor.Util, and used in many
>> places inside of base for efficiency over '.' (compose), However no module
>> in base actually exports these. I have recently been using Data.Coerce more
>> frequently and think it would be useful to go ahead and export these from
>> somewhere in base.
>> For convenience, I will paste the note about (#.) from Data.Functor.Util:
>> "Note [Function coercion]
>> ~~~~~~~~~~~~~~~~~~~~~~~
>> Several functions here use (#.) instead of (.) to avoid potential efficiency
>> problems relating to #7542. The problem, in a nutshell:
>> If N is a newtype constructor, then N x will always have the same
>> representation as x (something similar applies for a newtype deconstructor).
>> However, if f is a function,
>> N . f = \x -> N (f x)
>> This looks almost the same as f, but the eta expansion lifts it--the lhs
>> could
>> be _|_, but the rhs never is. This can lead to very inefficient code.  Thus
>> we
>> steal a technique from Shachaf and Edward Kmett and adapt it to the current
>> (rather clean) setting. Instead of using  N . f,  we use  N #. f, which is
>> just
>> coerce f `asTypeOf` (N . f)
>> That is, we just *pretend* that f has the right type, and thanks to the
>> safety
>> of coerce, the type checker guarantees that nothing really goes wrong. We
>> still
>> have to be a bit careful, though: remember that #. completely ignores the
>> *value* of its left operand.
>> "
>> -------------- next part --------------
>> An HTML attachment was scrubbed...
>> URL: <http://mail.haskell.org/pipermail/libraries/attachments/20180420/c5646504/attachment-0001.html>
> _______________________________________________
> 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: Export (#.) and (.#) from Data.Coerce

Joachim Breitner-2
In reply to this post by Daniel Cartwright
Hi,

Am Freitag, den 20.04.2018, 15:56 -0400 schrieb Daniel Cartwright:
> I have recently been using Data.Coerce more frequently and think it
> would be useful to go ahead and export these from somewhere in base.

I expect the target audience of these functions to be pretty small
(they need to know what coerce does, they need to care and know about
the problem with composing newtype constructors with functions etc.) I
don’t think any of these will struggle to define their (#.) locally –
or simply call coerce directly on `f`, without specifying the unused
newtype constructor.

I am, however, worried about people who are not the target audience to
see these operators and shoot in their foot with them (e.g. passing a
function that “does something” as the first argument to #. and then
being very confused that things don’t work.).

The benefits don’t obviously outweigh the risks, so a mild hesitant -1
from me.

Cheers,
Joachim

--
Joachim “nomeata” Breitner
  [hidden email]
  https://www.joachim-breitner.de/

_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Export (#.) and (.#) from Data.Coerce (Libraries Digest, Vol 176, Issue 8)

Edward Kmett-2
In reply to this post by David Feuer
It looks like inference works out. 

I've hacked up profunctors HEAD in a similar manner and pre-emptively narrowed my Data.Coerce imports there in case we do decide to export these from a more common location.

I did have to drop support for ghc < 7.8 to get the more general signatures to work out nicely though, as the old default definitions aren't valid there afterwards.

-Edward

On Sat, Apr 21, 2018 at 7:44 PM, David Feuer <[hidden email]> wrote:
I don't personally think the slightly confusing appearance is worth worrying about. If inference works out, I like Li-yao's approach a lot.

On Apr 21, 2018 7:27 PM, "Edward Kmett" <[hidden email]> wrote:
Note: this way of indicating which argument is unused means that this confusingly looks almost precisely backwards relative to the more general code that created those names and usage pattern in the first place. (I don't have a particularly strong objection to allowing the same sort of tweak to that code, assuming type inference works out in practice for the major consumers of the combinators there. I don't really foresee a problem, but I've been surprised by interactions before.)

I do have some concern that exporting these incompatible versions from Data.Coerce would break a subset of the code that is using the more general combinators in profunctors. e.g. in the lens library these were coined for the code for prisms imports both.

This is why they were placed in a more obscure internal location to begin with as just the special case was needed by base and it was easier to write a copy locally than merge Profunctor to base.

-Edward

On Sat, Apr 21, 2018 at 10:16 AM, Andrew Martin <[hidden email]> wrote:
Generalizing the type like that helps a lot. I had skimmed the documentation before, but I didn’t immediately comprehend what it meant. When I read the type signatures you gave them, it immediately made sense.

Also, +1 on exporting these.

Sent from my iPhone

> On Apr 21, 2018, at 10:06 AM, Li-yao Xia <[hidden email]> wrote:
>
> That seems useful indeed! Using only 'coerce' requires too many type annotations.
>
> Would it make sense to generalize the type so it's clear that one argument is unused?
>
> (#.) :: Coercible b c => p b c -> (a -> b) -> (a -> c)
> (.#) :: Coercible a b => (b -> c) -> p a b -> (a -> c)
>
> Li-yao
>
>> On 04/20/2018 03:56 PM, Daniel Cartwright wrote:
>> (#.) :: Coercible b c => (b -> c) -> (a -> b) -> (a -> c)
>> (#.) _ = coerce
>> {-# INLINE (#.) #-}
>> (.#) :: Coercible a b => (b -> c) -> (a -> b) -> (a -> c)
>> (.#) f _ = coerce f
>> {-# INLINE (.#) #-}
>> The first of these is exported from Data.Functor.Util, and used in many
>> places inside of base for efficiency over '.' (compose), However no module
>> in base actually exports these. I have recently been using Data.Coerce more
>> frequently and think it would be useful to go ahead and export these from
>> somewhere in base.
>> For convenience, I will paste the note about (#.) from Data.Functor.Util:
>> "Note [Function coercion]
>> ~~~~~~~~~~~~~~~~~~~~~~~
>> Several functions here use (#.) instead of (.) to avoid potential efficiency
>> problems relating to #7542. The problem, in a nutshell:
>> If N is a newtype constructor, then N x will always have the same
>> representation as x (something similar applies for a newtype deconstructor).
>> However, if f is a function,
>> N . f = \x -> N (f x)
>> This looks almost the same as f, but the eta expansion lifts it--the lhs
>> could
>> be _|_, but the rhs never is. This can lead to very inefficient code.  Thus
>> we
>> steal a technique from Shachaf and Edward Kmett and adapt it to the current
>> (rather clean) setting. Instead of using  N . f,  we use  N #. f, which is
>> just
>> coerce f `asTypeOf` (N . f)
>> That is, we just *pretend* that f has the right type, and thanks to the
>> safety
>> of coerce, the type checker guarantees that nothing really goes wrong. We
>> still
>> have to be a bit careful, though: remember that #. completely ignores the
>> *value* of its left operand.
>> "
>> -------------- next part --------------
>> An HTML attachment was scrubbed...
>> URL: <http://mail.haskell.org/pipermail/libraries/attachments/20180420/c5646504/attachment-0001.html>
> _______________________________________________
> 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