Alistair> Apologies if this has been covered already... I've searched Alistair> the haskell-prime list archive and not found anything on this. Alistair> I'd like to submit a request for a fairly trivial feature: Alistair> multi-line text literals in source, AKA here-docs. You know, Alistair> like the ruby/perl/bash < triple-quotes, or C#'s @"...". John> This would be a wonderful thing to see. The current system is John> terribly annoying in this regard. The obvious disadvantage is that it becomes easier to create runaway strings. If you do this at all, reuse the regular quotes, don't invent yet another weird and wonderful lexical syntax. Haskell is already bad enough that way, with \ used for lambda and so on. @" would be okay I guess. -- She had a passion for anyone who could do anything really well. ... "Not for an engineer, not for a technician!" Mikhail Bulgakov, The Master & Margarita

...

If you do this at all, reuse the regular quotes, don't invent yet another weird and wonderful lexical syntax. Haskell is already bad enough that way, with \ used for lambda and so on. @" would be okay I guess.

Why not just go the Python way and use """ ?

That is, three literal quotes at the beginning and end.

After all, Python has lifted quite a few things from Haskell. Time to return the favor. ;-)

I'm not fussy as to exactly what syntax is chosen, just that we get some kind of here-doc. I've been using C# quite a bit recently, so the @"..." syntax seems quite appealing. It's fairly lightweight, and @ doesn't have too many other uses in Haskell syntax, does it? (just the name@(a1:a2:_) usage springs to mind). Something else to consider: in C#, at least, the escaping rules change depending on which type of string literal you choose (single or multi-line). In multi-line (AKA verbatim) strings, escaping is switched off, so a single backslash, for example, will appear as such in the output. This obviously makes it easier to preserve a block of text verbatim if it contains backslashes and escape sequences. The exceptions are backslash-double-quote (\") and two double-quotes (""), which both result in one double-quote in the result. Alistair

On Fri, Sep 22, 2006 at 09:30:50PM -0400, Ian Zimmerman wrote:

John> Why not just go the Python way and use """ ? That is, three John> literal quotes at the beginning and end. After all, Python has John> lifted quite a few things from Haskell. Time to return the John> favor. ;-)

Because it will confuse language-agnostic tools.

I don't understand -- what language-agnostic tools would this confuse more than any other syntax?

Do you use Emacs? How does it handle the Python syntax? I am not a Python programmer, so I can't answer that myself. But I'll hazard a guess: badly.

python-mode actually handles Python syntax a lot better than haskell-mode handles Haskell syntax, particularly regarding indentation. -- John

On 22 Sep 2006 23:54:42 -0400, Ian Zimmerman wrote:

Here's a quick test: put the cursor in front of a triple-quoted string, then hit Control-Alt-F (forward-sexp). It should move just after the whole string. Does it?

Any tool which assumes strings are delimited by a single front delimiter and a single end delimiter, which they are in most reasonable languages, will have trouble.

(just speculating here...) In order to produce one double-quote inside a double-quote delimited string, many (most?) languages let you use two adjacent double quotes. So a string starting with triple double-quote would result in a string that has one double quote as its first char. I imagine that smarter language-aware editors would handle this case, otherwise they would not correctly recognise whether or not the cursor was inside a string literal. Alistair

On Fri, Sep 22, 2006 at 11:54:42PM -0400, Ian Zimmerman wrote:

John> indentation.

Automatic indentation is only one aspect of Emacs modes, and as far as I am concerned not nearly the most important one.

Here's a quick test: put the cursor in front of a triple-quoted string, then hit Control-Alt-F (forward-sexp). It should move just after the whole string. Does it?

Yes, it does. But I don't think we should be limiting our language by what Emacs does.

Any tool which assumes strings are delimited by a single front delimiter and a single end delimiter, which they are in most reasonable languages, will have trouble.

Then the tools are buggy. What sort of tools are you thinking of here?

On 2006-09-24 at 01:59BST "Neil Mitchell" wrote:

As a side note, perhaps if you're shoving massive amounts of text into a Haskell source file you want to either move to something more structured (like haskell source extensions),

IIRC the original problem was MySQL statements, which really call out for something structured. Having them as strings throws away potential compile-time checks.

or if it really is just some large constant, then put it in a separate file.

That reminds me of an idea I've had rumbling about in my head for some time: files as constants. It goes something like this: A module may import a directory (folder?) using some special syntax (or hypothetical module name), and all the files in the directory become names available to the module. In the simplest version, the files would just correspond to names of type String, but more structure would be possible (and probably desirable). So, let's suppose that the directory D contains files foo and bar, a module could say something like import ConstantFiles/D (foo) main = putStr foo and the compiler would instruct the linker that D/foo was to be included in the resulting programme (possibly at load time?) bound to the name foo. There are plenty of details to be worked out (including what mapping for filenames to variable names, encodings - which the compiler would have to check, searchpath resolution, ...), which is why I've not got round to posting this before, but I think the idea has potential. Jón -- Jón Fairbairn Jon.Fairbairn at cl.cam.ac.uk

haskell-prime-bounces@haskell.org wrote:

I would also like to see these. I like the python syntax

""" stuff... """

but really most anything will do.

the triple quote doesn't eat any usable syntax though and won't require any special cases in the parser so I would much prefer something like that.

Would someone like to make a ticket/wiki page for HereDocuments? I suggest that here documents could supplant string gaps, which are a pain both for the compiler and the user and interact badly with CPP. In fact, I suggest removing string gaps anyway, since "abc"++ "cde"++ ... is just as good as "abc\ \cde\ ... GHC optimises the first to the second anyway. I find myself using explicit ++ rather than string gaps these days, ever since the problems with recent versions of GNU CPP and string gaps arose (yes I know cpphs works with string gaps). Cheers, Simon