ghc 6.10.4 infix declarations and '\' bug or not ?
in declaring fixity for an operator (\\) to get it to compile using ghc 6.10.4, I needed to use the following code infixl 9 \\\ (\\) a b = etc ... where I assume the first \ escapes the second \, using infixl 9 \\ generates a syntax error infixl 9 \\ used to compile no problems with ghc 6.8.2 what is going on here ? why do I now need to add an additional \ ?, where is this change documented ?, is this a bug?
On Sat, 2009-08-22 at 15:52 +1000, John Lask wrote:
in declaring fixity for an operator (\\) to get it to compile using ghc 6.10.4, I needed to use the following code
infixl 9 \\\ (\\) a b = etc ...
where I assume the first \ escapes the second \, using infixl 9 \\ generates a syntax error
infixl 9 \\ used to compile no problems with ghc 6.8.2
what is going on here ?
Usually this problem is related to cpp, since \\ at the end of a line has special meaning to cpp. Are you sure that you're comparing like with like when you say it worked in ghc-6.8.2? If you're using cpp for the module now and in the past you were not then that would explain it. Another trick I've seen is: infixl 9 \\ -- this comment is here to defeat evil cpp mangling Duncan
indeed it was the cpp, and the behaviour is consistent beetween versions, I
must have introduced some changes that affected the eol marker. Thanks for
your tip.
jvl
----- Original Message -----
From: "Duncan Coutts"
On Sat, 2009-08-22 at 15:52 +1000, John Lask wrote:
in declaring fixity for an operator (\\) to get it to compile using ghc 6.10.4, I needed to use the following code
infixl 9 \\\ (\\) a b = etc ...
where I assume the first \ escapes the second \, using infixl 9 \\ generates a syntax error
infixl 9 \\ used to compile no problems with ghc 6.8.2
what is going on here ?
Usually this problem is related to cpp, since \\ at the end of a line has special meaning to cpp.
Are you sure that you're comparing like with like when you say it worked in ghc-6.8.2? If you're using cpp for the module now and in the past you were not then that would explain it.
Another trick I've seen is:
infixl 9 \\ -- this comment is here to defeat evil cpp mangling
Duncan
participants (2)
-
Duncan Coutts -
John Lask