Fixity resolution, possible specification

Hello, I just came up with a (in my opinion) quite elegant description of fixity resolution as proposed here: http://hackage.haskell.org/trac/haskell-prime/wiki/FixityResolution Any comments on this idea (see below)? Also, I realize that I am not a member of the H' committee, but I see no reason why I can't try help out. Twan Changes to the report: == 3 Expressions == The lexical syntax is changed to: oexp -> pexp [ qop_1 pexp_1 ... qop_{n-1} pexp_{n-1}] & (\tr{expression with operators}, n>=0) | @-@ oexp & (\tr{negation}) aexp -> ... | @(@ pexp_1 qop_1 ... pexp_n qop_n @)@ & (\tr{left section}, n>=1) | @(@ qop_1 pexp_1 ... qop_n pexp_n @)@ & (\tr{right section}, n>=1) oexp replaces exp^0, pexp replaces exp^10: exp -> oexp @::@ [context @=>@] type & (\tr{expression type signature}) | oexp pexp -> @\@ apat_1 ... apat_n @->@ exp & (\tr{lambda abstraction}, n>=1) ... lexp and rexp are no longer needed. (Perhaps all but the last element of these operator chains can be restricted so they do not contain lambda, let or if. This would mean that the longest parse rule is not needed there. ) The part after "A note about parsing" is dropped. === 3.4 Operator Applications === After: The form e1 qop e2 is the infix application of binary operator qop to expressions e1 and e2. Add: If after parsing there are operator applications containing more then one operator, then fixity resolution (see Section 3.4.1) has to be performed. Add subsection: === 3.4.1 Fixity Resolution === Fixity resolution is applied after parsing to convert all operator applications to the form @e1 qop e2@. Fixity resolution is specified by the following algorithm: Let $e$ be an expression anywhere in the parse tree consisting of alternating operators and expressions. Let $O$ be the list of operator with the lowest precedence level among those in $e$. If all operators in $O$ are declared left-associative (@infixl@), then: -> $e$ is split at the rightmost element $o$ of $O$. Splitting means that in the parse tree, $e$ is replaced by @(everything in $e$ before $o$) $o$ (everything in $e$ after o)@. If all operators in $O$ are declared right-associative (@infixr@), then: -> $e$ is split at the leftmost element of $O$. If $O$ contains a single operator which is declared non-associative (@infix@), then: -> $e$ is split at that operator. In all other cases -> an error is reported. This process is repeated until all expressions contain a single operator. The fixity resolution is also applied to sections (see Section 3.5). === 3.5 Sections === Add: Just like operator applications, sections containing multiple operators are resolved using fixity resolution (see Section 3.4.1). Remove: The example about the let/lambda meta rule.

Twan van Laarhoven wrote:
Add subsection: === 3.4.1 Fixity Resolution ===
Fixity resolution is applied after parsing to convert all operator applications to the form @e1 qop e2@.
Fixity resolution is specified by the following algorithm: Let $e$ be an expression anywhere in the parse tree consisting of alternating operators and expressions. Let $O$ be the list of operator with the lowest precedence level among those in $e$. If all operators in $O$ are declared left-associative (@infixl@), then: -> $e$ is split at the rightmost element $o$ of $O$. Splitting means that in the parse tree, $e$ is replaced by @(everything in $e$ before $o$) $o$ (everything in $e$ after o)@. If all operators in $O$ are declared right-associative (@infixr@), then: -> $e$ is split at the leftmost element of $O$. If $O$ contains a single operator which is declared non-associative (@infix@), then: -> $e$ is split at that operator. In all other cases -> an error is reported.
This process is repeated until all expressions contain a single operator.
The fixity resolution is also applied to sections (see Section 3.5).
I haven't examined the above algorithm in detail, but it would be much easier to check if it were expressed as concrete Haskell code. That's what I had in mind when I proposed FixityResolution. Write a function that takes an operator-application expressed left-associatively (or right-associatively) and re-associate it according to the precedences of the operators. It's pretty straightforward to write - I have some code lying around somewhere, and GHC contains some code that does exactly that. By all means propose some code (and some QuickCheck tests!), that will certainly save us some time. Cheers, Simon
participants (2)
-
Simon Marlow
-
Twan van Laarhoven