| View Issue Details [ Jump to Notes ] | [ Issue History ] [ Print ] | ||||||||
| ID | Project | Category | View Status | Date Submitted | Last Update | ||||
|---|---|---|---|---|---|---|---|---|---|
| 0000122 | mercury | Bug | public | 2009-12-18 20:18 | 2010-01-18 18:33 | ||||
| Reporter | mva | ||||||||
| Assigned To | mark | ||||||||
| Priority | normal | Severity | minor | Reproducibility | always | ||||
| Status | resolved | Resolution | fixed | ||||||
| Product Version | |||||||||
| Target Version | Fixed in Version | ||||||||
| Summary | 0000122: Functional dependency typeclass instance in module with sub-module int0 error | ||||||||
| Description | I 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. | ||||||||
| Tags | No tags attached. | ||||||||
| Attached Files |
| ||||||||
 Relationships |
|
 Relationships |
| Notes |
|
|
wangp (developer) 2010-01-04 17:40 |
check_consistency_pair_2 in check_typeclass.m looks suspicious, specifically the RangeA = RangeB test. |
|
mark (administrator) 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. |
|
mark (administrator) 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. |
| 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 |