On Fri, Oct 5, 2012 at 8:01 AM, Lennart Augustsson wrote:

I agree that backslash string wrapping is obscure. I do use it a lot, but I would not be sad to see it go.

On Fri, Oct 5, 2012 at 9:50 AM, Henrik Nilsson wrote:

I find it quite neat, also use it a lot, and would be sad to see it go.

It is also a good feature for automatic formatting of code to a specific width.

But what about just replacing those \s with ++? It's true it's a few more characters, but is it really that much more work? I actually just used the \s recently, and being 3 characters shorter is a bit nicer, but not that much nicer. And it messed up my simplistic syntax highlighting. However, I did notice that given OverloadedStrings, '"hello " <> "there" :: Text' does not get optimized to 'Text.pack "hello there"', but for all I know the complicated thing it emits is just as efficient.

The same is true for \a, \b, \f, \v, \EM, \DC1, etc. We do need \&, though.

What is \& used for? I never knew it existed until I reread that bit of the report, and couldn't figure out what it was for. I'm assuming that only terminal manipulation stuff needs those things, and that you would generally not want to write it inline, but write something like 'ringyDingy "I'm going to nag and bell at you!"', and ringyDingy is just as happy to build the bell with Char.chr. I guess this is pretty much bike-sheddery so I'll leave it at this, but it seems like the darker corners should be subject to some spring cleaning every 10 years or so...

On Fri, Oct 5, 2012 at 3:34 PM, Evan Laforge wrote:

On Fri, Oct 5, 2012 at 8:01 AM, Lennart Augustsson wrote:

...

I agree that backslash string wrapping is obscure. I do use it a lot, but I would not be sad to see it go.

On Fri, Oct 5, 2012 at 9:50 AM, Henrik Nilsson wrote:

...

I find it quite neat, also use it a lot, and would be sad to see it go.

It is also a good feature for automatic formatting of code to a specific width.

But what about just replacing those \s with ++? It's true it's a few more characters, but is it really that much more work? I actually just used the \s recently, and being 3 characters shorter is a bit nicer, but not that much nicer. And it messed up my simplistic syntax highlighting.

However, I did notice that given OverloadedStrings, '"hello " <> "there" :: Text' does not get optimized to 'Text.pack "hello there"', but for all I know the complicated thing it emits is just as efficient.

Not every OverloadedString instance is necessarily equally efficient or even necessarily supports ++ or <> though.

The same is true for \a, \b, \f, \v, \EM, \DC1, etc.

...

We do need \&, though.

What is \& used for? I never knew it existed until I reread that bit of the report, and couldn't figure out what it was for.

It is used when splitting up some escapes to keep them from consuming the following characters.

I'm assuming that only terminal manipulation stuff needs those things, and that you would generally not want to write it inline, but write something like 'ringyDingy "I'm going to nag and bell at you!"', and ringyDingy is just as happy to build the bell with Char.chr.

Maybe I'm just showing my age here, but I'd be somewhat weirded out to see the escapes that I expect to be present in almost any language just gone and replaced with a kind of weak "but you can use a named combinator to get it if you really need it" excuse. I guess this is pretty much bike-sheddery so I'll leave it at this,

but it seems like the darker corners should be subject to some spring cleaning every 10 years or so...

I'm a pretty strong -1 on this. Do I use these features often? Not terribly. Do I particularly want to recolor this bikeshed in the name of simplicity? No. The set of string escapes is admittedly only one point in a potentially very large the design space, but I don't see much point in randomly changing it, and then forcing awkwardness on any code that is already using it, and causing more complication in compilers and libraries and a fairly arbitrary-seeming distinction between the current and previous versions of Haskell. Frankly, I think the current set of string escapes satisficeshttp://en.wikipedia.org/wiki/Satisficing and I don't really see how any other reasonable point in the design space is * enough* of an improvement to justify the infrastructure impact. Implementing the string escapes falls to a small handful of us who write compilers or tools for working with Haskell, but the proposal seems to be to just randomly discard functionality that isn't particularly hard to implement or all that exotic by comparison with other languages. -Edward