Hacker News Reader

Comment by kbenson | Hacker News Reader

If only more languages supported quote operators like Perl. They really do make certain things like this so much easier.

Non interpolating quotes:

  q/I wasn't surprised when he said "boo" and game me $5/;
  q@I wasn't surprised when he said "boo" and game me $5@;
  q!I wasn't surprised when he said "boo" and game me $5!;
  q(I wasn't surprised when he said "boo" and game me $5);
  q[I wasn't surprised when he said "boo" and game me $5];

Interpolating quotes:

  qq/Hello, $name!/;
  qq!Hello, $name\!!;
  qq@Hello, $name!@;
  qq(Hello, $name!);
  qq[Hello, $name!];
  qq'Hello, $name!';

Rule of thumb, single q for single quote string (non-interpolating normally), and two q's for a double quote string (normally interpolates).

View on HN

Lifted directly from sed, one of Perl's inspirations:

  s/replace #/with $/
  s#replace /#with _#

I think it was in ed already. The POSIX ed spec says: "Any character other than <space> or <newline> can be used instead of a slash to delimit the RE and the replacement."

and, AFAIR, in perl space and enter could be delimiters too! I think I've used it in some perlgolf task which didn't count whitespace.

and memory tricked me. Whitespace doesn't work for regex and quoting terminators.

Works in Ruby:

  irb(main):001:1/ puts(%r
  irb(main):002:1* a+
  irb(main):003:0> .match? %q aaa )
  true

Raw string literals in C++ allow this as well:

  R"/(I wasn't surprised when he said "boo" and game me $5)/"
  R"@(I wasn't surprised when he said "boo" and game me $5)@"
  R"|(I wasn't surprised when he said "boo" and game me $5)|"

https://en.cppreference.com/w/cpp/language/string_literal

I also like how Raku has extended this with the Q operator, allowing one to specify what should be interpolated (scalars, escape sequences, closures, etc) also with arbitrary delimiters --

   Q/I got $5 \sigh /   # literal
   Q:s/Hello $name/     # just scalars
   Q:b/hello world\n/   # just backslash escape sequences

https://docs.raku.org/syntax/Q

That may be a good candidate of something to port back when Perl 7 gets to the stage of adding new features.

It does look nice, and I kind of miss the feature in other programming languages. I also maintained cperl-mode for many years, and honestly the editor support for this functionality never quite worked right. It is hard to parse, and even harder when you are doing a heuristic-based incremental parse. (The challenge with text editors is that you have to provide correct syntax highlighting even when the document contains parse errors that the compiler would have bailed out on.)

Because editor tooling is important to me, I'm willing to see an ugly "\"quoted\" string" from time to time, if it means that I get better tools as a result.

I do generally prefer Perl's q and qq, though Python's triple-quote and its raw form are often good enough. Python also inherited C's (mis-)feature of concatenating consecutive string literals automatically, which comes in handy in some cases.

D does: https://dlang.org/spec/lex.html#delimited_strings

Rust does too, to some degree: https://github.com/rust-lang/rust/pull/9674

Unfortunately D doesn't allow substitutions like Perl.

I'm not sure if Ruby borrowed the full range of q and qq operators, but it offers Percent strings: https://ruby-doc.org/core-2.7.1/doc/syntax/literals_rdoc.htm...

This is just string interpolation.

%q allows different delimiters to represent single quoted strings, which doesn't have string interpolation. For ex:

    $ ruby -e 'a=5; puts "[#{a}]"'
    [5]
    $ ruby -e 'a=5; puts %q/[#{a}]/'
    [#{a}]

%Q or just % does interpolation:

    $ ruby -e 'a=5; puts %Q/[#{a}]/'
    [5]
    $ ruby -e 'a=5; puts %/[#{a}]/'
    [5]

%q/ruby/

%q@is@

%q!strongly!

%q(inspired)

%q[by]

%q<perl>

%Q~#{"interpolating quotes"}~

%&non interpolating by default&

q and qq are fantastic.

And qw too:

    # ['this', 'is', 'a', 'list']
    qw/this is a list/;

... but boy am I glad I don’t have to read stuff like that.

  ['but', 'boy', 'am', 'I', 'glad', 'I', 'don\'t', 'have', 'to', 'read', 'stuff', 'like', 'that']

  qw/but boy am I glad I don’t have to read stuff like that/

But why?

Or as it is written in mostly any other language:

    split("but boy am I glad I don't have to read stuff like that")

But I guess you saved three bytes, so that's nice.

Split works at run time, while qw// is just shorthand for array initialization syntax, so it works at compile time.

If splitting a string is an important optimization point in your program, neither language is a good choice.

You fail to explain why other languages do not grow these vestiges. I can only assume the implicit explanation is that you believe them to be incompetently designed, whereas I believe the exact complement: it looks like a good idea, but it isn’t.

Such things are called "syntactic sugar". They are common in other languages. Quote: «A construct in a language is called "syntactic sugar" if it can be removed from the language without any effect on what the language can do: functionality and expressive power will remain the same.»[0]

Another quote: «Data types with core syntactic support are said to be "sugared types." Common examples include quote-delimited strings, curly braces for object and record types, and square brackets for Arrays.»

[0]: https://en.wikipedia.org/wiki/Syntactic_sugar

There are many good ideas that aren't in one programming language or another.

Does that actually mean they are bad ideas? No. It only means that particular language didn't copy that particular idea.

There may be bad ideas that are in many languages, that doesn't somehow make them good.

---

Quote-words are used regularly in Perl because they are clear and useful.

    for (qw' alpha beta charlie ') {
      say
    }
    for (split '', 'alpha beta charlie') {
      say
    }
    for ( 'alpha', 'beta', 'charlie' ) {
      say
    }

The `qw` emphasizes that we are dealing with `alpha`, `beta`, and 'charlie`. The other ones have extra noise that is only there to satisfy the compiler.

Now imagine you have to add `delta` to the list.

With the `qw` you only have to press the spacebar and the letters `d e l t a`. You don't have to worry if you accidently left off a `'`, because you didn't need to add one.

To be fair, the `split` would have the same benefit. But it is still more error-prone. For example I wonder how many people didn't notice that the first argument to `split` was an empty string when it should have been a string with one space in it.

I didn't even notice it, and I've been programming in Perl for decades.

Split works at run time, but it could, in principle, evaluate at compile time when it has a constant argument.

For example, the ord() Perl function is evaluated at compile time if the argument is a constant string.

(It's not worth it because split() syntax isn't as clean as qw() for this purpose. split's first arg, if present, is the pattern to split on.)

Wouldn't that fall over for common usages of the shell (presuming it acts like sed)?

Suppose you have an executable "queue".

you'd generally run it as

  ./queue

With this rule, wouldn't that be parsed as

  ./q'e'e

?

It's the idea, rather than the implementation, which I'm advocating for. For a shell, it would likely be best to trigger with a reserved character (or two) that's much less likely to be encountered in normal usage.

Understood.

Finding a reserved character (or even sequence) that doesn't have collisions or unintended behavior beyond what the semi-reserved ' and " can do will be hard (but not necessarily impossible :)! ).

In addition to what kbenson said, word characters [a-zA-Z0-9] usually aren't eligible as quotes anyway, otherwise how would qq'this has a q in it' parse (versus q/'this has a /).

Powershell has "here-strings". For example:

    @"
    For help, type "get-help"
    "@

https://docs.microsoft.com/en-us/powershell/module/microsoft...

BASH too. Example:

SILLY_VAR="

My silly username is "$USER"

echo ${SILLY_VAR}

Reply on news.ycombinator.com