Nicolas Frisby wrote:
> I don't see how it's too complex. Isn't
>> infixl ??
> prec ?? < $
> (??) = whenOperator
>> exactly what you want to say?
Yes. I'd add that the system should (of course) take the transitive closure
over all explicitly stated precedence relations. That really cuts down the
number of cases one needs to specify. For instance, we'll want the Prelude
operators to retain their relative precedences, so Prelude will contain
(using a slightly changed syntax):
prec ($ $! seq) < (>> >>= =<<) < (||) < (&&) < (== /= < <= >= >) < (:)
prec (:) < (+ -) < (* / quot rem div mod) < (^ ^^ **) < (.)
(Syntax summary:
* ops with equal precedence are grouped by parentheses which are mandatory
even if they contain only a single operator
* precedence relations may use '<' or '>' between equality groups
* no commas between operators are necessary if they are seperated by
whitespace
* backticks for operators with function names can be left out)
Fixity would have to be declared separately as (using 'infixl' or 'infixr';
or whatever).
Whenever we would currently declare an operator as having precedence N, we'd
now declare it to have precedence equal to one or more operators from the
corresponding precedence group, e.g.
prec (<+> +)
or, if you like
prec (<+> + -)
However
prec (<+> + *)
would be an error because (*) and (+) have previously been declared to have
different precedence.
Compilers can support a special command line switch "--dump-precedences")
(and interpreters an interactive command) to display the precedences of all
operators in scope in some module. (The latter would be quite a useful
addition even with the current numerical precedence system).
The more I think about it the more I like the idea.
Cheers,
Ben