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

[Peter Schachte]

On Mon, Aug 04, 2003 at 03:25:51PM +1000, Ralph Becket wrote:
> > The only problem with this is syntactic:  people will tend to write
> > 	X where p(X), q(X)
> > and no doubt the error message they get will not immediately help them
> > realize the simple precedence problem.
> 
> I think this is a worse problem than prefering "where" to ":-".
> ... one would have to write
> 
> 	f(X) = (Y where p(X, Y)).

Ah, syntax again.  OK, after thinking about it more, I agree.  I don't
like the extra parentheses that will *always* be required, but the
compiler will handle their omission with the precedence you propose
better than with what I suggested.



On Mon, Aug 04, 2003 at 05:36:54PM +1000, Peter Moulder wrote:
>   - Interactions with `not', especially "hidden" not's such as with
>     `\='.  One needs to know that the extra goals come inside the scope
>     of that `not'.  I feel this leads to counter-intuitive behaviour of
>     `=' vs `\=' when the inserted goals can fail.

OK, this requires care.  Take 3 \= (X where p(3, X)) when p(in,out)
is semidet.  This could sensibly mean:

	p(3, X),
	3 \= X

or

	\+ p(3, 3)

But this must have already been addressed for handling semidet
functions.  It should be handled however Mercury handles

	3 \= p(3)

when p/1 is a semidet function.


>   - If the inserted goals can fail or produce multiple solutions, then
>     EXPR = EXPR can fail.  (IIRC, one reason that Mercury doesn't
>     support multi/nondet functions was to avoid cases where EXPR = EXPR
>     fails.)

How can EXPR = EXPR fail?  Both occurrences of EXPR have the same set
of solutions, and all of them satisfy EXPR = EXPR.  The cost of
computing all solutions of this is the square of the cost of computing
all solutions of EXPR alone, though.

I think the real problem is splittng a nondet function returning a
bundle of values into separate nondet functions returning parts of the
bundle.  This loses the correspondence between the elements of the
bundle.

Alright, so require (... where ...)  to have at most 1 solution.
That's in keeping with the idea that (... where ...) is a functional
form that behaves the way function application behaves.

>   - The order of the goals can be significant (e.g. performance, or
>     completeness guarantees with fully-strict), yet it isn't always
>     obvious what the order will be.  Unlike `@' and function calls,
>     `where' presumably allows state variable transformations, where
>     mistakes in understood ordering affect program logic.

Good point.  Best not allow state variables in where expressions,
again in keeping with the (... where ...) is a functional form
principle.

> I wouldn't mind having a clearer idea of the benefits of `where'.

It's a nestability thing.  You can put function invocation inside of
goals as you like, but you can't put goals inside of function
applications (except for if->then;else expressions, and then only in
the condition).  This improves the interchangability of the two
syntaxes.


-- 
Peter Schachte              Algorithms are inherently mathematical things that
schachte at cs.mu.OZ.AU        should be as un-patentable as the value of pi.
www.cs.mu.oz.au/~schachte/      -- Donald Knuth 
Phone: +61 3 8344 1338      
--------------------------------------------------------------------------
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
--------------------------------------------------------------------------