|View Issue Details|
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0000311||mercury||Bug||public||2014-01-23 06:09||2014-01-28 16:31|
|Platform||i686||OS||Linux Debian||OS Version||3.2.46-1+deb7u1|
|Target Version||Fixed in Version|
|Summary||0000311: Gathering solutions depends on how predicate is programmed|
|Description||I 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
|Tags||No tags attached.|
|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.|
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.
|The delay_partial_inst.m pass does something like that.|
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.
|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|