<blockquote style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;" class="gmail_quote">The problem is that may not be uniquely defined. If you have :- mode foo(out,out) is multi. :- mode foo(in, out) is det. :- mode foo(out, in) is det. and call it in mode (in,in), which mode "most closely matches" the state of the variables? The only thing you can be sure of is that it's not the first one. </blockquote><div> You have a point there. I see a couple of options: <ol><li>Change nothing and very explicitly document the behavior. This doesn't take much time but might confuse those that don't get that far in the documentation. </li><li>Call using foo(in, in) an error if foo(in, out) and foo(out, in) are defined and foo(in, in) isn't explicitly defined. This would break old code. I wouldn't be surprised if it broke the compiler. On the other hand, the fix is reasonably easy. </li><li>From Nick: Call it an error if foo(in, in) is not defined and both foo(in, out) and foo(out, in) are defined. This has the advantage of catching the situation early but it may generate more errors and code then is needed. </li><li>#2 but substitute the word warning for error and default using the order in the file, the overall mode (probably the wrong term, what I mean is det, semidet, multi, nondet, etc), or something else. </li><li> #3 but substitute the word warning for error and default using the order in the file, the overall mode, or something else.</li><li>Default using the overall mode ala Peter. </li></ol></div>Any other ideas? --Nik <div>On 06/08/07, Nicholas Nethercote <<a href="mailto:njn@csse.unimelb.edu.au" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">njn@csse.unimelb.edu.au </a>> wrote: <blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">On Mon, 6 Aug 2007, Peter Schachte wrote: > The problem is that may not be uniquely defined. If you have > > :- mode foo(out,out) is multi. > :- mode foo(in, out) is det. > :- mode foo(out, in) is det. > > and call it in mode (in,in), which mode "most closely matches" the state of the > variables? The only thing you can be sure of is that it's not the first one. > If you instead have > > :- mode foo(out,out) is multi. > :- mode foo(in, out) is nondet. > :- mode foo(out, in) is semidet. > > would you expect Mercury to prefer the semidet mode over the nondet one, and > choose the third? That'd be nice. We have a similar thing in Zinc with overloading, and solve it by requiring that there be a version that is the glb of all the different signatures. Eg. if you have f(int, float) -> float f(float, int) -> float you also have to provide f(int, int) -> float which is the glb of the other two. (Zinc has automatic int-to-float coercions, which is why this is required.) The question for Mercury then becomes: what is the glb mean over modes and determinisms? For 'foo' above, I would guess: :- mode foo(in, in) is det. But maybe there are other complications I'm unaware of. Nick -------------------------------------------------------------------------- mercury-users mailing list Post messages to: <a href="mailto:mercury-users@csse.unimelb.edu.au" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">mercury-users@csse.unimelb.edu.au</a> Administrative Queries: <a href="mailto:owner-mercury-users@csse.unimelb.edu.au" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)"> owner-mercury-users@csse.unimelb.edu.au </a> Subscriptions: <a href="mailto:mercury-users-request@csse.unimelb.edu.au" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">mercury-users-request@csse.unimelb.edu.au</a> -------------------------------------------------------------------------- </blockquote> </div>