backslashes within quotes

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

backslashes within quotes

Evan Laforge
The backslash string wrapping feature is a fairly obscure part of
haskell syntax, and some tools don't handle it properly (e.g. the
built in 'lex' function won't lex such strings properly).  It's also
not as useful as e.g. python's triple quotes, because you have to
suffix and prefix every line with a backslash.  As long as you are
have to add suffixes and prefixes (i.e. straight cut and paste no
longer works), you might as well write it out with (++).  In other
words, as long as you're applying ('\\':) . (++"\\") you might as well
apply ("++ \""++) . (++"\"").  And it seems to me that "string
literal" ++ "another string" is an easy thing for a compiler to
optimize, ghc-core says ghc unsurprisingly has no trouble with it.

So it's probably not helpful for performance.  IMO it's not very
useful for it's intended purpose (embedding multiline strings) because
of the \s everywhere.  It doesn't seem very widely used, and it adds a
little bit of a hassle to parsing.  And 'lex' doesn't support it.

Any interest in getting rid of it?


I would actually be in favor of triple quotes (yeah, I know it can be
done with quasi-quotes, but still...), but that's a different issue.

Also, it's hardly a big deal, but do we really need \a, \b, \f, and
\v?  The one time I used one (it was \v) it was a typo and I would
have preferred the parse error, instead I got weird output that I
didn't notice for a long time.  If I really want to, say, ring the
terminal bell or do a vertical tab or perhaps send a telegraph, I
would be using some library that handles terminal type stuff in a
higher level way.  Similarly, the \EM, \DC1, etc. codes are probably
not pulling their weight.  The '70s were 40 years ago!  And there's
that weird \& thing.  Surely cursor control library authors have
better ways to construct their magic codes.

_______________________________________________
Haskell-prime mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-prime
Reply | Threaded
Open this post in threaded view
|

Re: backslashes within quotes

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

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

On Tue, Oct 2, 2012 at 10:17 PM, Evan Laforge <[hidden email]> wrote:
The backslash string wrapping feature is a fairly obscure part of
haskell syntax, and some tools don't handle it properly (e.g. the
built in 'lex' function won't lex such strings properly).  It's also
not as useful as e.g. python's triple quotes, because you have to
suffix and prefix every line with a backslash.  As long as you are
have to add suffixes and prefixes (i.e. straight cut and paste no
longer works), you might as well write it out with (++).  In other
words, as long as you're applying ('\\':) . (++"\\") you might as well
apply ("++ \""++) . (++"\"").  And it seems to me that "string
literal" ++ "another string" is an easy thing for a compiler to
optimize, ghc-core says ghc unsurprisingly has no trouble with it.

So it's probably not helpful for performance.  IMO it's not very
useful for it's intended purpose (embedding multiline strings) because
of the \s everywhere.  It doesn't seem very widely used, and it adds a
little bit of a hassle to parsing.  And 'lex' doesn't support it.

Any interest in getting rid of it?


I would actually be in favor of triple quotes (yeah, I know it can be
done with quasi-quotes, but still...), but that's a different issue.

Also, it's hardly a big deal, but do we really need \a, \b, \f, and
\v?  The one time I used one (it was \v) it was a typo and I would
have preferred the parse error, instead I got weird output that I
didn't notice for a long time.  If I really want to, say, ring the
terminal bell or do a vertical tab or perhaps send a telegraph, I
would be using some library that handles terminal type stuff in a
higher level way.  Similarly, the \EM, \DC1, etc. codes are probably
not pulling their weight.  The '70s were 40 years ago!  And there's
that weird \& thing.  Surely cursor control library authors have
better ways to construct their magic codes.

_______________________________________________
Haskell-prime mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-prime


_______________________________________________
Haskell-prime mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-prime
Reply | Threaded
Open this post in threaded view
|

Re: backslashes within quotes

Evan Laforge
On Fri, Oct 5, 2012 at 8:01 AM, Lennart Augustsson
<[hidden email]> 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
<[hidden email]> 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...

_______________________________________________
Haskell-prime mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-prime
Reply | Threaded
Open this post in threaded view
|

Re: backslashes within quotes

Brandon Allbery
On Friday, 5 October 2012 at 15:34, Evan Laforge wrote:
On Fri, Oct 5, 2012 at 9:50 AM, Henrik Nilsson
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.
There's a conflict between \SOA and \SO followed by A, which is resolved by making the latter \SO\&A.

-- 
brandon s allbery kf8nh                               sine nomine associates
[hidden email]                                  [hidden email]
unix/linux, openafs, kerberos, infrastructure          http://sinenomine.net

Sent with Sparrow


_______________________________________________
Haskell-prime mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-prime
Reply | Threaded
Open this post in threaded view
|

Re: backslashes within quotes

Edward Kmett-2
In reply to this post by Evan Laforge

On Fri, Oct 5, 2012 at 3:34 PM, Evan Laforge <[hidden email]> wrote:
On Fri, Oct 5, 2012 at 8:01 AM, Lennart Augustsson
<[hidden email]> 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
<[hidden email]> 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 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

_______________________________________________
Haskell-prime mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-prime
Reply | Threaded
Open this post in threaded view
|

Re: backslashes within quotes

Evan Laforge
In reply to this post by Evan Laforge
On Fri, Oct 5, 2012 at 1:21 PM, Henrik Nilsson
<[hidden email]> wrote:
> No, it would often (or even usually) not be that much more work, but it
> is replacing a very simple and useful mechanism that has worked very
> well for two decades with something more complicated, somewhat less
> nice, breaking a not insignificant amount of code in the process, for
> not much gain as far as I can see.

Fair enough, works for me.

On Fri, Oct 5, 2012 at 1:01 PM, brandon s allbery kf8nh
<[hidden email]> wrote:
> There's a conflict between \SOA and \SO followed by A, which is resolved by
> making the latter \SO\&A.

Presumably you mean \SOH?  "\xe\x1" is unambiguous.

On Fri, Oct 5, 2012 at 1:34 PM, Edward Kmett <[hidden email]> wrote:
> 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.

Ok, good enough for me.  As I mentioned, it does cause bugs, at least
it did for me.  Admittedly only one though.

_______________________________________________
Haskell-prime mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-prime
Reply | Threaded
Open this post in threaded view
|

Re: backslashes within quotes

Doug McIlroy
In reply to this post by Evan Laforge

> "\xe\x1" is unambiguous.

There are two things wrong with this solution:

(1) It descends to another level of discourse--binary encoding of characters.

(2) It does not actually eliminate the need for \&. Consider the
string "\SOH1".  It cannot be written "\x11", or even "\x011".

Doug McIlroy

_______________________________________________
Haskell-prime mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-prime