2019-04-19 01:01 AEST

View Issue Details Jump to Notes ]
IDProjectCategoryView StatusLast Update
0000296mercuryBugpublic2014-10-05 17:33
Reporterwangp 
Assigned To 
PrioritynormalSeverityminorReproducibilityalways
StatusnewResolutionopen 
Product Version 
Target VersionFixed in Version 
Summary0000296: ui mode and multiple clauses
Descriptionfrom 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]
     ).
TagsNo tags attached.
Attached Files

-Relationships
+Relationships

-Notes

~0000791

mark (administrator)

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

-Issue History
Date Modified Username Field Change
2013-07-31 12:58 wangp New Issue
2014-10-05 17:33 mark Note Added: 0000791
+Issue History