whitespace in strings (was "ghc misreports the error line")
George Russell
ger at tzi.de
Thu Oct 25 12:12:06 EDT 2001
Malcolm Wallace wrote, answering me:
> > 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 reveals the extent, but not the contents.
>
> > 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?
I cannot distinguish between tabs and sequences of spaces just by their
appearances. And adding vertical tabs, returns, linefeed and miscellaneous
unicode spaces would 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.
>
> It really isn't difficult to give a sensible error message when the close
> quote is missing.
It is however difficult to do error-recovery. Possible perhaps, but writing
error-correcting parsers is hard enough as it is without us making it more
difficult.
>
> 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).
I don't really find it very hard typing
> main = putStrLn
> "hello,\n\
> \world"
This style also has the advantage of preserving indentation, as well
as making it clear exactly what of the various end-of-line characters
(return, linefeed, formfeed, newline or whatever) is being printed.
>
> And note that no compiler/interpreter currently rejects a string
> containing a literal tab character.``
No Haskell compiler that I know of does error-recovery on lexing or
parsing. But they should, in my opinion.
More information about the Glasgow-haskell-bugs
mailing list