2024-03-29 16:23 AEDT

View Issue Details Jump to Notes ]
IDProjectCategoryView StatusLast Update
0000311mercuryBugpublic2014-01-28 16:31
Reporterplsm 
Assigned Tozs 
PrioritynormalSeverityminorReproducibilityalways
StatusassignedResolutionopen 
Platformi686OSLinux Debian OS Version3.2.46-1+deb7u1
Product Version 
Target VersionFixed in Version 
Summary0000311: Gathering solutions depends on how predicate is programmed
DescriptionI have a predicate that has several solutions that I want to collect. Depending on how I program the predicate, either all solutions are correctly collected by predicates in module solutions, or some solutions or even just one are returned by predicates.

I have tested in mercury compiler 11.07 and 13.05.2
TagsNo tags attached.
Attached Files

-Relationships
+Relationships

-Notes

~0000618

zs (developer)

The file bug311.m I just uploaded is a simplified version of the original test case. It has a comment at the top (a) diagnosing the problem, (b) proposing some solutions, and (c) recommending a workaround that works right now.

~0000619

zs (developer)

I have just thought of a better fix.

Mark every variable which satisfies the conditions that lead to the problem (such as G in the example).
For every unification which fills in some field(s) of G but does not make G ground, eliminate the unification, but record which fields are filled in, with what values. When we come to a unification that grounds G by filling in its remaining field(s), replace that with a unification that creates G from scratch, filling in all its fields all at once.

This effectively transforms lattice_bad to lattice_bad_fixes inside the compiler.

This solution works if all fields of a cell have to be filled in by unifications in the same predicate body, because *calls* are not allowed to fill in fields of preexisting cells. I think we currently impose that restriction (indirectly, via limitations of the mode system), but I am not sure.

~0000620

wangp (developer)

The delay_partial_inst.m pass does something like that.

~0000623

zs (developer)

Yes, it does try to handle things like that. However, I just checked, and it screws up on this test case in two separate and distinct ways. First, it does not properly handle the two unifications in a row that fill in the xsize and ysize fields of G. Second, while it handles the first disjunct ok, it screws up the second, thinking that the unifications generated in the first disjunct hold in the second as well. (There is already an XXX in the code for disjunctions, but that comment does not consider this scenario.)

I will look into whether we can modify delay_partial_inst.m to handle this situation.
+Notes

-Issue History
Date Modified Username Field Change
2014-01-23 06:09 plsm New Issue
2014-01-23 06:09 plsm File Added: bugSolutions.m
2014-01-28 14:24 zs File Added: bug311.m
2014-01-28 14:25 zs Note Added: 0000618
2014-01-28 14:26 zs Priority high => normal
2014-01-28 14:26 zs Severity major => minor
2014-01-28 14:42 zs Note Added: 0000619
2014-01-28 15:05 wangp Note Added: 0000620
2014-01-28 16:30 zs Note Added: 0000623
2014-01-28 16:31 zs Assigned To => zs
2014-01-28 16:31 zs Status new => assigned
+Issue History