#4180: do not consider associativity for unary minus for fixity resolution
----------------------------------+-----------------------------------------
Reporter: maeder | Owner:
Type: proposal | Status: new
Priority: normal | Milestone:
Component: Compiler | Version: 6.12.3
Keywords: fixity resolution | Difficulty:
Os: Unknown/Multiple | Testcase:
Architecture: Unknown/Multiple | Failure: None/Unknown
----------------------------------+-----------------------------------------
Comment(by isaacdupree):
The current standard+GHC behavior of unary minus in expressions has a
quite simple (albeit mind-bending) way to think about it:
Imagine putting a 0 (zero) to the left side of the minus. Then resolve
the precedence (possibly leading to an error). Then give an error if the
0 did not become the argument #1 of the now-imaginarily-binary minus.
It's mind-bending, but at least I have a mental model of it. I hope any
alternative has two properties:
a) At least as simple a mental model
b) not to *change* the association of any code that compiles both before
and after the change (because it seems so easy to accidentally introduce
bugs by getting the wrong semantics and not realizing). (Since no
treatment of unary-minus is perfect for us all, conservatively sticking to
the existing standard has value... yeah this might be controversial.)
To respond to #2 in the ticket-description, I am unsure why "- 1 ## 1" for
"infix/infixr 6 ##" should be defined to resolve to "(- 1) ## 1" rather
than "- (1 ## 1)" (nor vice versa; I'd rather have an error, and if you-
the-coder don't want one, choose a different precedence than 6 for ##).
But maybe if it fit in with a mental model...(which I was unable to get by
staring at Christian's code, and I didn't investigate further, but someone
could propose one)
--
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/4180#comment:7>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
_______________________________________________
Glasgow-haskell-bugs mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
