[m-dev.] Ordered conjunction

[Fergus Henderson]

On 25-Aug-2000, Robert Jeschofnik <rejj at students.cs.mu.oz.au> wrote:
> On 25-Aug-2000, Fergus Henderson <fjh at cs.mu.OZ.AU> wrote:
> > On 24-Aug-2000, Erwan Jahier <Erwan.Jahier at irisa.fr> wrote:
> > > Ralph Becket <rbeck at microsoft.com> writes:
> > > 
> > > > I know this has come up before, but I just want to restate the case
> > > > for an ordered conjunction (P && Q) which constrains the compiler to
> > > > call P before Q (for && pick the symbol of your choice).
> > > 
> > > What about `then'? It seems to me that it a degenerated case of
> > > if-then-else where there is no `else' branch (or where the `else'
> > > branch it equivalent to `fail').  
> > 
> > You're right about the semantics of `P && Q' being the same
> > as `if P then Q else fail' or `P -> Q ; fail'.
> 
> What about scoping, though?
> 
> In `(P -> Q ; fail), R' I'm not allowed to use variables that are bound inside
> P, instead they must be bound inside Q.
>
> It would not make much sence to enforce this same restriction on `P && Q, R'.

Oh, good point.  I hadn't thought of that.  I agree with your
conclusion that the left-hand operand of `&&' should be allowed to
bind non-local variables.

In that case, I guess we can't get away with just a syntactic expansion.
I think this difference in mode-correctness from if-then-else is also
an argument against using `then' or `->' for the syntax.

I quite like Ralph's original suggestion of `&&' for the syntax.
The next question is what the priority and associativity should be.

I think it should be left-associative, like `,' and `&'.
(Right-associative would work OK too, but IMHO it should not be
non-associative, since that would require parentheses for `P && Q &&
R', which would be quite annoying since `(P && Q) && R' and `P && (Q && R)'
are semantically equivalent; we shouldn't force the user to add parentheses
here when they don't actually make any difference.  Given the choice
between right-associative and left-associative, I choose left-associative
since that matches `,' and `&'.)

As for precedence, one could argue that it would be best if the
parser simply disallowed expressions like `P && Q, R', instead
forcing the user to use explicit parentheses to disambiguate.
However, our current operator-precedence parser technology assumes
a total ordering on operator precedences; the only
way to make those kinds of expressions illegal without explicit
parentheses using our current parser is to make the operator(s)
concerned non-associative, and as I argued above I don't think
that is a good idea in this case.

So, given that the current parser technology, we need to choose a
precedence for `&&'.  Currently `,' has precedence 1000 and
`&' has precedence 1025 (note that a higher number actually means
the operator has a lower precedence, i.e. binds less tightly),
so `P, Q & R' parses as `(P, Q) & R'.

Personally, I think `P, Q && R' should parse as `(P, Q) && R'
and `P & Q && R' should parse as `(P & Q) && R'.  So I suggest
we give `&&' priority 1040, which is between `&' and `->' (which is 1050).
The intution behind this is that when in doubt, a sequence constraint
should be interpreted as strongly as possible, because the consequence
of interpreting it too strongly is just reduced parallelism, whereas
the consequence of interpreting it too weakly might be as bad as
an infinite loop or an unwanted exception.

Comments?

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