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

[Peter Moulder]

On balance I think I agree, though I'm not certain.

Some opposing points:

I'm always cautious of transformations, like `@' and `where' and indeed 
function calls in general, that insert extra goals.

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

  - 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.)

  - 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.  In p(!A, E
    where q(!A)), I believe the order of the A numbering would be p(A1,
    A2, E where q(A0, A1)), i.e. different from the syntactic order of
    the `!A' occurrences.  I believe ((E where G1) where G2) is another
    example where expanded order differs from syntactic order, which
    would confound a casual reading of such code, leading to bugs not
    being noticed.

    (If I'm wrong about those examples, then I suppose it supports the
    claim that the ordering isn't obvious.)


I wonder if `X = Y where G' might be misread by some as `G => (X = Y)'
rather than `G, (X = Y)' (especially if inside `(all[Vars] ...)').
Requiring explicit parens should avoid that confusion (`X = (Y where G)').
`a(E1) where E2 = E3 = E4' (or indeed `E1 where E2 where E3 = E4 = E5 =
E6') are further examples of possibly-misleading syntax.


I wouldn't mind having a clearer idea of the benefits of `where'.
I'd have thought that functional if-then-elses tend to become less
useful when they're long/complex (e.g. if they contain where clauses),
as it makes it harder for the programmer to keep in mind ("on the
stack") the context of the if-then-else expression.  However, I don't
use functional if-then-elses very widely (partly due to conflicts with
state variables in some versions of the compiler).

pjm.

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