infixr and infixl not respected

[Munksgaard]

Using infixr and infixl for a given operator should result in different parse-trees.

For example, parsing infixl 7 +>; a +> c +> d and infixr 7 +>; a +> c +> d results in the same parse tree, but really we would expect the +> operator to be right-associative in the second example.

For completeness, I've included the output of tree-sitter parse with those inputs below.

Now, I don't even know if it is possible to amend this issue while using tree-sitter, or if you want to, so feel free to close this issue at your convenience.

$ tree-sitter parse <(echo 'infixl 7 +>; a +> c +> d')
(haskell [0, 0] - [1, 0]
  (fixity [0, 0] - [0, 11]
    (integer [0, 7] - [0, 8])
    (varop [0, 9] - [0, 11]
      (operator [0, 9] - [0, 11])))
  (top_splice [0, 13] - [0, 24]
    (exp_infix [0, 13] - [0, 24]
      (exp_infix [0, 13] - [0, 19]
        (exp_name [0, 13] - [0, 14]
          (variable [0, 13] - [0, 14]))
        (operator [0, 15] - [0, 17])
        (exp_name [0, 18] - [0, 19]
          (variable [0, 18] - [0, 19])))
      (operator [0, 20] - [0, 22])
      (exp_name [0, 23] - [0, 24]
        (variable [0, 23] - [0, 24])))))

$ tree-sitter parse <(echo 'infixr 7 +>; a +> c +> d')
(haskell [0, 0] - [1, 0]
  (fixity [0, 0] - [0, 11]
    (integer [0, 7] - [0, 8])
    (varop [0, 9] - [0, 11]
      (operator [0, 9] - [0, 11])))
  (top_splice [0, 13] - [0, 24]
    (exp_infix [0, 13] - [0, 24]
      (exp_infix [0, 13] - [0, 19]
        (exp_name [0, 13] - [0, 14]
          (variable [0, 13] - [0, 14]))
        (operator [0, 15] - [0, 17])
        (exp_name [0, 18] - [0, 19]
          (variable [0, 18] - [0, 19])))
      (operator [0, 20] - [0, 22])
      (exp_name [0, 23] - [0, 24]
        (variable [0, 23] - [0, 24])))))

[tek]

I think it isn't possible at all, but even if it were, it would require substantial changes and work only for the edge case of the fixity being defined in the same module as its usage, if that usage is after the definition. so quite unlikely to be feasible 🙂

[Munksgaard]

Yeah, that's what I expected. I was just curious whether you thought it was possible at all, since the same problem exists for the hypothetical SML tree-sitter I haven't written yet :)

…

On Wed, 13 Apr 2022, at 21:09, Torsten Schmits wrote: I think it isn't possible at all, but even if it were, it would require substantial changes and work only for the edge case of the fixity being defined in the same module as its usage, if that usage is after the definition. so quite unlikely to be feasible 🙂 — Reply to this email directly, view it on GitHub <#77 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AABYJVOO7RCBGTV2BZN5W73VE4LWPANCNFSM5TLC5YDA>. You are receiving this because you authored the thread.Message ID: ***@***.***>

[tek]

heh. a similar problem occurs with #if/#else cpp macros – we can't easily pass around state except to descendants. fixity would be a little simpler, but still very limited.

[Munksgaard]

All good. I'll close this issue as "wontfix".