remove instance NFData (a -> b)

[amigalemming]

I suggested to remove the instance NFData (a -> b) because it cannot be implemented properly. I think the proposal got broad support:
https://mail.haskell.org/libraries/2016-May/026961.html
We have still to decide whether to drop the instance or replace it by an unimplementable one. The latter one would have the advantage that people see that the instance is omitted by intention. We would need a major version bump. I can setup a pull request if you like.

[hvr]

tbh, I'd like the @haskell/core-libraries-committee to sign off on this.

Personally, I'd prefer an unimplementable instance, as otherwise all it takes is one orphan instance hidden somewhere in a popular package to thwart this change. And even worse, if more than one orphan instance appears, we would risk ending up in an even worse situation than we're now in :-/

(/cc'ing @RyanGlScott as he wasn't yet part of the @haskell/core-libraries-committee github team at time of writing)

[ekmett]

I have no objection to removing the instance, but I'm not a fan of the idea
of making it unimplementable.

Yes, one popular package could bring it back from the dead, or bring into
scope a variant that enumerates the entire domain of a function and
memoizes all results, but if it can weather the storm of popular opinion
then perhaps it deserves to come back. This scenario is unlikely given the
complete absence of interest in the current instance.

We have an open world. Orphan instances are deeply unpopular and
anti-modular. If someone needs the instance, let them have it, it won't go
far enough upstream to matter.

-Edward

On Mon, May 23, 2016 at 6:29 AM, Herbert Valerio Riedel <
notifications@github.com> wrote:

tbh, I'd like the @haskell/core-libraries-committee
https://github.com/orgs/haskell/teams/core-libraries-committee to sign
off on this.

Personally, I'd prefer an unimplementable instance, as otherwise all it
takes is one orphan instance hidden somewhere in a popular package to
thwart this change. And even worse, if more than one orphan instance
appears, we would risk ending up in an even worse situation than we're now
in :-/

(/cc'ing @RyanGlScott https://github.com/RyanGlScott as he wasn't yet
part of @haskell/core-libraries-committee
https://github.com/orgs/haskell/teams/core-libraries-committee at time
of writing)

—
You are receiving this because you are on a team that was mentioned.
Reply to this email directly or view it on GitHub
#16 (comment)

[amigalemming]

On Mon, 23 May 2016, Edward Kmett wrote:

We have an open world. Orphan instances are deeply unpopular and
anti-modular. If someone needs the instance, let them have it, it won't
go far enough upstream to matter.

There needs to be only one package in any of hundred packages I import
defining this instance as an orphan and then this disables my type safety
check. I prefer the non-implementable instance and if someone needs the
enumerating instance he can implement it for a newtype wrapper of the
function type.

[hvr]

@amigalemming afaik you suggested to implement some warning facility to annotate undesirable/questionable instances; can you think of a variant which would help here?

[ekmett]

And you can just as easily implement an orphan instance module that
provides the impossible instance with the same head.

class Don'tExportMe where boom :: a
instance Don'tExportMe => NFData (a -> b) where
rnf = boom

and import that to know that the other isn't being used in your code,
because now you'll get a overlapping instance head.

I'd, however, treat whatever package exported this instance as just as
questionable as one that provided the other.

NFData provides no guarantees that it "really" does anything. There are
lots of such "mildly dangerous instances" that may not be as fully strict
as you'd like for NFData. You'll never rule them all out.

For the scenario you fear to come to pass you have to make two lapses in
judgment. First you have to depend on a package that provides the instance,
and then you have to write code that depends on the instance existing.

That seems well balanced against the fact that someone using criterion
might very well want to define the instance for NFData (a -> b) locally in
their benchmark suite, regardless of whether or not you believe the
instance should exist.

-Edward

On Mon, May 23, 2016 at 7:00 AM, amigalemming notifications@github.com
wrote:

On Mon, 23 May 2016, Edward Kmett wrote:

We have an open world. Orphan instances are deeply unpopular and
anti-modular. If someone needs the instance, let them have it, it won't
go far enough upstream to matter.

There needs to be only one package in any of hundred packages I import
defining this instance as an orphan and then this disables my type safety
check. I prefer the non-implementable instance and if someone needs the
enumerating instance he can implement it for a newtype wrapper of the
function type.

—
You are receiving this because you are on a team that was mentioned.
Reply to this email directly or view it on GitHub
#16 (comment)

[snoyberg]

I agree with Edward here, my vote goes with his stance.

On Mon, May 23, 2016, 3:33 PM Edward Kmett notifications@github.com wrote:

And you can just as easily implement an orphan instance module that
provides the impossible instance with the same head.

class Don'tExportMe where boom :: a
instance Don'tExportMe => NFData (a -> b) where
rnf = boom

and import that to know that the other isn't being used in your code,
because now you'll get a overlapping instance head.

I'd, however, treat whatever package exported this instance as just as
questionable as one that provided the other.

NFData provides no guarantees that it "really" does anything. There are
lots of such "mildly dangerous instances" that may not be as fully strict
as you'd like for NFData. You'll never rule them all out.

For the scenario you fear to come to pass you have to make two lapses in
judgment. First you have to depend on a package that provides the instance,
and then you have to write code that depends on the instance existing.

That seems well balanced against the fact that someone using criterion
might very well want to define the instance for NFData (a -> b) locally in
their benchmark suite, regardless of whether or not you believe the
instance should exist.

-Edward

On Mon, May 23, 2016 at 7:00 AM, amigalemming notifications@github.com
wrote:

On Mon, 23 May 2016, Edward Kmett wrote:

We have an open world. Orphan instances are deeply unpopular and
anti-modular. If someone needs the instance, let them have it, it won't
go far enough upstream to matter.

There needs to be only one package in any of hundred packages I import
defining this instance as an orphan and then this disables my type safety
check. I prefer the non-implementable instance and if someone needs the
enumerating instance he can implement it for a newtype wrapper of the
function type.

—
You are receiving this because you are on a team that was mentioned.
Reply to this email directly or view it on GitHub
#16 (comment)

—
You are receiving this because you are on a team that was mentioned.

Reply to this email directly or view it on GitHub
#16 (comment)

[dolio]

I'm also for no instance at this point. If you think the existing instance is bad, it's better for no instance to exist, so that you get an error if you accidentally try to use it. The other instances I can think of have roughly the same negatives as the existing one. You don't get a compile-time complaint, you just have to figure out what went wrong if your program ever exercises the instance (and either blows up or loops uselessly for a very long time). And the instance that doesn't just blow up requires introducing a new class to implement ideally, and then getting people to implement it.

[amigalemming]

On Mon, 23 May 2016, dolio wrote:

I'm also for no instance at this point. If you think the existing
instance is bad, it's better for no instance to exist, so that you get
an error if you accidentally try to use it. The other instances I can
think of have roughly the same negatives as the existing one. You don't
get a compile-time complaint,

I definitely want a compile-time complaint, and I think this can be better
done with an explicitly forbidden instance. I think of something similar
to Edward, only in Haskell 98, e.g.

class NotImplementable a where -- not exported
instance NotImplementable a => NFData (a -> b) where

This instance tells any programmer that the instance cannot be defined
anymore and that this is by intent.

[amigalemming]

On Mon, 23 May 2016, Herbert Valerio Riedel wrote:

@amigalemming afaik you suggested to implement some warning facility to
annotate undesirable/questionable instances; can you think of a variant
which would help here?

I proposed this one:
https://ghc.haskell.org/trac/ghc/ticket/11796

It would solve the issue here, too, but it is not implemented in GHC, it
did not even start a discussion, so far.

[ekmett]

My point about that instance is that it is something that you are just as
free to implement as someone who wants to implement the instance you don't
like.

Just to be clear, I was not advocating that the instance I mentioned be
placed in base.

I was mentioning that if you wanted to rule out the instance in question,
you could write your own orphan instance in your own package somewhere, and
it'd infect the global context and conflict with any other attempted
instance.

So you can either, simply check to make sure that your code still compiles
with any version of your dependencies you know doesn't have the instance
around, or you can jump through hoops and create one of the orphan
'impossible' instances described so far.

Only in the latter case do you break users who just want some instance
like instance
NFData (a -> b) locally in their criterion benchmarks, and they asked for
it by depending on your code.

-Edward

On Mon, May 23, 2016 at 9:44 AM, amigalemming notifications@github.com
wrote:

On Mon, 23 May 2016, dolio wrote:

I'm also for no instance at this point. If you think the existing
instance is bad, it's better for no instance to exist, so that you get
an error if you accidentally try to use it. The other instances I can
think of have roughly the same negatives as the existing one. You don't
get a compile-time complaint,

I definitely want a compile-time complaint, and I think this can be better
done with an explicitly forbidden instance. I think of something similar
to Edward, only in Haskell 98, e.g.

class NotImplementable a where -- not exported
instance NotImplementable a => NFData (a -> b) where

This instance tells any programmer that the instance cannot be defined
anymore and that this is by intent.

—
You are receiving this because you are on a team that was mentioned.
Reply to this email directly or view it on GitHub
#16 (comment)

[amigalemming]

On Mon, 23 May 2016, Edward Kmett wrote:

Just to be clear, I was not advocating that the instance I mentioned be
placed in base.

I understood it this way.

Only in the latter case do you break users who just want some instance
like instance NFData (a -> b) locally in their criterion benchmarks, and
they asked for it by depending on your code.

Is this a frequent usecase? How about using a newtype wrapper there? The
deepseq package could provide the wrapper even by itself.

[ekmett]

The criterion example was one usecase. One that enumerates all of the
inputs and memoizes a function's results is another that has the same head
shape that also conflicts. Sure, we could hide it behind a newtype. We
could hide every instance for (->) behind a newtype, but we don't.

But if you can build with any version of your dependencies that doesn't
have the instance, then you can't be relying on it.

You'll only run into this problem when you explicitly call rnf on a
function and when someone you don't like that you depend upon brings an
instance into scope. That frankly strikes me as pretty far removed from an
active concern, and more a theoretical exercise.

-Edward

On Mon, May 23, 2016 at 10:38 AM, amigalemming notifications@github.com
wrote:

On Mon, 23 May 2016, Edward Kmett wrote:

Just to be clear, I was not advocating that the instance I mentioned be
placed in base.

I understood it this way.

Only in the latter case do you break users who just want some instance
like instance NFData (a -> b) locally in their criterion benchmarks, and
they asked for it by depending on your code.

Is this a frequent usecase? How about using a newtype wrapper there? The
deepseq package could provide the wrapper even by itself.

—
You are receiving this because you are on a team that was mentioned.
Reply to this email directly or view it on GitHub
#16 (comment)

[amigalemming]

On Mon, 23 May 2016, Edward Kmett wrote:

The criterion example was one usecase. One that enumerates all of the
inputs and memoizes a function's results is another that has the same head
shape that also conflicts. Sure, we could hide it behind a newtype. We
could hide every instance for (->) behind a newtype, but we don't.

The existence of different possible implementations is an argument pro
dedicated newtype wrappers for me.

You'll only run into this problem when you explicitly call rnf on a
function and when someone you don't like that you depend upon brings an
instance into scope. That frankly strikes me as pretty far removed from an
active concern, and more a theoretical exercise.

I want to be sure that I do not accidentally call 'rnf' or that a library
function calls 'rnf' for me on any structure, where a function is
contained somewhere deep in it, which can happen if only one of hundred
transitively imported packages defines an orphan NFData (a -> b) instance.
Even if I check the absense of such an orphan instance today, it may
change easily if one of the transitively imported packages extends its
imports.

[ekmett]

They can do that anyway if they just define their instance for any composite structure in the middle by hand. Even your newtype solution is evidence of this. You get no such transitive guarantee.

Sent from my iPhone

On May 23, 2016, at 12:03 PM, amigalemming notifications@github.com wrote:

On Mon, 23 May 2016, Edward Kmett wrote:

The criterion example was one usecase. One that enumerates all of the
inputs and memoizes a function's results is another that has the same head
shape that also conflicts. Sure, we could hide it behind a newtype. We
could hide every instance for (->) behind a newtype, but we don't.

The existence of different possible implementations is an argument pro
dedicated newtype wrappers for me.

You'll only run into this problem when you explicitly call rnf on a
function and when someone you don't like that you depend upon brings an
instance into scope. That frankly strikes me as pretty far removed from an
active concern, and more a theoretical exercise.

I want to be sure that I do not accidentally call 'rnf' or that a library
function calls 'rnf' for me on any structure, where a function is
contained somewhere deep in it, which can happen if only one of hundred
transitively imported packages defines an orphan NFData (a -> b) instance.
Even if I check the absense of such an orphan instance today, it may
change easily if one of the transitively imported packages extends its
imports.
—
You are receiving this because you are on a team that was mentioned.
Reply to this email directly or view it on GitHub