ghc misreports the error line

[George Russell]

Malcolm Wallace wrote:
[snip]
> No he isn't.  At least, I can't find anything in the Report which
> disallows literal newline characters in a string literal.
> Oh, hold on.  The production
> 
>     string -> "  { graphic_<"|`> | space | escape | gap }  "
> 
> does seem to disallow newline characters.  But it also disallows
> literal tab characters!  I submit that this is a bug in the Haskell'98
> Report, and it should really say
> 
>     string -> "  { graphic_<"|`> | whitechar | escape | gap }  "
[snip]
On the contrary I'm glad to see that the Haskell standard is so sensible.
I edit Haskell using XEmacs, and I don't want to have to do an octal
or hexadecimal dump of my source code to determine whether a string 
contains a tab, newline, return, line feed, Unicode en-space (there are 
several funny Unicode space characters available) or whatever.  If you 
want a tab (and mostly they are a total pain in the neck, if not lower 
down) you can jolly well write "\t".

It is an unfortunate fact that the layout system means that invisible
spaces of various types can transform one valid program into another
inequivalent valid program, but I see no reason to make things even worse.

Allowing newline in string literals is also a bad idea if you want any
kind of intelligent error-recovery (admittedly lacking in GHC and Hugs),
since if you miss out a " character the lexer has no way of recovering 
until it hits EOF.