The case of enumeration types will be reduced to word literals, and
#10137: Rewrite switch code generation -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 (CodeGen) | Keywords: Resolution: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #9157, #8326, | Differential Revisions: #8317, #9159 | -------------------------------------+------------------------------------- Changes (by rwbarton): * related: #9157, #8326, #8317 => #9157, #8326, #8317, #9159 Comment: Also see the comments of #9159. treated the same from now on. Note that when matching on an enumeration type, we can assume that the constructor tag is within the range of possible tag values. We cannot make any such assumption for matches on ints. So, we should remember the extra information that we have about the range when doing this reduction. I imagine you will have a function to generate code for an int pattern match with known bounds anyways, as part of a binary search algorithm, so this should not complicate the code greatly.
Matching against literals literals is fishy anyways, so my suggestion is to simply generate a linear list of equality checks here – turning the intended operation (equality test) into something else (comparisons in a if-then-else tree) feels wrong to me for floats.
I don't see anything wrong with using comparisons for pattern matching on floats as long as the patterns are all finite numbers (though there is trickiness around negative zero to be aware of). But I also think float pattern matching is much less important than your other goals, so I would agree with doing something simple for floats, at least initially. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/10137#comment:4 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler