If we're going to be "as inclusive as possible", why not allow all of
#8524: GHC is inconsistent with the Haskell Report on which Unicode characters are allowed in string and character literals -------------------------------------+------------------------------------- Reporter: oerjan | Owner: | RyanGlScott Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.6.3 (Parser) | Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D1235 -------------------------------------+------------------------------------- Comment (by oerjan): Replying to [comment:6 thomie]: these? Are there any downsides to this? Perhaps under a new flag `FullUnicodeStrings`, enabled by default and disabled in Haskell98 and Haskell2010 mode. A couple thoughts: Allowing \n in strings severely messes with layout. I've always assumed that's why it was disallowed in the first place. I suppose this also applies to the other *Separators and perhaps "\v\f\r" too (which would probably be *Separators if they weren't grandfathered as Control). And \r has the varying newline encoding issue. Unless I'm severely mistaken, Surrogate only exists because of the Unicode multiple encodings mess, and shouldn't ever really be ''used'' in UTF-8. I guess including them is fairly harmless but might trip up someone doing a bad encoding conversion. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8524#comment:7 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler