[mercury-users] Higher order programming

[Fergus Henderson]

On 23-Apr-1999, Lee Naish <lee at cs.mu.OZ.AU> wrote:
> 
> >  For the Mercury CLP(R)
> >interface, we clearly want to use functional syntax; using relational
> >syntax for arithmetic expressions leads to code which is much harder
> >to read.
> 
> Agreed.  This seems to be the main reason for using functional syntax in
> a non-FP way.  With CLP you completely abandon any idea of modes and
> determinism.

You do need dynamic modes, but you don't have to abandon mode and determinism
completely.  The Mercury CLP(R) interface uses modes and determinism.
For example, '+' has the following modes:

	:- func '+'(cfloat, cfloat) = cfloat.
	:- mode '+'(any  -> any, any  -> any) = (any  -> any) is semidet.
	:- mode '+'(free -> any, any  -> any) = (any  -> any) is det.
	:- mode '+'(any  -> any, free -> any) = (any  -> any) is det.
	:- mode '+'(any  -> any, any  -> any) = (free -> any) is det.

The `any' inst here is used for dynamic moding; it indicates a constrained
value that could be free, ground, or somewhere in between.

The determinism declarations mean that if any one of the two args or
the return value is initially free, then the compiler (or user) can
be sure that the call will not fail.  Also, since none of these modes
have determinism `nondet' or `multi', the compiler (or user) can be
sure that calls to `+' will not create any choice points.
The Mercury compiler makes uses of this information to generate more
efficient code.

> One possibility is to treat this kind of code specially,
> for example, in Sicstus, CLP(R) constraints have to be enclosed within
> braces (something Peter hates, mind you) and this may permit more
> flexibity.

I don't really like that solution very much.  If the aim is just to be
able use a slightly more convenient syntax for higher-order code, then
requiring functions to only have one mode seems like overkill, especially
if it means that constraint solving code has to use a less convenient
syntax.

I think it would be better to modify the way the compiler supports
higher-order insts so that the compiler can infer the correct mode
for higher-order arguments.  This is not easy, so I don't see it as
happening soon (in particular we should at least wait until after
the alias tracking stuff has been integrated into the main development
branch), but it's also not impossible, and I think doing in the long
run doing that would be a cleaner solution.

> Another is to (possibly) change how the CLP(R) interface
> works - does it really need reversible Mercury functions? Doesn't the
> CLP(R) version of plus just make some connection between its arguments +
> result with things inside the solver (rather inefficiently) without
> much regard for modes?

The CLP(R) interface uses multiple modes to allow the compiler to properly
infer determinism.  See the example above.

-- 
Fergus Henderson <fjh at cs.mu.oz.au>  |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>  |  of excellence is a lethal habit"
PGP: finger fjh at 128.250.37.3        |     -- the last words of T. S. Garp.
--------------------------------------------------------------------------
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
--------------------------------------------------------------------------