[mercury-users] Predicate call uses the "wrong" mode

Julien Fischer juliensf at csse.unimelb.edu.au
Sun Aug 5 21:32:10 AEST 2007

On Sat, 4 Aug 2007, Nikolas Everett wrote:

> Bug or not, its unexpected.  I expected the compiler to go with the mode
> that most closely matches the state of the variables.
> Admittedly I think
> that because I'm used to dealing with Java which picks the most precisely
> defined method when doing object overloading.  So this:
> class Test {
>    protected static void doIt(Object o) {
>        System.out.println("Object");
>    }
>    protected static void doIt(String string) {
>        System.out.println("String:  " + string);
>    }
>    public static void main(String[] argv) {
>        doIt(new Integer(1));
>        doIt("SSS");
>    }
> }
> Spits out this:
> Object
> String:  SSS
> Is there a situation where you'd want to use the implied predicate instead
> of the explicit one?

Probably not, although the inverse is sometimes the case.  Sometimes the
explicit mode results in more efficient code being generated.  An example
consider the following modes of list.append/3.

 	list.append(in, in, out) 	... (1)
 	list.append(in, in, in)		... (2)

The second mode is implied by the first because we can call (1) with
the third argument being ground and what will happen is that the
compiler will call (1) and append a test unification afterwards.

 	e.g. for mode(1)


 	effectively becomes:

 		V = [6],

If we explicitly generate mode (2) the code will avoid the list

The standard library occasionally does this.  It's why some of the modes
in the list and string modules, in particular, have a comment next to
them that says "implied mode".

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

More information about the users mailing list