2019-09-20 11:07 AEST

View Issue Details Jump to Notes ]
IDProjectCategoryView StatusLast Update
0000122mercuryBugpublic2010-01-18 18:33
Reportermva 
Assigned Tomark 
PrioritynormalSeverityminorReproducibilityalways
StatusresolvedResolutionfixed 
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.
Attached Files

-Relationships
+Relationships

-Notes

~0000237

wangp (developer)

check_consistency_pair_2 in check_typeclass.m looks suspicious, specifically the RangeA = RangeB test.

~0000243

mark (administrator)

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 (administrator)

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.
+Notes

-Issue History
Date Modified Username Field Change
2009-12-18 20:18 mva New Issue
2009-12-18 20:18 mva File Added: tcinsub.zip
2010-01-04 17:40 wangp Note Added: 0000237
2010-01-12 17:22 mark Note Added: 0000243
2010-01-13 12:41 juliensf Status new => assigned
2010-01-13 12:41 juliensf Assigned To => mark
2010-01-18 18:33 mark Note Added: 0000246
2010-01-18 18:33 mark Status assigned => resolved
2010-01-18 18:33 mark Resolution open => fixed
+Issue History