Re: OVERLAPPABLE/OVERLAPPING/OVERLAPS pragmas are confusing
Johan,
to summarize:
1. If an instance is marked as OVERLAPPABLE, then clients may overlap it
without having any pragmas
2. If an instance is NOT marked OVERLAPPABLE, then clients may still
overlap it, but then they have to use an explicit OVERLAPPING pragma.
So you should either add OVERLAPPABLE to your library, and then clients
don't need to do anything, or
you should remove it, and require that clients add OVERLAPPING.
Note that using this mechanism across modules can be quite error prone.
For example, you have to be very careful
not to use an OVERLAPPABLE instance in your library, as if you do parts of
the program might end up using
one instance, and other parts may end up using another instance---GHC has
no way of knowing about overlapping
instance in client libraries, so it will simply use the best possible
*local* instance.
-Iavor
On Tue, Aug 25, 2015 at 8:46 AM, Mikhail Glushenkov
the.dead.shall.r...@gmail.com wrote:
Hi,
On 25 August 2015 at 14:18, Johan Tibell johan.tib...@gmail.com wrote:
The proposed change to my library is here:
https://github.com/tibbe/cassava/pull/95/files
We remove the OverlappingInstances pragma and instead add an OVERLAPPABLE
pragma like so:
instance {-# OVERLAPPABLE #-} FromField a = FromField (Maybe a)
where
This causes clients of the library that previously compiled (e.g. the
music-parts package) to no longer compile, due to a now lacking
OVERLAPPING
pragma in their code.
No, it's not quite like that. Client code can start to break when {-#
LANGUAGE OverlappingInstances #-} is removed, as happened with the
music-parts package. Adding an OVERLAPPABLE pragma to cassava's code
made that error go away.
Client code can usually work around the problem of missing
OVERLAPPABLE pragmas in the library by adding OVERLAPPING pragmas to
their instances. The reason I suggested bumping cassava's version is
that there may be some places in cassava that still need new pragmas
that I've overlooked.
If GHC had an option for detecting overlapping instances at definition
site, that'd help, I think, since then it'd be easier to find
instances that need new pragmas.
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: OVERLAPPABLE/OVERLAPPING/OVERLAPS pragmas are confusing
Hi,
On 25 August 2015 at 14:18, Johan Tibell johan.tib...@gmail.com wrote:
The proposed change to my library is here:
https://github.com/tibbe/cassava/pull/95/files
We remove the OverlappingInstances pragma and instead add an OVERLAPPABLE
pragma like so:
instance {-# OVERLAPPABLE #-} FromField a = FromField (Maybe a) where
This causes clients of the library that previously compiled (e.g. the
music-parts package) to no longer compile, due to a now lacking OVERLAPPING
pragma in their code.
No, it's not quite like that. Client code can start to break when {-#
LANGUAGE OverlappingInstances #-} is removed, as happened with the
music-parts package. Adding an OVERLAPPABLE pragma to cassava's code
made that error go away.
Client code can usually work around the problem of missing
OVERLAPPABLE pragmas in the library by adding OVERLAPPING pragmas to
their instances. The reason I suggested bumping cassava's version is
that there may be some places in cassava that still need new pragmas
that I've overlooked.
If GHC had an option for detecting overlapping instances at definition
site, that'd help, I think, since then it'd be easier to find
instances that need new pragmas.
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: OVERLAPPABLE/OVERLAPPING/OVERLAPS pragmas are confusing
The proposed change to my library is here:
https://github.com/tibbe/cassava/pull/95/files
We remove the OverlappingInstances pragma and instead add an OVERLAPPABLE
pragma like so:
instance {-# OVERLAPPABLE #-} FromField a = FromField (Maybe a) where
This causes clients of the library that previously compiled (e.g.
the music-parts package) to no longer compile, due to a now
lacking OVERLAPPING pragma in their code.
The issue here is I'm trying to the right thing (move to new pragmas), but
that causes clients to fail to compile. My question is: how do we avoid
that? Would it be OK if they added the OVERLAPPING pragma first and then I
change my library to use OVERLAPPABLE?
On Tue, Aug 25, 2015 at 1:25 PM, Simon Peyton Jones simo...@microsoft.com
wrote:
What's the right way to migrate code? Just switching my library to the new
pragmas breaks code, so that doesn't seem very attractive.
I don’t understand. Can you describe the problem more precisely, perhaps
with an example?
S
*From:* ghc-devs [mailto:ghc-devs-boun...@haskell.org] *On Behalf Of *Johan
Tibell
*Sent:* 25 August 2015 10:42
*To:* ghc-devs@haskell.org
*Subject:* OVERLAPPABLE/OVERLAPPING/OVERLAPS pragmas are confusing
It was brought to my attention that cassava, my library,
uses OverlappingInstances, which is now deprecated. There's a suggested fix
here: https://github.com/tibbe/cassava/pull/95.
The fix seems correct but, as Mikhail points out, makes some client code
no longer compile (due to a now missing OVERLAPPABLE pragma).
What's the right way to migrate code? Just switching my library to the new
pragmas breaks code, so that doesn't seem very attractive. Do clients have
to migrate before the libraries they use?
-- Johan
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
RE: OVERLAPPABLE/OVERLAPPING/OVERLAPS pragmas are confusing
Would it be OK if they added the OVERLAPPING pragma first and then I change my
library to use OVERLAPPABLE?
I think so, yes. Does that not work? Is it bad? Do you think the semantics is
wrong?
Simon
From: Johan Tibell [mailto:johan.tib...@gmail.com]
Sent: 25 August 2015 13:19
To: Simon Peyton Jones
Cc: ghc-devs@haskell.org
Subject: Re: OVERLAPPABLE/OVERLAPPING/OVERLAPS pragmas are confusing
The proposed change to my library is here:
https://github.com/tibbe/cassava/pull/95/files
We remove the OverlappingInstances pragma and instead add an OVERLAPPABLE
pragma like so:
instance {-# OVERLAPPABLE #-} FromField a = FromField (Maybe a) where
This causes clients of the library that previously compiled (e.g. the
music-parts package) to no longer compile, due to a now lacking OVERLAPPING
pragma in their code.
The issue here is I'm trying to the right thing (move to new pragmas), but that
causes clients to fail to compile. My question is: how do we avoid that? Would
it be OK if they added the OVERLAPPING pragma first and then I change my
library to use OVERLAPPABLE?
On Tue, Aug 25, 2015 at 1:25 PM, Simon Peyton Jones
simo...@microsoft.commailto:simo...@microsoft.com wrote:
What's the right way to migrate code? Just switching my library to the new
pragmas breaks code, so that doesn't seem very attractive.
I don’t understand. Can you describe the problem more precisely, perhaps with
an example?
S
From: ghc-devs
[mailto:ghc-devs-boun...@haskell.orgmailto:ghc-devs-boun...@haskell.org] On
Behalf Of Johan Tibell
Sent: 25 August 2015 10:42
To: ghc-devs@haskell.orgmailto:ghc-devs@haskell.org
Subject: OVERLAPPABLE/OVERLAPPING/OVERLAPS pragmas are confusing
It was brought to my attention that cassava, my library, uses
OverlappingInstances, which is now deprecated. There's a suggested fix here:
https://github.com/tibbe/cassava/pull/95.
The fix seems correct but, as Mikhail points out, makes some client code no
longer compile (due to a now missing OVERLAPPABLE pragma).
What's the right way to migrate code? Just switching my library to the new
pragmas breaks code, so that doesn't seem very attractive. Do clients have to
migrate before the libraries they use?
-- Johan
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
