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