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

[Ralph Becket]

Fergus Henderson, Tuesday,  5 August 2003:
> On 05-Aug-2003, Peter Schachte <schachte at cs.mu.OZ.AU> wrote:
> > On Mon, Aug 04, 2003 at 05:36:54PM +1000, Peter Moulder wrote:
> 
> > 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.
> 
> Yes, I agree.  Although the requirement should be the same as for functions:
> it should only be prevented from having more than one solution in
> the forwards mode (the one in which the result of the where expression
> has an output mode and all of the other non-local variables have an
> input mode).  If some of the non-local variables other than
> those in the result have output modes, it should be OK for the where
> expression to be nondeterministic.
> 
> This determinism requirement is necessary for consistency with the way
> we treat functions.  Unfortunately, however, it will make the proposal
> a bit more difficult to implement.  In particular, we will need to keep
> track in the HLDS of which goals came from a `where' expression, so that
> determinism analysis can check their determinism.

I've often thought that it would be useful to have inst and/or
determinism annotations on predicates and expressions just as we have
`with_type` annotations.

I think such a thing would simplify the problem.

Would this be difficult to do?

> That in turn also means that we should not allow mode reordering to
> break up where expressions.

I'm being a bit dense today - can you provide an example where
reordering would be significant?

> > >   - 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.
> 
> For the purposes of state variables, I think we should treat a where
> expression `<Expr> where <Goal>' the same way as a function call with
> a lambda expression, `<Expr> = f((pred) is semidet :- <Goal>)'.

State variables cannot be updated inside expressions anyway.  This is a
non-issue.

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