[m-dev.] Suggestion for a new "where" operator

[Fergus Henderson]

On 07-Aug-2003, Peter Moulder <pmoulder at mail.csse.monash.edu.au> wrote:
> [Interestingly, the two versions of the goal can have different
>  determinisms (or even produce a mode error in the duplicate-where
>  version) if the first p call changes the instantiatedness of X.  E.g. if
>  (p(out) is det) is chosen for the initial p(X) call (i.e. p(free >>
>  ground) is det), then the second p(X) call in the duplicate-where
>  version can resolve to (p(in) is semidet), and the compiler may
>  (over-cautiously) complain that the goal can fail.]

The same applies to ordinary functions like "+".
For instance, in the following example,

        :- func foo(int) = int.
        foo(X) = Y :-
                q(X + Y, X + Y).

	:- pred q(int::out, int::out) is det.
	q(Z, Z) :- Z = 42.

the second call to `+' will result in a determinism error,
because the first call to `+' has bound `Y'.
I don't see this as a significant problem, because it is easy
to rewrite such code in a way that avoids the determinism error.

In so far as this issue is a problem for where expressions, I think it
would in the main part be resolved by adopting scoping rules analagous
to those for lambda expressions, as I suggested in one of my earlier
posts, so that variables which occur only within `where' expressions
are scoped locally to those `where' expressions.

-- 
Fergus Henderson <fjh at cs.mu.oz.au>  |  "I have always known that the pursuit
The University of Melbourne         |  of excellence is a lethal habit"
WWW: <http://www.cs.mu.oz.au/~fjh>  |     -- the last words of T. S. Garp.
--------------------------------------------------------------------------
mercury-developers mailing list
Post messages to:       mercury-developers at cs.mu.oz.au
Administrative Queries: owner-mercury-developers at cs.mu.oz.au
Subscriptions:          mercury-developers-request at cs.mu.oz.au
--------------------------------------------------------------------------