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