GHC 6.2 breaks multiline string literals

[Joachim Durchholz]

John Meacham wrote:
> 
> I have also wanted something like that on several occasions. ideally,
> I'd like something like python where.
> 
> foo = """
> hello this is
> preformatted text.
> """
> 
> will be the same as 
> foo = "hello this is\npreformatted text.\n"

I wouldn't want something like that in a language.
It's very convenient, yes, but I'm uneasy at the prospect of an editor 
cutting off trailing blanks. I shudder at the prospect of an editor 
reinterpreting leading blanks as tabs or vice versa - the text will be 
interpreted differently depending on whether it's displayed in an 
editor, on a terminal, or in the dialog box of a GUI.
This all doesn't matter much when all that one wants is a simple Usage: 
message in response to a --help option. But it would be hellishly 
difficult to make sure that every programmer understands the 
ramifications of using multiline string literals.

Personally, I'd prefer having autoconcatenated strings like this:
   multilineLiteral = "\n"
     "\tline1\n"
     "\tline2"
making all the representation decisions explicit.
To edit that thing, I'd like a macro that took the autoconcatenated 
string literal at the current cursor position, created a temporary 
buffer with the parsed string, let the user edit it, and moved the 
unparsed results of that edit back into the original source code.

Regards,
Jo