[mercury-users] Modes in "int" module.

[Ralph Becket]

Bartlomiej Szymczak, Tuesday, 10 July 2007:
> On 7/10/07, Ralph Becket <rafe at csse.unimelb.edu.au> wrote:
> >Bartlomiej Szymczak, Monday,  9 July 2007:
> >> Hello.
> >>
> >> I don't understand one thing in the "int" library module:
> >>
> >>     :- pred int.max(int::in, int::in, int::out) is det.
> >>
> >>     :- func int + int = int.
> >>     :- mode in  + in  = uo  is det.
> >>
> >> Both operations (max and +) have the same type from mathematical point
> >> of view - they take two numbers and deterministically produce another
> >> number.
> >>
> >> What I don't understand is why + produces result in mode uo. Shouldn't
> >> it produce result in mode out, like max does?
> >
> >The uo mode is mainly there for hysterical raisins.
> >Usually the output of an addition is a new integer, whereas the output
> >of max is one of its inputs, hence the justification for uo for +, but
> >not max.  In practice we don't properly support uniqueness yet (for which
> >we're slightly embarrassed!), but we're hoping to get a PhD student on
> >board to redo the mode system, at which point hopefully uniqueness will
> >work properly.
> >
> 
> Thanks for your answer, Ralph. :-)
> 
> I don't quite see how that fact can decide about uo or out mode. So
> whenever a function outputs something which is not one of it's inputs,
> it should make it uo? I thought uo is suited for outputs that should
> be only used once (like arrays, hash tables), because they have state.

You can use uo for any outputs that are genuinely unique in the sense
that they share no memory structures with any other values.  We can be
pretty sure that integer addition doesn't allocate any memory!

> Should the result of addition be referenced just once? I don't quite see 
> why.

Say we did have complete support for uniqueness.  In that case the
compiler needs to know which outputs are unique.  In a practical sense,
all integer values can be treated as unique since they are not memory
objects.  Note that there is nothing to stop you using a unique object
in a shared context: the only consequence is that afterwards the object
is no longer unique.

> >> Additionally I don't like that there are only functions to do some
> >> things. It would be really nice for me if predicate versions were
> >> provided.
> >
> >Our convention is that relations with mode (in, in, ..., in, out) is det
> >should be functions and all others should be predicates.  Of course, we
> >don't strictly stick to this for (a) historical reasons and (b) field
> >access functions.
> 
> It's just that I prefer notation resembling predicate logic. And if I
> use only predicates, without functions, I can use Prolog's top-level
> to test my predicates. As far as I can remember, that's how first
> version of Mercury compiler was bootstrapped. Functions just make it
> impossible.

But functions do make coding in Mercury much more comfortable than in
Prolog.  It isn't that much work to write test code in Mercury and the
Mercury debugger allows you to trace execution in much the same way as
you can in Prolog.

> >> One more problem is that in the documentation the modes for int.plus
> >> function are not shown:
> >> :- func int.plus(int, int) = int.
> >
> >A func with no mode takes the default mode (in, in, ..., in) = out is det.
> >It's a useful shorthand.
> 
> Yes, the shorthand is useful, but now I'm confused even more. It turns
> out that "+" has "uo" output, but "plus" has "out" output, according
> to the convention. Am I right?
> 
> It's really confusing, eg.:
> 
>         % addition
>         %
>     :- func int + int = int.
>     :- mode in  + in  = uo  is det.
>     :- mode uo  + in  = in  is det.
>     :- mode in  + uo  = in  is det.
> 
>     :- func int.plus(int, int) = int.
> 
> I thought that plus has the same modes as +, just prefix syntax
> instead of infix.

It is confusing and the only reason is that for ints out and uo are
functionally equivalent (ints are not memory objects).

> Do all other prefixed int operations produce "out" output? That would
> be more convenient for me than "uo".

You can always treat a uo as an out.

Cheers,
-- Ralph
--------------------------------------------------------------------------
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
--------------------------------------------------------------------------