backslashes within quotes

[Edward Kmett]

On Fri, Oct 5, 2012 at 3:34 PM, Evan Laforge <qdunkan at gmail.com> wrote:

> On Fri, Oct 5, 2012 at 8:01 AM, Lennart Augustsson
> <lennart at augustsson.net> 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
> <Henrik.Nilsson at nottingham.ac.uk> 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
satisfices<http://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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-prime/attachments/20121005/96ff72d7/attachment.htm>