develooper Front page | perl.perl5.porters | Postings from May 2022

Re: Pre-RFC: syntax for quote-words-arrayref

Thread Previous | Thread Next
May 31, 2022 19:36
Re: Pre-RFC: syntax for quote-words-arrayref
Message ID:
On Tue, May 31, 2022 at 4:41 AM Neil Bowers <> wrote:

> In early March last year, I proposed[1] new syntax for "quote words
> arrayref",
> so that the following:
>     $a = [qw/ a b c /];
> could be replaced with:
>     $a = qa[ a b c ];
> (or maybe qwa[] or qaw[]). There are modules for this on CPAN - see my
> original post for references[1].
> Roughly 36% of CPAN distributions use that idiom at least once.

I like the idea of reviewing idioms and updating operators, but does the
proposed new operator add enough value to the language to be included? It
is adding 1 extra quote-like operator for a 2-character gain (only 1 if qwa
is used instead of qa) and maybe a little extra readability. On the other
hand, it's one extra operator to implement, maintain, document, and to
learn about/consider when reading and writing code. So my first questions

* is code really that more clear/legible as qa[...] than it is with [
qw(...) ]?
* will qa() or qa|| or qa// etc be allowed?

I probably have a lot of code using the [ qw( a b c ) ] idiom, but I
honestly don't see myself using qa[] just to replace that idiom. Maybe it's
one of those things you only see the value once it's there, or maybe I'm
just lazy :)


>     $a = qs[ a b c ];
>     @a = qs( a b c );
>     %h = qs( a 1 b 2 c 3 );
>     $h = qs{ a 1 b 2 c 3 };
> You wouldn't be allowed to use anything other than [], (), and {} as quote
> chars.
> We could make => a no-op, so you can at least make it look like a hash:
>     $h = qs{ a => 1 b => 2 c => 3 };
> That might cause more confusion than benefit though, so probably not.
> It would interpolate other scalars, arrays, and hashes,
> and would allow inline comments
>     $w = qs[
>                zork         # blah blah
>                xyzzy        # plugh plugh
>                $favourite
>                @defaults
>            ];
> But, you say, what if people want the literal '@defaults' in there?
> I think things that are different should look different,
> and if you want that literally, then you should see '@defaults'.

That's a lot of edge cases to consider and way too deviant from current
quote-like operators' behaviour. I think it would cause more confusion than
benefits, like people trying to do the same with qw(). Especially when you
already can achieve similar behaviour with just a few characters more.

Also, what if you don't want to interpolate? It could soon follow the need
for a qqs[] interpolating variables while a qs[] would return a literal
'$defaults'. Unless it was already implemented that way, in which case the
proper behaviour might need to be puzzled out.

> Really, I just want qa[]. I see evidence for the value of that.
> I don't see evidence for qs, but that doesn't mean that people wouldn't
> use it.

I believe qs[], as proposed, needs more work. And while the idea of qa[]
has some appeal, my feeling is that the added value would not be too high.

Considering qa[] under the lense of the "what makes a good idea" section of
the RFC proposals document:

* is it less verbose than existing syntax?

2 characters less.

* does it have fewer ways to make mistakes?

Maybe? One could argue $x = qw(a b c) or $x = \qw(a b c) are common
pitfalls and qa[] could fix them, but in practicality it may be so that
people now get confused over what quote-like operator to use, bikeshedding
over whether qa[] is more efficient than [qw()], trying to use qa[] in code
running on older perls, or trying out $x = qa(a b c) and getting errors,
then wondering why separators are interchangeable in all but qa[].

* is it more efficient internally?

Probably not? I don't see why both qa[] and [qw()] couldn't be optimized
the same way. Then again, I'm not a perl core dev and could be way off.

* opens up new ways to express problems?

Does it? I'm not so sure. But I have not looked hard enough into it.

Costs are:

* yet another way to do it - Perl becomes incrementally harder to learn,
remember and read


* existing tooling has to adapt to cope

Yup, internally and externally (new operator means updates to syntax
highlighters, linters, etc.)

* linearly more implementation to maintain

I think so.

* exponentially more combinations of features to define and debug

Maybe? Not sure.


p.s. It is a shame that a reference to a list creates a list of references
and not a reference to said list. I would love for [ (...) ] and \( ... )
to be consistent, this would make it a non-issue since developers could
just write \qw( a b c ) which I think would be clearer. Oh, well.

p.p.s: I would really enjoy a quote operator that would return a list based
on a separator, as my biggest issue with qw() is not being able to use
@x = qw( one, then two, and now three ); Maybe I'll try coming up with a
pre-rfc for that.

Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About