Re: Overlapping and incoherent instances
To me, perhaps naively, IncoherentInstances is way more scary than
OverlappingInstances.
What behavior do these new pragmas have? In particular, will it be an error if
there is no single most specific instance? And can the user decide whether it is
an error?
Twan
On 29/07/14 11:11, Simon Peyton Jones wrote:
Friends
One of GHC’s more widely-used features is overlapping (and sometimes incoherent)
instances. The user-manual documentation is here
http://www.haskell.org/ghc/docs/latest/html/users_guide/type-class-extensions.html#instance-overlap.
The use of overlapping/incoherent instances is controlled by LANGUAGE pragmas:
OverlappingInstances and IncoherentInstances respectively.
However the overlap/incoherent-ness is a property of the **instance
declaration** itself, and has been for a long time. Using LANGUAGE
OverlappingInstances simply sets the “I am an overlapping instance” flag for
every instance declaration in that module.
This is a Big Hammer. It give no clue about **which** particular instances the
programmer is expecting to be overlapped, nor which are doing the
overlapping.It brutally applies to every instance in the module. Moreover,
when looking at an instance declaration, there is no nearby clue that it might
be overlapped. The clue might be in the command line that compiles that module!
Iavor has recently implemented per-instance-declaration pragmas, so you can say
instance {-# OVERLAPPABLE #-} Show a = Show [a] where …
instance {-# OVERLAPPING #-} Show [Char] where …
This is much more precise (it affects only those specific instances) and it is
much clearer (you see it when you see the instance declaration).
This new feature will be in GHC 7.10 and I’m sure you will be happy about that.
*But I propose also to deprecate the LANGUAGE pragmas OverlappingInstances and
IncoherentInstances*, as way to encourage everyone to use the new feature
instead of the old big hammer. The old LANGUAGE pragmas will continue to work,
of course, for at least another complete release cycle. We could make that two
cycles if it was helpful.
However, if you want deprecation-free libraries, it will entail a wave of
library updates.
This email is just to warn you, and to let you yell if you think this is a bad
idea. It would actually not be difficult to retain the old LANGUAGE pragmas
indefinitely – it just seems wrong not to actively push authors in the right
direction.
These deprecations of course popped up in the test suite, so I’ve been replacing
them with per-instance pragmas there too. Interestingly in some cases, when
looking for which instances needed the pragmas, I found…none. So
OverlappingInstances was entirely unnecessary. Maybe library authors will find
that too!
Simon
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Overlapping and incoherent instances
On Mon, Aug 11, 2014 at 11:36 AM, Twan van Laarhoven twa...@gmail.com wrote: To me, perhaps naively, IncoherentInstances is way more scary than OverlappingInstances. It might be a bit naive. Most things that incoherent instances would allow are allowed with overlapping instances so long as you partition your code into two modules. So unless such a partitioning is impossible, overlapping instances are almost as scary as incoherent instances (unless the module separation somehow makes it less scary). And actually, with the way GHC handles instances, you can get more incoherent behavior than incoherent instances allow without enabling any extensions, just using modules: module A where class Foo a where foo :: a module B where import A instance F oo Int where foo = 5 bar :: Int ; bar = foo module C where import A instance Foo Int where foo = 6 baz :: Int ; baz = foo module D where import B import C quux = bar + baz -- 11 -- Dan ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Overlapping and incoherent instances
Hello, this is clearly a bug in GHC: where `B` and `C` are imported, there should have been an error, saying that there is a duplicate instance of `Foo Int`. If there is no ticket for this already, could you please add one? -Iavor On Mon, Aug 11, 2014 at 12:35 PM, Dan Doel dan.d...@gmail.com wrote: On Mon, Aug 11, 2014 at 11:36 AM, Twan van Laarhoven twa...@gmail.com wrote: To me, perhaps naively, IncoherentInstances is way more scary than OverlappingInstances. It might be a bit naive. Most things that incoherent instances would allow are allowed with overlapping instances so long as you partition your code into two modules. So unless such a partitioning is impossible, overlapping instances are almost as scary as incoherent instances (unless the module separation somehow makes it less scary). And actually, with the way GHC handles instances, you can get more incoherent behavior than incoherent instances allow without enabling any extensions, just using modules: module A where class Foo a where foo :: a module B where import A instance F oo Int where foo = 5 bar :: Int ; bar = foo module C where import A instance Foo Int where foo = 6 baz :: Int ; baz = foo module D where import B import C quux = bar + baz -- 11 -- Dan ___ Libraries mailing list librar...@haskell.org http://www.haskell.org/mailman/listinfo/libraries ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Overlapping and incoherent instances
This has been reported: https://ghc.haskell.org/trac/ghc/ticket/8338 But it's really not clear what the solution is! Richard On Aug 11, 2014, at 9:27 PM, Iavor Diatchki iavor.diatc...@gmail.com wrote: Hello, this is clearly a bug in GHC: where `B` and `C` are imported, there should have been an error, saying that there is a duplicate instance of `Foo Int`. If there is no ticket for this already, could you please add one? -Iavor On Mon, Aug 11, 2014 at 12:35 PM, Dan Doel dan.d...@gmail.com wrote: On Mon, Aug 11, 2014 at 11:36 AM, Twan van Laarhoven twa...@gmail.com wrote: To me, perhaps naively, IncoherentInstances is way more scary than OverlappingInstances. It might be a bit naive. Most things that incoherent instances would allow are allowed with overlapping instances so long as you partition your code into two modules. So unless such a partitioning is impossible, overlapping instances are almost as scary as incoherent instances (unless the module separation somehow makes it less scary). And actually, with the way GHC handles instances, you can get more incoherent behavior than incoherent instances allow without enabling any extensions, just using modules: module A where class Foo a where foo :: a module B where import A instance Foo Int where foo = 5 bar :: Int ; bar = foo module C where import A instance Foo Int where foo = 6 baz :: Int ; baz = foo module D where import B import C quux = bar + baz -- 11 -- Dan ___ Libraries mailing list librar...@haskell.org http://www.haskell.org/mailman/listinfo/libraries ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Overlapping and incoherent instances
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 I suppose that -XOverlappingInstances could mean silently honour OVERLAPPABLE/OVERLAPPING pragmas, while lacking it would mean honour OVERLAPPABLE/OVERLAPPING pragmas, but emit noisy warnings or even don't honour them and warn. But that is different to the behaviour today, so we'd need a new LANGUAGE pragma. Perhaps -XHonourOverlappingInstances or something. This would be a reasonable alternative to the keyword-based solution. At least for now. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iQIcBAEBCAAGBQJT45F5AAoJENEcKRHOUZzewwwQALUiK60sbIC6j5nbXHPCeau8 bN80pmhUL11lAyI7OCSQyV8S9AU7ikgaUPyKwk/cx/TtKQGLwghWFZlRCoCRrplk dmGsSCw2LN4GElHL22EcyELPcx74lknz3tmQuZg4oAUXm1h2w8774L3iHOE4Ompg 9gYzuOo8Ii3oHJ6fjIL0DwGWp92F8NrTPeQmziBOPHAgQYVFO8QMncXcOGtdIZUb PQr0szr9HLkcwKSrYoxvvZBqEj6AM0xj+KhX87NEnQ08EaY6FO/Dhm4mi7X/A5Ca khwsjwId0qR6C4vs7QyYnaK3yiUFlZMUlXdUhpRG3wWFHseb3m9tX2a2ewE30jPl TgnoU5NYphijMWXpc3p06D5Zj0lT6L++Y3Ez8CS+0QpBPG9c0CJnLqXFQ5CNbl+9 Ryzpg7ltg5vhtq7BLwcz+V87lzc4KYm/tyqEVvxN59W6XLuLLe4tW6NL9vLDl9Rg /3vMRYKZBa+0we7jAi/wYbdks7g+9sqpiLqke5m73a5F2j/TTl4BrkIj2vG0KrP+ G9eJC1aieUbfPXXwXWSJh8binJNp//qWs7rILDsx4r0o1QR245uT5WzwkwapXmE8 ZYuXsVcc1/mS1ZneOP6zn0QOlRcUJ0A5dFxQg69hsXpD+MM226r/57P3eI9XhLRN W+DNBoXbr9mp8eNGjl6O =CFkA -END PGP SIGNATURE- ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Overlapping and incoherent instances
Simon Peyton Jones wrote: | On a largely unrelated note, here's another thing I don't | understand: when is OVERLAPPABLE at one instance declaration | preferable to using only OVERLAPPING at the instance declarations | that overlap it? It's a user decision. GHC allows - OVERLAPPABLE at the instance that is being overlapped, or - OVERLAPPING at the instance that is doing the overlapping, or - both I'm curious how this affects simplification of contexts. If I have class Foo a instance Foo a = Foo [a] then GHC will simplify foo :: Foo [a] = a - () to foo :: Foo a = a - () Would this be prevented by declaring the Foo [a] instance as overlappable? In other words, does OVERLAPPABLE instruct the type checker to expect overlapping instances even if none of them are visible? Cheers, Bertram ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: Overlapping and incoherent instances
| overlappable? In other words, does OVERLAPPABLE instruct the
| type checker to expect overlapping instances even if none of
| them are visible?
No, not at the moment.
Suppose we have
class C a where
op :: a - String
instance {-# OVERLAPPABLE #-} C a = C [a] where
op x = [a]
instance {-# OVERLAPPING #-} C [Int] where
op x = [Int]
foo :: C a = a - String
foo x = op [x] ++ urk
Then we (rightly) get an overlapping instance error when we try to solve the (C
[a]) constraint arising from op [a] in foo's RHS.
But if we omit the type signature for foo, then GHC will (as before) not
simplify the (C [a]) constraint, for the same reason, but because it's unsolved
GHC will abstract over it to give the inferred type
foo :: C [a] = a - String
But this only happens if the overlapping instance is visible here. If the C
[Int] instance is in some other module, then GHC will infer foo :: C a = a -
String.
Your point is that if the C [a] instance is marked OVERLAPPABLE, perhaps GHC
should decline to simplify it, on the grounds that a more specific instance
might appear. But then the (C [a]) instance would never, ever be used! (On
the grounds that it might be overlapped by some as-yet-unseen instance. So I
don't think this would work.
In any case, if the current behaviour doesn't seem precisely defined by the
user manual, could you suggest some words that would make it clearer?
Simon
| -Original Message-
| From: Glasgow-haskell-users [mailto:glasgow-haskell-users-
| boun...@haskell.org] On Behalf Of Bertram Felgenhauer
| Sent: 07 August 2014 16:25
| To: glasgow-haskell-users@haskell.org
| Subject: Re: Overlapping and incoherent instances
|
| Simon Peyton Jones wrote:
| | On a largely unrelated note, here's another thing I don't
| | understand: when is OVERLAPPABLE at one instance declaration
| | preferable to using only OVERLAPPING at the instance declarations
| | that overlap it?
|
| It's a user decision. GHC allows
|- OVERLAPPABLE at the instance that is being overlapped, or
|- OVERLAPPING at the instance that is doing the overlapping, or
|- both
|
| I'm curious how this affects simplification of contexts. If I have
|
| class Foo a
| instance Foo a = Foo [a]
|
| then GHC will simplify
|
| foo :: Foo [a] = a - ()
|
| to
|
| foo :: Foo a = a - ()
|
| Would this be prevented by declaring the Foo [a] instance as
| overlappable? In other words, does OVERLAPPABLE instruct the
| type checker to expect overlapping instances even if none of
| them are visible?
|
| Cheers,
|
| Bertram
| ___
| Glasgow-haskell-users mailing list
| Glasgow-haskell-users@haskell.org
| http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: Overlapping and incoherent instances
| Here's one concern I have with the deprecation of
| -XOverlappingInstances: I don't like overlapping instances, I find
| them confusing and weird and prefer to use code that doesn't
| include them, because they violate my expectations about how type
| classes work. When there is a single LANGUAGE pragma, that's a
| simple, easily-checkable signpost of this code uses techniques
| that Ben doesn't understand. When it is all controlled by pragmas
| I basically have to check every instance declaration individually.
I see your point. Though you could just grep for OVERLAP!
I suppose that -XOverlappingInstances could mean silently honour
OVERLAPPABLE/OVERLAPPING pragmas, while lacking it would mean honour
OVERLAPPABLE/OVERLAPPING pragmas, but emit noisy warnings or even don't
honour them and warn.
But that is different to the behaviour today, so we'd need a new LANGUAGE
pragma. Perhaps -XHonourOverlappingInstances or something.
My sense is that the extra faff is not worth it.
| On a largely unrelated note, here's another thing I don't
| understand: when is OVERLAPPABLE at one instance declaration
| preferable to using only OVERLAPPING at the instance declarations
| that overlap it?
It's a user decision. GHC allows
- OVERLAPPABLE at the instance that is being overlapped, or
- OVERLAPPING at the instance that is doing the overlapping, or
- both
Another possible choice would be to require both. One or t'other wouldn't do.
But the current choice (with the LANGUAGE pragmas -XOverlappingInstances) is
the either/or choice, and I had no user pressure to change that. There *is*
user pressure for the either/or semantics, so that you can *later* add an
un-anticipated OVERLAPPING instance.
| {-# LANGUAGE FlexibleInstances #-}
| module M where
| class C a where f :: a - a
| instance C a where f x = x
| instance C Int where f x = x + 1
|
| I suspect many people have the intuition that NoOverlappingInstances
| should forbid the above, but in fact OverlappingInstances or no only
| controls instance *resolution*. I imagine you all already knew this
| but I did not until I carefully reread things.
It's pretty clearly stated in the manual, but I'd be delighted to add a
paragraph or two, or an example, if you can draft something and say where a
good place for it would be (ie where you'd have looked).
Thanks
Simon
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Overlapping and incoherent instances
On Sat, Aug 02, 2014 at 08:51:57PM +0100, Ben Millwood wrote:
On Sat, Aug 02, 2014 at 04:27:14PM +0100, Ben Millwood wrote:
On Thu, Jul 31, 2014 at 07:20:31AM +, Simon Peyton Jones wrote:
My main motivation was to signal the proposed deprecation of the global per-module flag
-XoverlappingInstances. Happily people generally seem fine with this. It is, after
all, precisely what deprecations are for (the old thing still works for now, but it
won't do so for ever, and you should change as soon as is convenient).
Here's one concern I have with the deprecation of
-XOverlappingInstances: I don't like overlapping instances, I find
them confusing and weird and prefer to use code that doesn't
include them, because they violate my expectations about how type
classes work. When there is a single LANGUAGE pragma, that's a
simple, easily-checkable signpost of this code uses techniques
that Ben doesn't understand. When it is all controlled by pragmas
I basically have to check every instance declaration individually.
On a largely unrelated note, here's another thing I don't
understand: when is OVERLAPPABLE at one instance declaration
preferable to using only OVERLAPPING at the instance declarations
that overlap it? In the latter model, as long as none of the
instances I write have pragmas, I can be sure none of them overlap.
In the former model, any instance I write for an existing typeclass
might overlap another instance, even if I don't want it to. Do we
have any specific use cases in mind for OVERLAPPABLE?
___
Libraries mailing list
librar...@haskell.org
http://www.haskell.org/mailman/listinfo/libraries
When I originally sent this mail I wasn't subscribed to the GHC
lists, so I went and fixed that and am now resending.
Good grief, and then I sent from the wrong address. Sorry for the noise.
Addendum: I was surprised by the behaviour of overlapping instances
when I went and looked closer at it.
{-# LANGUAGE FlexibleInstances #-}
module M where
class C a where f :: a - a
instance C a where f x = x
instance C Int where f x = x + 1
I suspect many people have the intuition that NoOverlappingInstances
should forbid the above, but in fact OverlappingInstances or no only
controls instance *resolution*. I imagine you all already knew this
but I did not until I carefully reread things.
As someone who dislikes overlapping type class instances, I am
finding them harder to avoid than I at first thought :(
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Overlapping and incoherent instances
This is great! It's nice to see something finer grain.
We'd of course like to bring Safe Haskell into the picture though! Our
concern with the new design as it stands is the OVERLAPS flag. We'd
prefer it to be eliminated in favor of requiring developers specify
both OVERLAPPABLE and OVERLAPS if that truly is their intention.
# Why?
## Long Version
https://ghc.haskell.org/trac/ghc/wiki/SafeHaskell/NewOverlappingInstances#NewOverlappingInstances--a.k.aInstanceSpecificPragmas
## Short Version (kind-of)
The security implications of OVERLAPPABLE vs. OVERLAPPING are fairly
different. Remember, in Safe Haskell we apply a policy of only
allowing instances from a module M compiled with `-XSafe` to overlap
other instances from module M. If it overlaps (and is the most
specific overlap) instances from modules other than M then we don't
allow this to succeed. This is done to ensure that untrusted code
compiled with `-XSafe` can't alter the behavior of existing code, some
of which may be part of the TCB and security critical.
Brining the new finer grained pragmas into the story we get the following:
* OVERLAPPABLE is the programmer communicating that they can be
overlapped, an open instance if you will. We want to relax the above
restriction and allow instances from `-XSafe` modules to overlap
instances from their own module AND instances declared OVERLAPPABLE
that reside in any module.
* OVERLAPPING is the programming simply declaring they may overlap
less specific instances. We want to keep the above restriction for
these instances. That is, a instance I1 from a `-XSafe` module M won't
be able to overlap as the most specific instance, a instance I2 from
another module if I2 is marked as OVERLAPPING.
This distinction enables new encodings in Safe Haskell by allowing
security library authors to distinguish how untrusted code can overlap
their instances. In some way giving them open vs closed instances.
This distinction is subtle and important. Having a pragma OVERLAPS
that implies both glosses over this and will encourage developers to
use this without much thought.
## Safe Inference
We can also safely infer a module that only has OVERLAPPABLE instances
as safe, while ones that contain OVERLAPPING or OVERLAPS instances
must be regarded as unsafe since there is a difference in semantics of
these pragmas under Safe vs Unsafe.
So we also have an advantage if developers are more specific about
what they want, than just defaulting to OVERLAPS.
Cheers,
David
On 29 July 2014 02:11, Simon Peyton Jones simo...@microsoft.com wrote:
Friends
One of GHC’s more widely-used features is overlapping (and sometimes
incoherent) instances. The user-manual documentation is here.
The use of overlapping/incoherent instances is controlled by LANGUAGE
pragmas: OverlappingInstances and IncoherentInstances respectively.
However the overlap/incoherent-ness is a property of the *instance
declaration* itself, and has been for a long time. Using LANGUAGE
OverlappingInstances simply sets the “I am an overlapping instance” flag for
every instance declaration in that module.
This is a Big Hammer. It give no clue about *which* particular instances
the programmer is expecting to be overlapped, nor which are doing the
overlapping.It brutally applies to every instance in the module.
Moreover, when looking at an instance declaration, there is no nearby clue
that it might be overlapped. The clue might be in the command line that
compiles that module!
Iavor has recently implemented per-instance-declaration pragmas, so you can
say
instance {-# OVERLAPPABLE #-} Show a = Show [a] where …
instance {-# OVERLAPPING #-} Show [Char] where …
This is much more precise (it affects only those specific instances) and it
is much clearer (you see it when you see the instance declaration).
This new feature will be in GHC 7.10 and I’m sure you will be happy about
that. But I propose also to deprecate the LANGUAGE pragmas
OverlappingInstances and IncoherentInstances, as way to encourage everyone
to use the new feature instead of the old big hammer. The old LANGUAGE
pragmas will continue to work, of course, for at least another complete
release cycle. We could make that two cycles if it was helpful.
However, if you want deprecation-free libraries, it will entail a wave of
library updates.
This email is just to warn you, and to let you yell if you think this is a
bad idea. It would actually not be difficult to retain the old LANGUAGE
pragmas indefinitely – it just seems wrong not to actively push authors in
the right direction.
These deprecations of course popped up in the test suite, so I’ve been
replacing them with per-instance pragmas there too. Interestingly in some
cases, when looking for which instances needed the pragmas, I found…none. So
OverlappingInstances was entirely unnecessary. Maybe library authors will
find that too!
Simon
___
RE: Overlapping and incoherent instances
Friends, in sending my message below, I should also have sent a link to
https://ghc.haskell.org/trac/ghc/ticket/9242#comment:25
Comment 25 describes the semantics of OVERLAPPING/OVERLAPPABLE etc, which I
signally failed to do in my message below, leading to confusion in the follow
up messages. My apologies for that.
Some key points:
* There is a useful distinction between overlapping and overlappable,
but if you don't want to be bothered with it you can just say OVERLAPS (which
means both).
* Overlap between two candidate instances is allowed if either has the
relevant property. This is a bit sloppy, but reduces the annotation burden.
Actually, with this per-instance stuff I think it'd be perfectly defensible to
require both to be annotated, but that's a different discussion.
I hope that helps clarify.
I'm really pretty certain that the basic proposal here is good: it implements
the current semantics in a more fine-grained manner. My main motivation was to
signal the proposed deprecation of the global per-module flag
-XoverlappingInstances. Happily people generally seem fine with this. It is,
after all, precisely what deprecations are for (the old thing still works for
now, but it won't do so for ever, and you should change as soon as is
convenient).
Thanks
Simon
From: Libraries [mailto:libraries-boun...@haskell.org] On Behalf Of Simon
Peyton Jones
Sent: 29 July 2014 10:11
To: ghc-devs; GHC users; Haskell Libraries (librar...@haskell.org)
Subject: Overlapping and incoherent instances
Friends
One of GHC's more widely-used features is overlapping (and sometimes
incoherent) instances. The user-manual documentation is
herehttp://www.haskell.org/ghc/docs/latest/html/users_guide/type-class-extensions.html#instance-overlap.
The use of overlapping/incoherent instances is controlled by LANGUAGE pragmas:
OverlappingInstances and IncoherentInstances respectively.
However the overlap/incoherent-ness is a property of the *instance declaration*
itself, and has been for a long time. Using LANGUAGE OverlappingInstances
simply sets the I am an overlapping instance flag for every instance
declaration in that module.
This is a Big Hammer. It give no clue about *which* particular instances the
programmer is expecting to be overlapped, nor which are doing the overlapping.
It brutally applies to every instance in the module. Moreover, when looking
at an instance declaration, there is no nearby clue that it might be
overlapped. The clue might be in the command line that compiles that module!
Iavor has recently implemented per-instance-declaration pragmas, so you can say
instance {-# OVERLAPPABLE #-} Show a = Show [a] where ...
instance {-# OVERLAPPING #-} Show [Char] where ...
This is much more precise (it affects only those specific instances) and it is
much clearer (you see it when you see the instance declaration).
This new feature will be in GHC 7.10 and I'm sure you will be happy about that.
But I propose also to deprecate the LANGUAGE pragmas OverlappingInstances and
IncoherentInstances, as way to encourage everyone to use the new feature
instead of the old big hammer. The old LANGUAGE pragmas will continue to work,
of course, for at least another complete release cycle. We could make that two
cycles if it was helpful.
However, if you want deprecation-free libraries, it will entail a wave of
library updates.
This email is just to warn you, and to let you yell if you think this is a bad
idea. It would actually not be difficult to retain the old LANGUAGE pragmas
indefinitely - it just seems wrong not to actively push authors in the right
direction.
These deprecations of course popped up in the test suite, so I've been
replacing them with per-instance pragmas there too. Interestingly in some
cases, when looking for which instances needed the pragmas, I found...none. So
OverlappingInstances was entirely unnecessary. Maybe library authors will find
that too!
Simon
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: Overlapping and incoherent instances
Andreas, remember that GHC 7.8 already implements (essentially) the same
algorithm. The difference is that 7.8 offers only the brutal
-XOverlappingInstances to control it. In your example of the decision you make
when writing
instance Bla a = Bla [a]
vs
instance {-# OVERLAPPABLE #-} Bla a = Bla [a]
you are, with GHC 7.8, making precisely the same decision when you decide
whether or not to add {-# LANGUAGE OverlappingInstances #-} to that module.
Perhaps that wasn't clear in what I wrote; apologies.
So your proposal seems to be this
don't remove -XOverlappingInstances, because that will prevent
programmers from flipping on/off pragmas until their program
goes through.
It's hard to argue AGAINST providing the opportunity for more careful
programmers to express their intentions more precisely, which is what the
OVERLAP/OVERLAPPABLE pragmas do.
Concerning deprecating OverlappingInstances, my gut feel is that it is
positively a good thing to guide programmers towards a more robust programming
style. But my reason for starting this thread was to see whether or not
others' gut feel is similar.
Simon
| -Original Message-
| From: Libraries [mailto:libraries-boun...@haskell.org] On Behalf Of
| Andreas Abel
| Sent: 31 July 2014 08:59
| To: Simon Peyton Jones; ghc-devs; GHC users; Haskell Libraries
| (librar...@haskell.org)
| Subject: Re: Overlapping and incoherent instances
|
| On 31.07.2014 09:20, Simon Peyton Jones wrote:
| Friends, in sending my message below, I should also have sent a link
| to
|
| https://ghc.haskell.org/trac/ghc/ticket/9242#comment:25
|
| Indeed.
|
| Quoting from the spec:
|
| * Eliminate any candidate IX for which both of the following hold:
| * There is another candidate IY that is strictly more specific;
| that is, IY is a substitution instance of IX but not vice versa.
|
| * Either IX is overlappable or IY is overlapping.
|
| Mathematically, this makes a lot of sense. But put on the hat of
| library writers, and users, and users that don't rtfm. Looking out
| from under this hat, the one may always wonder whether one should make
| one's generic instances OVERLAPPABLE or not.
|
| If I create a library with type class Bla and
|
|instance Bla a = Bla [a]
|
| I could be a nice library writer and spare my users from declaring
| their Bla String instances as OVERLAPPING, so I'd write
|
|instance {-# OVERLAPPABLE #-} Bla a = Bla [a]
|
| Or maybe that would be malicious?
|
| I think the current proposal is too sophisticated. There are no
| convincing examples given in the discussion so far that demonstrate
| where this sophistication pays off in practice.
|
| Keep in mind that 99% of the Haskell users will never study the
| instance resolution algorithm or its specification, but just flip
| on/off pragmas until their code goes through. [At least that was my
| approach: whenever GHC asks for one more LANGUAGE pragma, just throw it
| in.]
|
| Cheers,
| Andreas
|
|
| Comment 25 describes the semantics of OVERLAPPING/OVERLAPPABLE etc,
| which I signally failed to do in my message below, leading to
| confusion in the follow up messages. My apologies for that.
|
| Some key points:
|
| *There is a useful distinction between /overlapping/ and
| /overlappable/, but if you don't want to be bothered with it you can
| just say OVERLAPS (which means both).
|
| *Overlap between two candidate instances is allowed if /either/ has
| the relevant property. This is a bit sloppy, but reduces the
| annotation burden. Actually, with this per-instance stuff I think
| it'd be perfectly defensible to require both to be annotated, but
| that's a different discussion.
|
| I hope that helps clarify.
|
| I'm really pretty certain that the basic proposal here is good: it
| implements the current semantics in a more fine-grained manner. My
| main motivation was to signal the proposed deprecation of the global
| per-module flag -XoverlappingInstances. Happily people generally
| seem
| fine with this. It is, after all, precisely what deprecations are
| for
| (the old thing still works for now, but it won't do so for ever, and
| you should change as soon as is convenient).
|
| Thanks
|
| Simon
|
| *From:*Libraries [mailto:libraries-boun...@haskell.org] *On Behalf Of
| *Simon Peyton Jones
| *Sent:* 29 July 2014 10:11
| *To:* ghc-devs; GHC users; Haskell Libraries (librar...@haskell.org)
| *Subject:* Overlapping and incoherent instances
|
| Friends
|
| One of GHC's more widely-used features is overlapping (and sometimes
| incoherent) instances. The user-manual documentation is here
| http://www.haskell.org/ghc/docs/latest/html/users_guide/type-class-
| extensions.html#instance-overlap.
|
| The use of overlapping/incoherent instances is controlled by LANGUAGE
| pragmas: OverlappingInstances and IncoherentInstances respectively.
|
| However the overlap/incoherent-ness
Re: Overlapping and incoherent instances
Now if only we could somehow find a way to do the same thing for
AllowAmbiguousTypes. :)
I have a 2500 line file that I'm forced to turn on AllowAmbiguousTypes in
for 3 definitions, and checking that I didn't accidentally make something
else ambiguous to GHC's eyes is a rather brutal affair. (I can't break up
the file without inducing orphans)
This is just a passing comment, while I'm thinking about it, not a serious
attempt to derail the topic!
-Edward
On Thu, Jul 31, 2014 at 4:13 AM, Simon Peyton Jones simo...@microsoft.com
wrote:
Andreas, remember that GHC 7.8 already implements (essentially) the same
algorithm. The difference is that 7.8 offers only the brutal
-XOverlappingInstances to control it. In your example of the decision you
make when writing
instance Bla a = Bla [a]
vs
instance {-# OVERLAPPABLE #-} Bla a = Bla [a]
you are, with GHC 7.8, making precisely the same decision when you decide
whether or not to add {-# LANGUAGE OverlappingInstances #-} to that module.
Perhaps that wasn't clear in what I wrote; apologies.
So your proposal seems to be this
don't remove -XOverlappingInstances, because that will prevent
programmers from flipping on/off pragmas until their program
goes through.
It's hard to argue AGAINST providing the opportunity for more careful
programmers to express their intentions more precisely, which is what the
OVERLAP/OVERLAPPABLE pragmas do.
Concerning deprecating OverlappingInstances, my gut feel is that it is
positively a good thing to guide programmers towards a more robust
programming style. But my reason for starting this thread was to see
whether or not others' gut feel is similar.
Simon
| -Original Message-
| From: Libraries [mailto:libraries-boun...@haskell.org] On Behalf Of
| Andreas Abel
| Sent: 31 July 2014 08:59
| To: Simon Peyton Jones; ghc-devs; GHC users; Haskell Libraries
| (librar...@haskell.org)
| Subject: Re: Overlapping and incoherent instances
|
| On 31.07.2014 09:20, Simon Peyton Jones wrote:
| Friends, in sending my message below, I should also have sent a link
| to
|
| https://ghc.haskell.org/trac/ghc/ticket/9242#comment:25
|
| Indeed.
|
| Quoting from the spec:
|
| * Eliminate any candidate IX for which both of the following hold:
| * There is another candidate IY that is strictly more specific;
| that is, IY is a substitution instance of IX but not vice versa.
|
| * Either IX is overlappable or IY is overlapping.
|
| Mathematically, this makes a lot of sense. But put on the hat of
| library writers, and users, and users that don't rtfm. Looking out
| from under this hat, the one may always wonder whether one should make
| one's generic instances OVERLAPPABLE or not.
|
| If I create a library with type class Bla and
|
|instance Bla a = Bla [a]
|
| I could be a nice library writer and spare my users from declaring
| their Bla String instances as OVERLAPPING, so I'd write
|
|instance {-# OVERLAPPABLE #-} Bla a = Bla [a]
|
| Or maybe that would be malicious?
|
| I think the current proposal is too sophisticated. There are no
| convincing examples given in the discussion so far that demonstrate
| where this sophistication pays off in practice.
|
| Keep in mind that 99% of the Haskell users will never study the
| instance resolution algorithm or its specification, but just flip
| on/off pragmas until their code goes through. [At least that was my
| approach: whenever GHC asks for one more LANGUAGE pragma, just throw it
| in.]
|
| Cheers,
| Andreas
|
|
| Comment 25 describes the semantics of OVERLAPPING/OVERLAPPABLE etc,
| which I signally failed to do in my message below, leading to
| confusion in the follow up messages. My apologies for that.
|
| Some key points:
|
| *There is a useful distinction between /overlapping/ and
| /overlappable/, but if you don't want to be bothered with it you can
| just say OVERLAPS (which means both).
|
| *Overlap between two candidate instances is allowed if /either/ has
| the relevant property. This is a bit sloppy, but reduces the
| annotation burden. Actually, with this per-instance stuff I think
| it'd be perfectly defensible to require both to be annotated, but
| that's a different discussion.
|
| I hope that helps clarify.
|
| I'm really pretty certain that the basic proposal here is good: it
| implements the current semantics in a more fine-grained manner. My
| main motivation was to signal the proposed deprecation of the global
| per-module flag -XoverlappingInstances. Happily people generally
| seem
| fine with this. It is, after all, precisely what deprecations are
| for
| (the old thing still works for now, but it won't do so for ever, and
| you should change as soon as is convenient).
|
| Thanks
|
| Simon
|
| *From:*Libraries [mailto:libraries-boun...@haskell.org] *On Behalf
RE: Overlapping and incoherent instances
| My proposal is to have just one pragma, e.g. OVERLAP, that allows
| overlap in either direction. But if you have examples whether the
| extra sophistication introduced by a separation into OVERLAPPABLE and
| OVERLAPPING is needed, I am happy to go along...
Great! As you'll see the proposal, OVERLAPS is precisely what you want. I
don't care whether it is called OVERLAP or OVERLAPS.
So it sounds as if you are content. (I assume you don't want to *prevent*
careful programmers from saying something more precise.)
Simon
|
| On 31.07.2014 10:13, Simon Peyton Jones wrote:
| Andreas, remember that GHC 7.8 already implements (essentially) the
| same algorithm. The difference is that 7.8 offers only the brutal -
| XOverlappingInstances to control it. In your example of the decision
| you make when writing
| instance Bla a = Bla [a]
| vs
| instance {-# OVERLAPPABLE #-} Bla a = Bla [a] you are, with GHC
| 7.8, making precisely the same decision when you decide whether or
| not to add {-# LANGUAGE OverlappingInstances #-} to that module.
| Perhaps that wasn't clear in what I wrote; apologies.
|
| So your proposal seems to be this
|
| don't remove -XOverlappingInstances, because that will prevent
| programmers from flipping on/off pragmas until their program
| goes through.
|
| It's hard to argue AGAINST providing the opportunity for more careful
| programmers to express their intentions more precisely, which is what
| the OVERLAP/OVERLAPPABLE pragmas do.
|
| Concerning deprecating OverlappingInstances, my gut feel is that it
| is positively a good thing to guide programmers towards a more robust
| programming style. But my reason for starting this thread was to see
| whether or not others' gut feel is similar.
|
| Simon
|
| | -Original Message-
| | From: Libraries [mailto:libraries-boun...@haskell.org] On Behalf Of
| | Andreas Abel
| | Sent: 31 July 2014 08:59
| | To: Simon Peyton Jones; ghc-devs; GHC users; Haskell Libraries
| | (librar...@haskell.org)
| | Subject: Re: Overlapping and incoherent instances
| |
| | On 31.07.2014 09:20, Simon Peyton Jones wrote:
| | Friends, in sending my message below, I should also have sent a
| | link to
| |
| | https://ghc.haskell.org/trac/ghc/ticket/9242#comment:25
| |
| | Indeed.
| |
| | Quoting from the spec:
| |
| | * Eliminate any candidate IX for which both of the following
| hold:
| | * There is another candidate IY that is strictly more specific;
| | that is, IY is a substitution instance of IX but not vice
| versa.
| |
| | * Either IX is overlappable or IY is overlapping.
| |
| | Mathematically, this makes a lot of sense. But put on the hat of
| | library writers, and users, and users that don't rtfm. Looking out
| | from under this hat, the one may always wonder whether one should
| | make one's generic instances OVERLAPPABLE or not.
| |
| | If I create a library with type class Bla and
| |
| |instance Bla a = Bla [a]
| |
| | I could be a nice library writer and spare my users from declaring
| | their Bla String instances as OVERLAPPING, so I'd write
| |
| |instance {-# OVERLAPPABLE #-} Bla a = Bla [a]
| |
| | Or maybe that would be malicious?
| |
| | I think the current proposal is too sophisticated. There are no
| | convincing examples given in the discussion so far that demonstrate
| | where this sophistication pays off in practice.
| |
| | Keep in mind that 99% of the Haskell users will never study the
| | instance resolution algorithm or its specification, but just flip
| | on/off pragmas until their code goes through. [At least that was
| my
| | approach: whenever GHC asks for one more LANGUAGE pragma, just
| throw
| | it in.]
| |
| | Cheers,
| | Andreas
| |
| |
| | Comment 25 describes the semantics of OVERLAPPING/OVERLAPPABLE
| | etc, which I signally failed to do in my message below, leading
| to
| | confusion in the follow up messages. My apologies for that.
| |
| | Some key points:
| |
| | *There is a useful distinction between /overlapping/ and
| | /overlappable/, but if you don't want to be bothered with it you
| | can just say OVERLAPS (which means both).
| |
| | *Overlap between two candidate instances is allowed if /either/
| | has the relevant property. This is a bit sloppy, but reduces the
| | annotation burden. Actually, with this per-instance stuff I
| think
| | it'd be perfectly defensible to require both to be annotated, but
| | that's a different discussion.
| |
| | I hope that helps clarify.
| |
| | I'm really pretty certain that the basic proposal here is good:
| it
| | implements the current semantics in a more fine-grained manner.
| | My main motivation was to signal the proposed deprecation of the
| | global per-module flag -XoverlappingInstances. Happily people
| | generally
| | seem
| | fine with this. It is, after all, precisely what
Re: Overlapping and incoherent instances
On Wed, Jul 30, 2014 at 2:50 PM, Ivan Lazar Miljenovic ivan.miljeno...@gmail.com wrote: On 30 July 2014 22:07, Andreas Abel andreas.a...@ifi.lmu.de wrote: I am a bit surprised by the distinction you outline below. This is maybe because I am native German, not English. The German equivalent of overlap, überschneiden/überlappen, is used exclusively in a symmetrical fashion. It's like in English, if I say our interests overlap, then it is pointless to ask whether my interest are overlapping yours or are overlapped by yours. I want to alert you to the fact that non-native English speaker might have little understanding for a distinction between OVERLAPPING and OVERLAPPABLE. Let's try to guess what it meant: Given A) instance Bla Char B) instance Bla a = Bla [a] C) instance Bla String you will in context A,B write C as OVERLAPPING, and in context A,C write B as OVERLAPPABLE? IIUC, B will be OVERLAPPABLE (you can overlap this) and C will be OVERLAPPING (I'm overlapping an existing one) whereas C will be plain. Apologies if this question doesn't make sense. Can we really talk about overlapping, given that instances can be written in different modules, moved between modules, or removed? ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Overlapping and incoherent instances
Simon Peyton Jones simonpj at microsoft.com writes: Tue Jul 29 09:11:05 UTC 2014 ... This is a Big Hammer. I agree with Simon's motivation that the whole-module overlap pragma is often too brutal. But I think that what Iavor has developed is still too brutal. (Sorry, and I hadn't known about these instance-level pragmas before now.) For my 2d, I think Andreas made an important distinction: Andreas Abel andreas.abel at ifi.lmu.de Wed Jul 30 12:07:01 UTC 2014 The German equivalent of overlap, ..., is used exclusively in a symmetrical fashion. It's like in English, if I say our interests overlap, then it is pointless to ask whether my interest are overlapping yours or are overlapped by yours. I'd say that the English overlap is also used in a symmetrical fashion (outside of specialist Haskell instances usage). There's a difference between: - this instance is nec. narrower than some other instance (IOW anything that's a substitution for this instance, is ipso facto a substitution for some wider) - vs. a partial overlap (some substitutions will fit this instance only, some will fit another instance, not this one, some will fit both) In my experience, unintended partial overlaps are the nastiest to diagnose. And partial overlaps are very seldom needed in practice. They're often a symptom that two separately-developed libraries are clashing. (For example the HList libraries -- as originally released -- used overlap extensively, but no partial overlaps.) So I would like the pragmas to be able to say: OK for this instance to subsumes or be subsumed by some other instance but it must not partially overlap any instance. (I guess this is beyond the question Simon's OP asked.) AntC ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Overlapping and incoherent instances
On 2014-07-29 at 11:29:45 +0200, Niklas Hambüchen wrote:
instance {-# OVERLAPPABLE #-} Show a = Show [a] where …
Is the syntax somewhat flexible in where the pragma can be placed?
For example, some might prefer
{-# OVERLAPPING #-}
instance Show [Char] where …
This variant may also be more convenient in cases where you need to
CPP-guard that pragma, as it's on a separate line.
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Overlapping and incoherent instances
On Tue, Jul 29, 2014 at 11:50 AM, Herbert Valerio Riedel h...@gnu.org wrote:
On 2014-07-29 at 11:29:45 +0200, Niklas Hambüchen wrote:
instance {-# OVERLAPPABLE #-} Show a = Show [a] where …
Is the syntax somewhat flexible in where the pragma can be placed?
For example, some might prefer
{-# OVERLAPPING #-}
instance Show [Char] where …
This variant may also be more convenient in cases where you need to
CPP-guard that pragma, as it's on a separate line.
Agreed, and if we remove the old pragma (even with a deprecation
cycle) you'll see quite a few of those as many library authors try to
have their libraries compile with the last 3 major GHC versions.
P.S. For e.g. INLINABLE we require that you mention the function name
next to the pragma (which means that you can e.g. put the pragma after
the declaration). What's the rationale to not require
{-# OVERLAPPING Show [Char] #-}
here? Perhaps it's too annoying to have to repeat the types?
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Overlapping and incoherent instances
On Tue, Jul 29, 2014 at 12:02:19PM +0200, Johan Tibell wrote:
What's the rationale to not require
{-# OVERLAPPING Show [Char] #-}
here? Perhaps it's too annoying to have to repeat the types?
This one might be written at the top of the file, so it would be easier
to overlook it, than having it directly at the instance declaration,
which seems to be one of the major points for OVERLAPPING and OVERLAPPABLE.
Greetings,
Daniel
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Overlapping and incoherent instances
On Tue, Jul 29, 2014 at 12:37 PM, Daniel Trstenjak
daniel.trsten...@gmail.com wrote:
On Tue, Jul 29, 2014 at 12:02:19PM +0200, Johan Tibell wrote:
What's the rationale to not require
{-# OVERLAPPING Show [Char] #-}
here? Perhaps it's too annoying to have to repeat the types?
This one might be written at the top of the file, so it would be easier
to overlook it, than having it directly at the instance declaration,
which seems to be one of the major points for OVERLAPPING and OVERLAPPABLE.
The same could be said for e.g. INLINE. The extra flexibility is nice
to have (e.g. because you can opt to put the pragma after the
declaration, to de-emphasize it.)
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Overlapping and incoherent instances
I think it may also lead to cleaner code. I would rather write a single
section like this:
#if NEW_GHC
{-# bunch of OVERLAPPABLE declarations #-}
#endif
at the start of the file rather than have to insert a lot of CPP-guarded
pragmas later. But it may be seen as an editor/IDE issue and bikeshedding
on the whole.
--
Krzysztof
On Tue, Jul 29, 2014 at 12:48 PM, Johan Tibell johan.tib...@gmail.com
wrote:
On Tue, Jul 29, 2014 at 12:37 PM, Daniel Trstenjak
daniel.trsten...@gmail.com wrote:
On Tue, Jul 29, 2014 at 12:02:19PM +0200, Johan Tibell wrote:
What's the rationale to not require
{-# OVERLAPPING Show [Char] #-}
here? Perhaps it's too annoying to have to repeat the types?
This one might be written at the top of the file, so it would be easier
to overlook it, than having it directly at the instance declaration,
which seems to be one of the major points for OVERLAPPING and
OVERLAPPABLE.
The same could be said for e.g. INLINE. The extra flexibility is nice
to have (e.g. because you can opt to put the pragma after the
declaration, to de-emphasize it.)
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: Overlapping and incoherent instances
The current implementation requires the pragma exactly where showed it.
I'm not keen on allowing it to be separated.
I suppose with some more parser jiggery pokery it could be allowed immediately
before (or, better, after).
But cpp would let you say
instance
#if blah
{-# OVERLAPPABLE #-}
#endif
Show a = Show [a] where ...
Simon
| -Original Message-
| From: Johan Tibell [mailto:johan.tib...@gmail.com]
| Sent: 29 July 2014 11:02
| To: Herbert Valerio Riedel
| Cc: Niklas Hambüchen; Haskell Libraries (librar...@haskell.org); GHC
| users; Simon Peyton Jones; ghc-devs
| Subject: Re: Overlapping and incoherent instances
|
| On Tue, Jul 29, 2014 at 11:50 AM, Herbert Valerio Riedel h...@gnu.org
| wrote:
| On 2014-07-29 at 11:29:45 +0200, Niklas Hambüchen wrote:
| instance {-# OVERLAPPABLE #-} Show a = Show [a] where …
|
| Is the syntax somewhat flexible in where the pragma can be placed?
| For example, some might prefer
|
|{-# OVERLAPPING #-}
|instance Show [Char] where …
|
| This variant may also be more convenient in cases where you need to
| CPP-guard that pragma, as it's on a separate line.
|
| Agreed, and if we remove the old pragma (even with a deprecation
| cycle) you'll see quite a few of those as many library authors try to
| have their libraries compile with the last 3 major GHC versions.
|
| P.S. For e.g. INLINABLE we require that you mention the function name
| next to the pragma (which means that you can e.g. put the pragma after
| the declaration). What's the rationale to not require
|
| {-# OVERLAPPING Show [Char] #-}
|
| here? Perhaps it's too annoying to have to repeat the types?
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Overlapping and incoherent instances
How about CAN_OVERLAP? -- Krzysztof 29-07-2014 15:40, Brandon Allbery allber...@gmail.com napisał(a): On Tue, Jul 29, 2014 at 8:33 AM, Andreas Abel andreas.a...@ifi.lmu.de wrote: +1. I like Niklas' syntax better. Also OVERLAPPABLE is a horrible word, OVERLAPPING sound less formidable (even though it might be slightly less accurrate). We already get overlap ok in instance-related type errors, so OVERLAP_OK wouldn't be particularly alien even if it doesn't quite fit in with existing pragmas. -- brandon s allbery kf8nh sine nomine associates allber...@gmail.com ballb...@sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net ___ Libraries mailing list librar...@haskell.org http://www.haskell.org/mailman/listinfo/libraries ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: Overlapping and incoherent instances
CAN_OVERLAP and CAN_BE_OVERLAPPED? (instead of OVERLAPPING and OVERLAPPABLE) Or CAN-OVERLAP, CAN-BE-OVERLAPPED That’s ok with me if that’s what you all want! Simon From: Glasgow-haskell-users [mailto:glasgow-haskell-users-boun...@haskell.org] On Behalf Of Krzysztof Skrzetnicki Sent: 29 July 2014 16:56 To: Brandon Allbery Cc: Simon Peyton Jones; Andreas Abel; GHC users; Haskell Libraries (librar...@haskell.org); ghc-devs Subject: Re: Overlapping and incoherent instances How about CAN_OVERLAP? -- Krzysztof 29-07-2014 15:40, Brandon Allbery allber...@gmail.commailto:allber...@gmail.com napisał(a): On Tue, Jul 29, 2014 at 8:33 AM, Andreas Abel andreas.a...@ifi.lmu.demailto:andreas.a...@ifi.lmu.de wrote: +1. I like Niklas' syntax better. Also OVERLAPPABLE is a horrible word, OVERLAPPING sound less formidable (even though it might be slightly less accurrate). We already get overlap ok in instance-related type errors, so OVERLAP_OK wouldn't be particularly alien even if it doesn't quite fit in with existing pragmas. -- brandon s allbery kf8nh sine nomine associates allber...@gmail.commailto:allber...@gmail.com ballb...@sinenomine.netmailto:ballb...@sinenomine.net unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net ___ Libraries mailing list librar...@haskell.orgmailto:librar...@haskell.org http://www.haskell.org/mailman/listinfo/libraries ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: Overlapping and incoherent instances
| One other issue this brings up: how does this all interact with -XSafe?
| Right now, Safety can be inferred by looking at the set of LANGUAGE
| pragmas and the import list. (Right?) With the change as implemented,
| Safe inference would require looking at all instance declarations. Is
| this OK?
I'm honestly not sure, but I do know that, in the implementation, each instance
declaration keeps track of (a) whether it is
OVERLAPPABLE/OVERLAPPING/INCOHERENT, and (b) the setting of -XSafe in the
module where the instance declaration is given.
This doesn't change. So I can't answer your question directly, but I think
that the behaviour is unchanged from that at present.
Simon
|
| Richard
|
| On Jul 29, 2014, at 7:02 AM, Simon Peyton Jones simo...@microsoft.com
| wrote:
|
| The current implementation requires the pragma exactly where showed
| it.
|
| I'm not keen on allowing it to be separated.
|
| I suppose with some more parser jiggery pokery it could be allowed
| immediately before (or, better, after).
|
| But cpp would let you say
|
| instance
| #if blah
| {-# OVERLAPPABLE #-}
| #endif
| Show a = Show [a] where ...
|
| Simon
|
| | -Original Message-
| | From: Johan Tibell [mailto:johan.tib...@gmail.com]
| | Sent: 29 July 2014 11:02
| | To: Herbert Valerio Riedel
| | Cc: Niklas Hambüchen; Haskell Libraries (librar...@haskell.org);
| GHC
| | users; Simon Peyton Jones; ghc-devs
| | Subject: Re: Overlapping and incoherent instances
| |
| | On Tue, Jul 29, 2014 at 11:50 AM, Herbert Valerio Riedel
| | h...@gnu.org
| | wrote:
| | On 2014-07-29 at 11:29:45 +0200, Niklas Hambüchen wrote:
| | instance {-# OVERLAPPABLE #-} Show a = Show [a] where .
| |
| | Is the syntax somewhat flexible in where the pragma can be
| placed?
| | For example, some might prefer
| |
| |{-# OVERLAPPING #-}
| |instance Show [Char] where .
| |
| | This variant may also be more convenient in cases where you need
| | to CPP-guard that pragma, as it's on a separate line.
| |
| | Agreed, and if we remove the old pragma (even with a deprecation
| | cycle) you'll see quite a few of those as many library authors try
| | to have their libraries compile with the last 3 major GHC versions.
| |
| | P.S. For e.g. INLINABLE we require that you mention the function
| | name next to the pragma (which means that you can e.g. put the
| | pragma after the declaration). What's the rationale to not require
| |
| | {-# OVERLAPPING Show [Char] #-}
| |
| | here? Perhaps it's too annoying to have to repeat the types?
| ___
| Glasgow-haskell-users mailing list
| Glasgow-haskell-users@haskell.org
| http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
|
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Overlapping and incoherent instances
Hello, I have no strong feelings about what words we use, but I wanted to point out that while we are thinking of names, we may want to consider 3 (and not just 2). Currently we have: * OVERLAPPING: This instances may overlap existing instances * OVERLAPPABLE: This instance may be overlapped by existing instances * OVERLAPS: This instance is both OVERLAPPING and OVERLAPPABLE Of course, the 3rd one (OVERLAPS) could be replaced by a comma separated list of the first two, but I could not see how to make this work easily with GHC's pragmas. It would not be hard to simply allow 2 pragmas after the `instance` keyword, but both of those seem rather long. Either way, I'll keep an eye on the discussion, and would be happy to change the names if a consesus is reached. -Iavor On Tue, Jul 29, 2014 at 9:57 AM, David Thomas davidleotho...@gmail.com wrote: Honestly, I think OVERLAPS and OVERLAPPED are perfectly clear. On Tue, Jul 29, 2014 at 9:52 AM, David Feuer david.fe...@gmail.com wrote: CAN-OVERLAP and CAN-BE-OVERLAPPED are nice and clear. A little long, perhaps. On Tue, Jul 29, 2014 at 12:29 PM, Simon Peyton Jones simo...@microsoft.com wrote: CAN_OVERLAP and CAN_BE_OVERLAPPED? (instead of OVERLAPPING and OVERLAPPABLE) Or CAN-OVERLAP, CAN-BE-OVERLAPPED That’s ok with me if that’s what you all want! Simon From: Glasgow-haskell-users [mailto:glasgow-haskell-users-boun...@haskell.org] On Behalf Of Krzysztof Skrzetnicki Sent: 29 July 2014 16:56 To: Brandon Allbery Cc: Simon Peyton Jones; Andreas Abel; GHC users; Haskell Libraries (librar...@haskell.org); ghc-devs Subject: Re: Overlapping and incoherent instances How about CAN_OVERLAP? -- Krzysztof 29-07-2014 15:40, Brandon Allbery allber...@gmail.com napisał(a): On Tue, Jul 29, 2014 at 8:33 AM, Andreas Abel andreas.a...@ifi.lmu.de wrote: +1. I like Niklas' syntax better. Also OVERLAPPABLE is a horrible word, OVERLAPPING sound less formidable (even though it might be slightly less accurrate). We already get overlap ok in instance-related type errors, so OVERLAP_OK wouldn't be particularly alien even if it doesn't quite fit in with existing pragmas. -- brandon s allbery kf8nh sine nomine associates allber...@gmail.com ballb...@sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net ___ Libraries mailing list librar...@haskell.org http://www.haskell.org/mailman/listinfo/libraries ___ Libraries mailing list librar...@haskell.org http://www.haskell.org/mailman/listinfo/libraries ___ Libraries mailing list librar...@haskell.org http://www.haskell.org/mailman/listinfo/libraries ___ Libraries mailing list librar...@haskell.org http://www.haskell.org/mailman/listinfo/libraries ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Overlapping and incoherent instances
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
instance {-# OVERLAPPABLE #-} Show a = Show [a] where ...
instance {-# OVERLAPPING #-} Show [Char] where ...
This, to me, is an admission that developers are not going to want to turn
overlapping on globally in general, and so the current language extensions
would not make sense to get adopted into the core language at any point.
I agree with this idea, and so would second the proposal mentioned at
http://www.reddit.com/r/haskell/comments/2c136i/xoverlappinginstances_and_xincoherentinstances_to/cjb4jmr
that a language extension that adds actual keywords to tag instances that
should be allowed to overlap be added, instead of resorting to pragmas.
This seems like an approach that could be useful in general and one could
imagine moving past an extension to the core language at some point,
potentially.
- --
Stephen Paul Weber, @singpolyma
See http://singpolyma.net for how I prefer to be contacted
edition right joseph
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
iQIcBAEBCAAGBQJT2DFBAAoJENEcKRHOUZzemmIQAJEbSjPyx745UI6mkuhBVhKl
LQWJlpu0/kzBHaFJl/mWcghKxoBFWwU+pCTh/Pr2oj0rp/KGskBLlplIqB4btZTA
ov2MpPrsHm1M37MuGyMtiBhs57UJE+saKKuvcH3qzLZyBCHorE3lFcKAFbNupBrL
e/vgNblQ70KGmDRAKqbAQHm9anoGeZUJPgQ9ylVEH4nBYLDo0YSNo/zTeB7fK2yv
xBE+Ul3YGfhzf82cLJhYNQOpi5wJ3JEDBevKXcGRzr4Mhzn2Lke+26tu0tx6sOSN
snPX2REoeQD1AfXvuNKSxV7BL+CQeyAOOmm2Isj3vW/oO3gkqpfRjCFc+ZSPEjlG
XQ3S7L7cgNB34rd6sOFzTv83PXvsH0a0d5RqKUM2kN/qGEjSbAQ1FVyJEUcaEmzr
jBnVnWq+abCOSOBg4joGfTxjq0zufdjxkzScEJVDVZ4pIXoxej7HJBi8UfIvo3Jo
EDMGGsLSedt4tR2LzYf/5up7GPfuBsFQQzuIcdgMG8/zYca7zWPJgyunlXAPcbzr
RvM/gf63SCBuVaQjrtv2Zhzp3PucWOL94NEmLYONU3uuEmo6bq1VO42fOUcl7X/1
UyhFbtoV7s/7PVClxdD4Ag9PumtSfl/CSvN0BA8AzDwTuHWNOPdThAHFqfAtRsD0
GyNzVRNOGuze9SqkLc4T
=YeKu
-END PGP SIGNATURE-
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Overlapping and incoherent instances
On 29-07-2014 20:41, Stephen Paul Weber wrote:
instance {-# OVERLAPPABLE #-} Show a = Show [a] where ...
instance {-# OVERLAPPING #-} Show [Char] where ...
This, to me, is an admission that developers are not going to want to turn
overlapping on globally in general, and so the current language extensions
would not make sense to get adopted into the core language at any point.
I agree with this idea, and so would second the proposal mentioned at
http://www.reddit.com/r/haskell/comments/2c136i/xoverlappinginstances_and_xincoherentinstances_to/cjb4jmr
that a language extension that adds actual keywords to tag instances that
should be allowed to overlap be added, instead of resorting to pragmas.
This seems like an approach that could be useful in general and one could
imagine moving past an extension to the core language at some point,
potentially.
OTOH, the pragma is mostly harmless for older GHC versions, while the
keyword approach needs a preprocessor.
--
Felipe.
signature.asc
Description: OpenPGP digital signature
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Overlapping and incoherent instances
Somebody signing messages as Felipe Lessa wrote: OTOH, the pragma is mostly harmless for older GHC versions, while the keyword approach needs a preprocessor. Only if *both* the old LANGUAGE pragma and the new pragma were employed, which will generate a deprecation warning for awhile and then eventually (likely) be rejected by newer GHCs, thus requiring a prepropcessor in either case. -- Stephen Paul Weber, @singpolyma See http://singpolyma.net for how I prefer to be contacted edition right joseph ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
