Ross points out that this is really hard to parse: | case x of y | ($ True) $ \ z -> z :: Bool -> Bool -> y
because the parser doesn't know when to stop eating the type and treat the arrow as the case-alternative arrow. Carl reminds us that this is hard to parse too: | do a == b == c because the layout processor is meant to insert a close curly where there would be a syntax error, and that depends on the non-associativity of (==). In both cases, the specification is unambiguous, but asks too much of the parser. But in neither case can I see a cure that is better than the disease. Remember, large-scale fixes are out of court. So in both cases I propose to say something like: here is an example that is hard to implement; wise programers will avoid code like this That is, point out the trap, and acknowledge that few impls will respect the letter of the law. This seems honest, and better than inventing some elaborate cure. Simon _______________________________________________ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell