I haven't used Perl in quite some time, and this is the sort of thing is why it ...

__david__ · on April 15, 2016

> This, on the other hand, is a 'solution' to escaping quotes that is completely mad.

Meh, Perl's solution is fine. You can throw up your hands and say it's crazy, but as a person who worked with Perl for 20 years, I've never had the problem you describe. I tend not to use the qq() or q() style quotes, but I've used s@@@ and s,,, so many times I can't count. It's really quite nice (and perfectly readable unless you do something weird like 'sxxx'.

kbenson · on April 14, 2016

> Quotes are quotes are quotes in almost every language. It's completely unambiguous

Oh, like in C and C++ where single quotes denote a char, and double quotes a string?

Or in Perl, PHP and Ruby where double quotes interpolate, and single quotes don't?

Or in JavaScript and Python, where there's no functional difference between single and double quotes?

Or C#'s string literals which only support double quotes, but you prefix the string with @ to denote it's verbatim?

Or systems that allow repeated double quotes within a double quote string literal to stand in for an escape ("foo ""bar"" baz"), as many SQL systems do?

Or what about systems that interpolate, and the differences between what they do and do not interpolate? Variables? Escape characters? Hexadecimal escapes?

You're fooling yourself if you think it unambiguous in anything except for the language you are dealing with, and if you're within that language, who cares what you use as long as it's consistent? You learn it, and then it's unambiguous (if implemented well).

This is no different than if your language supports hex numbers (usually done through prefixing it with 0x). Those are two different ways to specify the exact same thing (a binary number!). The benefit comes from using it in the circumstance where it's appropriate. That is, where it enhances readability, not where it detracts from it.

> This, on the other hand, is a 'solution' to escaping quotes that is completely mad. Using non-standard quotes, especially mixing and matching them is a disaster for readability and maintainability

Maybe you think

    "{\"foo\":\"bar\",\"baz\":\"it's that's they're we're\"}"

is fine, or you may prefer

    '{"foo":"bar","baz":"it\'s that\'s they\'re we\'re"}'

(if your language supports it).

I prefer

    q|{"foo":"bar","baz":"it's that's they're we're"}|

because I think it's clearer, and learning once that a literal q defines a new quote operator that is in effect until it's next seen is simple, easy to remember, and yields very useful readability gains.

> using a T in your string now? need to change the quotes!

I included the qTT example just to show how it worked, not to endorse its use. I thought that would have been obvious from my statement "You could simplify it by not using the matching enclosures ({ and }, [ and ], etc). It's easy to parse. and if you keep the quoting character somewhat rare, it's not hard to read."

In any case, I fail to see how how that's a problem beyond any other quote character. Including that character in your string will result in a compile time error in all but the most esoteric of cases, making it easy to find.

__david__ · on April 15, 2016

And don't forget Tcl where { and } are actually quotes.

draegtun · on April 15, 2016

And similar with Rebol / Red where you have two distinct quoting literals...

  "string with no newlines"

  {A multi-line string
  that can run over over many lines
  and {even be} nested}

For unbalanced {} string then you would need to escape it...

  {escape closing brace ^}  &  opening brace ^{ is all you need}