ghc misreports the error line

[Malcolm Wallace]

> 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. 

Syntax colouring, or indeed careful visual inspection, is good enough
to reveal the extent of a string literal.  I don't see why a hex dump
is required.

> 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,

Both tabs and newlines are visible to me.  Adding _any_ character,
whitespace or not, to a string literal changes a valid program to
another valid program.  I'm afraid I don't know what point you are
trying to make here.  Can you elucidate?

> 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.

It really isn't difficult to give a sensible error message when the close
quote is missing.

Personally, I quite like being able to embed newlines in string
literals because it reduces the meta-character clutter in long
sections of text (e.g. help messages).

And note that no compiler/interpreter currently rejects a string
containing a literal tab character.

Regards,
    Malcolm