[mercury-users] Compiler warning for implicit mode?

[Jeff Thompson]

The language reference manual section 4.4 "Different clauses for 
different modes" has the example to use other_append when it is more 
efficient:
:- pred append(list(T), list(T), list(T)).
:- mode append(in, in, out) is det.
:- mode append(out, out, in) is multi.
:- mode append(in, out, in) is semidet.
:- mode append(out, in, in) is semidet.

:- pragma promise_equivalent_clauses(append/3).
append(L1::in, L2::in, L3::out) :- usual_append(L1, L2, L3).
append(L1::out, L2::out, L3::in) :- usual_append(L1, L2, L3).
append(L1::in, L2::out, L3::in) :- usual_append(L1, L2, L3).
append(L1::out, L2::in, L3::in) :- other_append(L1, L2, L3).

Note that none of the modes is append(in, in, in).  If append is called 
with this mode, Mercury will implicitly call one of the modes with an 
"out" argument and check for equivalence when it returns.  Normally if 
there is only one clause this is OK. But in this case, Mercury could 
implicitly call either append(out, in, in) or one of the other modes 
which have different implementations and could lead to unexpected behavior.

When the clauses specify the mode, is there a way to get the compiler to 
issue a warning if it has to implicitly create another mode?  (I know 
that, given promise_equivalent_clauses, any one should be OK, but I'm 
worried about that the compiler could pick the inefficient 
implementation.)  Or is it recommended that I specify all possible modes 
every time I use this language feature to be sure the compiler will 
implicitly pick the desired implementation?

Thanks,
- Jeff

--------------------------------------------------------------------------
mercury-users mailing list
Post messages to:       mercury-users at csse.unimelb.edu.au
Administrative Queries: owner-mercury-users at csse.unimelb.edu.au
Subscriptions:          mercury-users-request at csse.unimelb.edu.au
--------------------------------------------------------------------------