Re: False "duplicate or overlapping instances" message
Simon Peyton-Jones wrote: > | I think I've worked out what's going on now. But I don't like it. > | When I use -fallow-undecidable-instances and -fallow-overlapping-instances > | (as I did) I was assuming (like Keith Wansbrough did) that > | GHC would do a Prolog-style backtracking search when it was time to > resolve > | an overloading, and would only complain if there were more or fewer than > one > | chain of inferences. Instead Haskell eagerly tries to anticipate possible > > | conflicts, which is a nuisance when it is obvious (as it is to me in this > case) that such > | conflicts are unlikely to arise. For a simpler example, imagine that we > have two classes > | Integral a (things corresponding to integers) and String a > | (things corresponding to strings). It is a pity that we cannot write > | > | instance Integral a => Show a > |and > | instance String a => Show a > | > | just because someone may come along later on and try to show > | something which is an instance of both Integral and String. (Though > obviously if > | they do, we DO need an error message.) > > I agree with this. Here's GHC's current policy: > > a) when trying to 'solve' a constraint (C T1 .. Tn) it finds an instance > decl whose head matches, and commits to that. If two match (and we're > allowing > overlap) then it picks the most specific. > > b) to make (a) make sense, GHC complains about overlap, at least > where one head is not more specific than the other > > A better policy might be > > a') when trying to solve a constraint, search for all solutions, and check > that in the end there is only one. > > b') never comlain of overlap when declaring instance declarations; instead > only complain when solving constraints. > > This is no more expensive than (a) in the common no-overlap case, > but it's more expressive when overlaps exist. > > All this makes perfect sense, I think. I don't have time to implement > it right now, but maybe someone else does? It's a well-separated > piece of GHC (one module). This has already been implemented in hugs (option +m - for `multi-instance resolution') as of about June 99. See the hugs user manual for details. It worked pretty well at the time, but may have suffered some bit-rot - I just haven't used that option in a long time, and since then there have been a couple interesting changes to the type checker. It was a fairly localized change in hugs, and I'd hope it would also be fairly localized in GHC. --Jeff ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: False "duplicate or overlapping instances" message
Marcin 'Qrczak' Kowalczyk wrote: [snip] > I am worried if the following scenario is possible: There are > two modules. Everything is OK. Now one of them adds an innocent > instance. It is perfectly correct in its context, but it happens that > it triggers an ambiguity in the second module. Still neither module > itself is at fault. [snip] > I don't have a concrete case in mind... [snip] I do though. I mentioned it before. I don't see how you can get a worse example in principle than this. Module 1: class Integral number where [ operations on numbers ] instance Integral number => Show number where [ extract digits in obvious way ] Module 2: class String string where [ operations on strings ] class String string => Show string where [ extract canonical ASCII string representation ] As a matter of fact GHC would not have a problem with these modules (unless perhaps someone imports both of them - I don't know if it checks that). In any case I would rather it didn't have a problem with them. I suspect some of my code already relies on it not having a problem. Now suppose J. Random User comes along three years later and adds something that's an instance of both Integral and String. S/he tries to show this hybrid. Then we DO have a problem. But not until then. I personally think it's quite alright to print out a message at this stage along the lines of "I'm sorry, I can't work out which instance of Show to use, because it could come from Integral (see Module 1) or from String (see Module 2)." Compare the case when Modules 1 & 2 give the same symbol different definitions. Haskell doesn't have a problem. It doesn't even have a problem if you import the two modules in the same file. It only has a problem if you try and use that symbol in that file. ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: False "duplicate or overlapping instances" message
Thu, 26 Oct 2000 01:29:38 -0700, Simon Peyton-Jones <[EMAIL PROTECTED]> pisze:
> a') when trying to solve a constraint, search for all solutions,
> and check that in the end there is only one.
>
> b') never comlain of overlap when declaring instance declarations;
> instead only complain when solving constraints.
I am worried if the following scenario is possible: There are
two modules. Everything is OK. Now one of them adds an innocent
instance. It is perfectly correct in its context, but it happens that
it triggers an ambiguity in the second module. Still neither module
itself is at fault.
Something like this can even happen now: when they define overlapping
instances. Maybe after this "fix" some of these cases won't trigger
errors immediately, but at some unexpected point in the future,
long after these modules were committed as good?
I don't have a concrete case in mind...
--
__("< Marcin Kowalczyk * [EMAIL PROTECTED] http://qrczak.ids.net.pl/
\__/
^^ SYGNATURA ZASTÊPCZA
QRCZAK
___
Glasgow-haskell-bugs mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: False "duplicate or overlapping instances" message
| I think I've worked out what's going on now. But I don't like it. | When I use -fallow-undecidable-instances and -fallow-overlapping-instances | (as I did) I was assuming (like Keith Wansbrough did) that | GHC would do a Prolog-style backtracking search when it was time to resolve | an overloading, and would only complain if there were more or fewer than one | chain of inferences. Instead Haskell eagerly tries to anticipate possible | conflicts, which is a nuisance when it is obvious (as it is to me in this case) that such | conflicts are unlikely to arise. For a simpler example, imagine that we have two classes | Integral a (things corresponding to integers) and String a | (things corresponding to strings). It is a pity that we cannot write | | instance Integral a => Show a |and | instance String a => Show a | | just because someone may come along later on and try to show | something which is an instance of both Integral and String. (Though obviously if | they do, we DO need an error message.) I agree with this. Here's GHC's current policy: a) when trying to 'solve' a constraint (C T1 .. Tn) it finds an instance decl whose head matches, and commits to that. If two match (and we're allowing overlap) then it picks the most specific. b) to make (a) make sense, GHC complains about overlap, at least where one head is not more specific than the other A better policy might be a') when trying to solve a constraint, search for all solutions, and check that in the end there is only one. b') never comlain of overlap when declaring instance declarations; instead only complain when solving constraints. This is no more expensive than (a) in the common no-overlap case, but it's more expressive when overlaps exist. All this makes perfect sense, I think. I don't have time to implement it right now, but maybe someone else does? It's a well-separated piece of GHC (one module). Simon ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: False "duplicate or overlapping instances" message
Keith Wansbrough wrote:
>
> > > You can now see that the two instance declarations overlap: their
> > > right hand sides are in fact *identical*. Remember that the
> > > typechecker simply matches on the right-hand sides ("heads") of the
> > > instance declarations.
> > No they do not overlap, unless there is an a b satisfying NodeTypeConfigParms a b
> > and ArcTypeConfigParms a b. Which there aint.
>
> Haskell makes the "open world" assumption... there may be new
> instances added later, and the behaviour of a well-typed program
> should not change if this occurs.
>
> I'll defer further discussion of this to the experts (Mark Jones?).
I think I've worked out what's going on now. But I don't like it.
When I use -fallow-undecidable-instances and -fallow-overlapping-instances
(as I did) I was assuming (like Keith Wansbrough did) that GHC would do a
Prolog-style backtracking search when it was time to resolve an overloading,
and would only complain if there were more or fewer than one chain of inferences.
Instead Haskell eagerly tries to anticipate possible conflicts, which is a nuisance
when it is obvious (as it is to me in this case) that such conflicts are unlikely
to arise. For a simpler example, imagine that we have two classes
Integral a (things corresponding to integers) and String a (things corresponding to
strings). It is a pity that we cannot write
instance Integral a => Show a
and
instance String a => Show a
just because someone may come along later on and try to show something which is an
instance of both Integral and String. (Though obviously if they do, we DO need an
error message.)
___
Glasgow-haskell-bugs mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: False "duplicate or overlapping instances" message
> > You can now see that the two instance declarations overlap: their
> > right hand sides are in fact *identical*. Remember that the
> > typechecker simply matches on the right-hand sides ("heads") of the
> > instance declarations.
> No they do not overlap, unless there is an a b satisfying NodeTypeConfigParms a b
> and ArcTypeConfigParms a b. Which there aint.
Haskell makes the "open world" assumption... there may be new
instances added later, and the behaviour of a well-typed program
should not change if this occurs.
I'll defer further discussion of this to the experts (Mark Jones?).
--KW 8-)
___
Glasgow-haskell-bugs mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: False "duplicate or overlapping instances" message
Keith Wansbrough wrote:
>
> > Instances.hs:1:
> > Duplicate or overlapping instance declarations
> > for `HasConfig (arcTypeConfig value) (arcTypeParms value)'
> > defined at Instances.hs:19 and defined at Instances.hs:11
> >
> > This is not fair, because while the instances for HasConfig have the
> > potential to conflict in the future, they will only do so should the classes
> > NodeTypeConfigParms and ArcTypeConfigParms overlap.
>
> It is fair. Let's rename your type variables to make what's going on a little
>clearer:
>
> main = return ()
>
> class HasConfig a b where
> ($$) :: a -> b -> b
>
> class NodeTypeConfigParms a b where
> nodeTypeConfig :: a c -> b c -> b c
>
> instance (NodeTypeConfigParms a b) => HasConfig (a c) (b c) where
> ($$) = nodeTypeConfig
>
> class ArcTypeConfigParms a b where
> arcTypeConfig :: a c -> b c -> b c
>
> instance (ArcTypeConfigParms a b) => HasConfig (a c) (b c) where
> ($$) = arcTypeConfig
>
>
> You can now see that the two instance declarations overlap: their
> right hand sides are in fact *identical*. Remember that the
> typechecker simply matches on the right-hand sides ("heads") of the
> instance declarations.
No they do not overlap, unless there is an a b satisfying NodeTypeConfigParms a b
and ArcTypeConfigParms a b. Which there aint.
>
> If you do -fallow-undecidable-instances, I think your program will
> work (in the Prolog-ish backtracking way), but note that if
> NodeTypeConfigParms and ArcTypeConfigParms are ever given instances at
> the same pair of types, the value of ($$) will be undefined.
As a matter of fact I DID use -fallow-undecidable-instances, as you can see
from my original contribution . . .
___
Glasgow-haskell-bugs mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: False "duplicate or overlapping instances" message
> Instances.hs:1:
> Duplicate or overlapping instance declarations
> for `HasConfig (arcTypeConfig value) (arcTypeParms value)'
> defined at Instances.hs:19 and defined at Instances.hs:11
>
> This is not fair, because while the instances for HasConfig have the
> potential to conflict in the future, they will only do so should the classes
> NodeTypeConfigParms and ArcTypeConfigParms overlap.
It is fair. Let's rename your type variables to make what's going on a little clearer:
main = return ()
class HasConfig a b where
($$) :: a -> b -> b
class NodeTypeConfigParms a b where
nodeTypeConfig :: a c -> b c -> b c
instance (NodeTypeConfigParms a b) => HasConfig (a c) (b c) where
($$) = nodeTypeConfig
class ArcTypeConfigParms a b where
arcTypeConfig :: a c -> b c -> b c
instance (ArcTypeConfigParms a b) => HasConfig (a c) (b c) where
($$) = arcTypeConfig
You can now see that the two instance declarations overlap: their
right hand sides are in fact *identical*. Remember that the
typechecker simply matches on the right-hand sides ("heads") of the
instance declarations.
If you do -fallow-undecidable-instances, I think your program will
work (in the Prolog-ish backtracking way), but note that if
NodeTypeConfigParms and ArcTypeConfigParms are ever given instances at
the same pair of types, the value of ($$) will be undefined.
--KW 8-)
___
Glasgow-haskell-bugs mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
False "duplicate or overlapping instances" message
When I compile the attached file on Linux with 4.08.1: /home/ger/ghc-4.08.1-binary/bin/ghc -c Instances.hs -fglasgow-exts -fallow-overlapping-instances -fallow-undecidable-instances I get the message: Instances.hs:1: Duplicate or overlapping instance declarations for `HasConfig (arcTypeConfig value) (arcTypeParms value)' defined at Instances.hs:19 and defined at Instances.hs:11 This is not fair, because while the instances for HasConfig have the potential to conflict in the future, they will only do so should the classes NodeTypeConfigParms and ArcTypeConfigParms overlap. Instances.hs
