View Issue Details [ Jump to Notes ] | [ Issue History ] [ Print ] | ||||||||||||
ID | Project | Category | View Status | Date Submitted | Last Update | ||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|
0000296 | mercury | Bug | public | 2013-07-31 12:58 | 2014-10-05 17:33 | ||||||||
Reporter | wangp | ||||||||||||
Assigned To | |||||||||||||
Priority | normal | Severity | minor | Reproducibility | always | ||||||||
Status | new | Resolution | open | ||||||||||
Product Version | |||||||||||||
Target Version | Fixed in Version | ||||||||||||
Summary | 0000296: ui mode and multiple clauses | ||||||||||||
Description | from Michael: This code triggers a mode error: :- mode get_text_content0(in, out, ui) is det. get_text_content0([], [], _IO). get_text_content0([Node|Nodes], [Text|Texts], IO) :- get_text_content_from_node(Node, Text, IO), % <-- error here for IO get_text_content0(Nodes, Texts, IO). However if I write the switch explicitly, it's fine: get_text_content0(Nodes, Texts, IO) :- ( Nodes = [], Texts = [] ; Nodes = [Node|Nodes0], get_text_content_from_node(Node, Text, IO), get_text_content0(Nodes0, Texts0, IO), Texts = [Text|Texts0] ). | ||||||||||||
Tags | No tags attached. | ||||||||||||
Attached Files |
|
Notes | |
mark (administrator) 2014-10-05 17:33 |
The explanation for this is that the introduction of HeadVars introduces extra unifications, and these cause the ui term to lose its uniqueness according to the mode analyser. HeadVars are always introduced, but in some cases (such as when a predicate is defined in a single clause) this introduction is reversed in order to retain meaningful variables names in the debugger. A side effect of this reversal is that the mode analyser no longer always chokes. Using a single clause seems to be an effective workaround for the real bug, which is that the mode analyser doesn't properly keep track of uniqueness. |