Mercury Bugs - mercury
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0000122mercuryBugpublic2009-12-18 20:182010-01-18 18:33
Reportermva 
Assigned Tomark 
PrioritynormalSeverityminorReproducibilityalways
StatusresolvedResolutionfixed 
PlatformOSOS Version
Product Version 
Target VersionFixed in Version 
Summary0000122: Functional dependency typeclass instance in module with sub-module int0 error
DescriptionI experience a bug in the Mercury compiler to do with int0 and typeclass instances.

If you have an abstract typeclass instance in a module which has a sub-module, the int0 file has two instances declaration, which can lead to a self-conflicting declaration.


Mercury/int0s/tcin.int0:011: Inconsistent instance declaration for typeclass
Mercury/int0s/tcin.int0:011: `tc.tc'/2 with functional dependency `(A -> B)'.
Mercury/int0s/tcin.int0:008: Here is the conflicting instance.
** Error making `Mercury/cs/tcin.sub.c'.


While there is no conflicting typeclass instance.

You can find attached a small test case exposing this bug.

Commenting the include_module tcin.sub in tcin.m is sufficient to make it compile properly.
TagsNo tags attached.
Relationships
Attached Fileszip tcinsub.zip (975) 2009-12-18 20:18
https://bugs.mercurylang.org/file_download.php?file_id=91&type=bug

Notes
(0000237)
wangp   
2010-01-04 17:40   
check_consistency_pair_2 in check_typeclass.m looks suspicious, specifically the RangeA = RangeB test.
(0000243)
mark   
2010-01-12 17:22   
The check_consistency_pair_2 predicate is doing what it's meant to: it checks the "consistency" condition, namely that any unifier for the domain of a functional dependency is also a unifier of the range.

The problem is that this doesn't work nicely with the weakened form of the "coverage" condition. The full coverage condition says that any type variables appearing in the range of a functional dependency must also appear in the domain, where they will be bound by the above unifier. The weakened coverage condition says merely that they should either appear in the domain or be captured by some functional dependency derived from the instance constraints, but in the latter case they will not be bound by the above unifier. The paper [1] does not seem to say anything about the issue, so it's going to need further investigation.

One thing that is exacerbating the problem is that duplicate abstract instances end up in the .int0 file, which is what triggers the problem in this case. Same thing arises if an abstract instances is duplicated in a .m file.

[1] M. Sulzmann, G. Duck, S. Peyton-Jones, P. Stuckey, "Understanding Functional Dependencies via Constraint Handling Rules", JFP 2006.
(0000246)
mark   
2010-01-18 18:33   
On further investigation, the issue with the "weakened coverage" condition is not actually a problem. In this case it is intended that instances may be found to be inconsistent even if identical. (It is analogous to a disjunction being considered multi/nondet even if the disjuncts are identical.)

The problem has been fixed by not performing the consistency check on pairs of instances that are imported from the same module. The proper check will be done when that module is itself compiled.

Issue History
Date ModifiedUsernameFieldChange
2009-12-18 20:18mvaNew Issue
2009-12-18 20:18mvaFile Added: tcinsub.zip
2010-01-04 17:40wangpNote Added: 0000237
2010-01-12 17:22markNote Added: 0000243
2010-01-13 12:41juliensfStatusnew => assigned
2010-01-13 12:41juliensfAssigned To => mark
2010-01-18 18:33markNote Added: 0000246
2010-01-18 18:33markStatusassigned => resolved
2010-01-18 18:33markResolutionopen => fixed