Unexpected behaviour of operators defined in different module

[radekm]

The following code works as expected (i.e. writes helloA to the console):

module A where

import FFI
import Prelude

infixr 1 ??, >=>

(??) :: a -> (a -> b) -> b
x ?? f = f x

(>=>) :: (a -> Fay b) -> (b -> Fay c) -> a -> Fay c
f >=> g =  \x -> f x >>= g

main :: Fay ()
main = do
  "helloA" ?? return >=> putStrLn

If I move the operators to another module

module Op where

import FFI

infixr 1 ??, >=>

(??) :: a -> (a -> b) -> b
x ?? f = f x

(>=>) :: (a -> Fay b) -> (b -> Fay c) -> a -> Fay c
f >=> g =  \x -> f x >>= g

then the code

module B where

import FFI
import Prelude
import Op

main :: Fay ()
main = do
  "helloB" ?? (return >=> putStrLn)

works too. But if I remove the parentheses around return >=> putStrLn the code stops working (nothing is printed to the console):

module C where

import FFI
import Prelude
import Op

main :: Fay ()
main = do
  "helloC" ?? return >=> putStrLn

I'm using fay-0.14.2.0 and compiling by:

fay --Wall --html-wrapper A.hs
fay --Wall --html-wrapper B.hs
fay --Wall --html-wrapper C.hs

[mgsloan]

Looking at the code, I don't think that fay currently handles operator precedence outside of those defined here: http://hackage.haskell.org/packages/archive/haskell-src-exts/1.13.5/doc/html/src/Language-Haskell-Exts-Fixity.html#line-140

Haskell-src-exts does provide a function applyFixities, that allows you to apply fixities after parsing them. Thankfully, there is already a scan of the dependencies in Fay.Compiler.CollectRecords, so fixing this might not be so difficult.

[bergmark]

This is not quite that easy, we need to first parse the file that uses the imported operator, this parse might fail (src-exts just errors out) because of ambiguous fixities since they are defined in this file's import. So we would need to pre-parse imports without using src-exts and then re-parse with the appropriate fixites.

Luckily haskell-names and the GHC API does this for us so once we migrate to one of these then it will be automagically fixed.

[bergmark]

Correction: haskell-names doesn't do this.

[bergmark]

Refs haskell-suite/haskell-names#1

[bergmark]

Spring cleaning. Lack of activity, it's unlikely that this will happen. Fixity declarations are just too much work since it depends on both parsing and name resolution.