[mercury-users] det & cc_multi question

Vladimir Gubarkov xonixx at gmail.com
Sun May 16 23:46:07 AEST 2010


Hi Dear sirs

let's look at code


:- module tst2.

:- interface.

:- import_module io.

:- pred main(io, io).
:- mode main(di, uo) is det.

:- implementation.


:- import_module solutions, list, int.

main -->
    {
     promise_equivalent_solutions [L] unsorted_solutions((pred(E::out) is
nondet :-
                                 member(E, 1..20),
                                  E mod 3 = 0
                                 ), L)
    },
    print(L).


Note, that without "promise_equivalent_solutions [L]" it gives


$ mmc tst2
tst2.m:008: In `main'(di, uo):
tst2.m:008:   error: determinism declaration not satisfied.
tst2.m:008:   Declared `det', inferred `multi'.
tst2.m:017:   call to `solutions.unsorted_solutions'((pred(out) is nondet),
tst2.m:017:   out) can succeed more than once.
tst2.m:017: Error: call to predicate `solutions.unsorted_solutions'/2 with
tst2.m:017:   determinism `cc_multi' occurs in a context which requires all
tst2.m:017:   solutions.


while compiling.

I've read some documentation on cc_multi, and I seem to understand the
meaning of cc_multi. It's used when we defining predicate as being multi,
but using it in place where we nead only 1 solution (actually, anyone.. this
is determined by compiler what solution to return taking in mind
optimization concerns). What I can't understand is why should I explicitely
convert it to det with "promise_equivalent_solutions [L]". Why compiler is
not smart enough to make this automatically? I know that I could
alternatively make cc_multi my main predicate.. But what if I have some
architecture with many det predicates. This would mean that I should then
turn all those preds to cc_multi.. I don't like this..

I've also read this thread that seem to relate to my questions

http://www.mercury.csse.unimelb.edu.au/mailing-lists/mercury-developers/mercury-developers.0108/0034.html

but still it's not very clear.

Also, it seems not very logical to me that aggregate and solutions
predicates perform sorting & removing duplicates. It seems more logical that
those perform as their unsorted_ counterparts and additional sorted_
versions be present.

I beg pardon for my, most likely, stupid questions =)

Sincerely yours,
Vladimir
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mercurylang.org/archives/users/attachments/20100516/2efa52ac/attachment.html>


More information about the users mailing list