[mercury-users] Higher order programming

[Lee Naish]

In message <19990422171708.A5772 at murlibobo.cs.mu.OZ.AU>Fergus wrote:
>> I think this problem would be easier to solve if there was less
>> distinction between predicates and functions.
>
>That could solve the problem of predicates not taking `function' HO args.
>
>But I don't think it would solve the problem of the compiler not being
>able to infer the modes for higher-order terms.

I mentioned this for the multi-moded case - the map2 predicate call.

>If a predicate
>has more than one det mode, which one would the compiler choose?

The (only) one declared as a function by the user.

>Why would only one mode be associated with the function?

The same reason you allow only one determinism: it allows the functional
syntax to convey more meaning (to the compiler and the human reader).

>Well, in Mercury functions are allowed to have more than one mode.
>The `+' function may be reversible.  So a goal using a functional
>expression like `Cs = map2((+), As, Bs)' might be computing
>As from Bs and Cs rather than computing Cs from As and Bs.

If + also had the nondet mode computing A and B from C (reasonable if
they are known to be natural numbers) you could use the syntax above for
a nondeterministic computation also.  Is this a good idea?  It adds more
"power"/flexibility, but I would argue its *not* a good idea. Similarly,
multi-moded functions are not a good idea.

In the original design of NUE-Prolog functional syntax was flattened
into predicates but there was no restriction on the directionality or
determinism.  In later versions this was changed.  This allowed the
translator to add when declarations (since the mode was known), thus
avoiding choice points ever being created, and to check determinism and
generate warning messages.  Similarly the human reader was able to infer
mode and determinism information whenever functional syntax was used.
This gained more benefit from the functional syntax. In the case of
Mercury, an advantage you would get is the compiler could figure out the
modes in Cs = map2((+), As, Bs).

The functional programmers get by without nondeterministic/multi-moded
functions.  If you are programming in that style you don't need them.
If you are not programming in that style, why not use relational syntax
instead?

And as a matter of style, if you have a function with an inverse which
is also a function, for example plus, I suspect the inverse is
best called something else, for example, minus.  Instead of
X = plus(Y,Z), you could write Z = minus(Y,X) (more readable, no?),
with the definition

minus(Y, X) = Z :- plus(Y,Z,X).

The compiler can figure out minus is det, with X and Y in and Z out,
from the syntax.  It just has to check plus(in,out,in) is defined and
is det.  Type inference should be pretty easy also.  In the worst case
you would have to write a declaration or two in addition and the
compiler might generate an extra branch instruction.

	lee
--------------------------------------------------------------------------
mercury-users mailing list
post:  mercury-users at cs.mu.oz.au
administrative address: owner-mercury-users at cs.mu.oz.au
unsubscribe: Address: mercury-users-request at cs.mu.oz.au Message: unsubscribe
subscribe:   Address: mercury-users-request at cs.mu.oz.au Message: subscribe
--------------------------------------------------------------------------