Re: Priorities of (non)operators.

[Kent Karlsson <kent@se.chalmers.cs>]

Original-Via: uk.ac.ukc; Wed, 13 Mar 91 15:50:58 GMT
From: Kent Karlsson <kent@se.chalmers.cs>
Date: Wed, 13 Mar 91 16:33:26 +0100
To: haskell@cs.glasgow.ac.uk
Subject: Re: Priorities of (non)operators.
Original-Sender: kent%se.chalmers.cs@sunic.sunet.se
Sender: haskell-request@cs.glasgow.ac.uk

> 
> If you parse 
> > (i)   as          (if a then b else  \x -> c) where {...}
> you can be accused of ignoring that where binds more tightly than
> lambda.
> If you parse
> > (ii)  or as        if a then b else (\x -> c  where {...})
> 
> no such accusation can be leveled at you.

It's not quite that easy, however.  There are at least four different
ways of interpreting priority specifications.

1) yacc's 'throw-away transitions' approach (only works with
   (S/LA)LR(>=1)-parsing): yields (ii).
2) precedence parsing's (or forms derived therefrom): yields (ii).
3) in a derivation of the string, if there are several alternative
   productions to choose from, choose the one(s) with lowest priority:
   yields (i), since 'where' has lower priority than 'if'.
4) the simple one-dimentional syntactic subclassing approach
   (the one I used): yields (iii) (i.e. syntax error, parenthetisation
   required).

The problem with approach (1) is its limited applicability; the
problems with (2) are (a) the obsoleteness of precedence parsing,
it can be built into the grammar though, but (b) not so easy;
the problem(?) with (3) is that at least I (correct me if it can)
don't know if it even can be built into the grammar.

In (4), however, the interpretation can *easily* be built into the grammar,
and it is applicable in *all* parsing methods, the priority scheme can
even (easily, at least in principle) be built into the parser(-generator),
thus not requiring the (inefficient) 'e(j) -> e(j+1)'-productions.


Interpretation (4) is clear, concise, precise, easy to understand, and
easy to implement, but:

I think there is an another "easy" way out (I don't like it, but there is):
(Re)order the priorities thus (yields reading (i) of my example):

	case-expressions (atomic, for the sake of symmetry)
	application expressions (prio 10, left assoc)
	binary operator expressions (0-9, incl. unary minus)
	type restriction expressions
	if-expressions
	lambda-abstractions
	where-expressions (**used to** bind tighter than lambda...)

then the four priority interpretations will (**happen to**) coinside.
The interpretation of the priority of unary minus could vary slightly,
so that (1), (2), and (3) allow  e.g.  a * -b, but that is a syntax
error according to (4).  I don't think there is any problem, though, in 
postulating that  a * -b  and similar expressions are syntax errors,
just as it has been done for certain other operator expressions already,
and adjust the parsing process accordingly.

			/kent k
PS
Yet another alternative it to let 'where' bind tighter than 'if',
but I suppose you really don't want that.