
This worked in GHC 6.0.1: multilineLiteral = " line1 line2" But doesn't work in GHC 6.2. Is this a bug or rather a bugfix? Anyway, I found it very convenient to embed verbatim string blocks this way. Is there maybe another way to achieve the same thing? Thanks in advance, -Stefan

Ferenc, thanks for your answer. It doesn't really solve my problem though... 1. Your method doesn't preserve the line-breaks within the resulting string. 2. Surrounding each line with special chars is actually what I want to avoid. What I'm looking for is something similar to Perl's << and PHP's <<< operator. -Stefan Ferenc Wagner wrote:
Stefan Reich
writes: multilineLiteral = " line1 line2"
Use string gaps (see 2.6 in the Report):
multilineLiteral = "\ \ line1\n\ \ line2"

On Sun, Dec 28, 2003 at 02:54:52AM +0100, Stefan Reich wrote:
Ferenc, thanks for your answer. It doesn't really solve my problem though...
1. Your method doesn't preserve the line-breaks within the resulting string.
2. Surrounding each line with special chars is actually what I want to avoid.
What I'm looking for is something similar to Perl's << and PHP's <<< operator.
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" -- --------------------------------------------------------------------------- John Meacham - California Institute of Technology, Alum. - john@foo.net ---------------------------------------------------------------------------

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
participants (4)
-
Ferenc Wagner
-
Joachim Durchholz
-
John Meacham
-
Stefan Reich