Front page | perl.perl5.porters |
Postings from March 2021
Re: Perl feature wish: quote-word array-ref operator
March 7, 2021 08:16
Re: Perl feature wish: quote-word array-ref operator
Message ID: 20210307081618.GO285759@stripey.com
Felipe Gasper writes:
> > On Mar 6, 2021, at 6:38 PM, Neil Bowers via perl5-porters
> > <email@example.com> wrote:
> > 3. hopefully improve readability / maintainability, and at least not
> > reduce those
> It’s hard to gauge this, of course, because concision here--which is a
> win--comes at the cost of adding vocabulary to the language, which is
> a loss. It seems relatively esoteric syntax at that, ...
Maybe esoteric, but Neil pointed out the combination of the two
operators together is used in 36% of Cpan modules. That's pretty common.
I'd put qa in a similar category to say:
• It combines two common things which are often used together (print
with "\n", and [...] with qw) into one, making them cleaner to read.
And also mentally combines them: the idea of emitting an entire line
of output is sufficiently atomic that it isn't necessary every time
one encounters say to mentally decompose it into print with "\n" at
the end to grok what it's doing. I think the same would be true for
qa: we can consider it as constructing an array-ref from its contents,
without needing to think about the operators it's replacing.
• In the big scheme of things, it's a relatively minor enhancement.
Given its behaviour is already possible with older Perls, it probably
isn't worth upgrading just to get this new feature. And for the first
few years of its life, it would be irritating to use it in a Cpan
module, forcing users to a high minimum version of Perl.
(To make a different comparison, I can remember in 2001 being
frustrated by the odd Cpan module that used the new-fangled Perl 5.6
use warnings and our, instead of -w and use vars, which worked fine on
the Perl 5.005 we were using on Debian stable.)
• Over time, that aversion dissipates. When v5.10 was new, using say
makes your code require the latest Perl. But by the time, for
instance, v5.16 is current, requiring a minimum of v5.10 is much more
reasonable. By now it's completely uncontroversial to have versions
much greater than v5.10 as a minimum.
(And 20 years on, I've been happily using both use warnings and our
for longer than I can remember.)
• Typing use feature qw<foo> takes more keystrokes than is saved by just
a couple of uses of the shorter construct, making it seem less of an
advantage in shorter scripts, and of questionable worth introducing.
But they can be used in one-liners with -E, where saving keystrokes is
And if you're already requiring, for instance, Perl v5.14 for other
reasons, then obviously you get say included anyway. If you start your
file with use v5.14, that's similar (actually slightly less) typing
than use strict (which it includes) and gives you say as part of that.
At which point there's no reason not to use say and benefit from
So while it probably isn't worth upgrading just to get qa, and it'd be
hassle to enable the feature explicitly, within a few years there
comes a point when the feature is widely available and will be enabled
automatically with a minimum version requirement — and it can then be
used freely, making code just that little bit cleaner.
> ... expanding on an area of Perl--the q* operators--that I think trips
> up a lot of newcomers.
I agree that when I was new to Perl — and still trying to write Perl
like I would've done whichever language I was coming from — qw was one
of the things I struggled with. It didn't look *right* without commas,
and possibly quote marks.
But clearly at some point I grew to like it.
And I don't think adding qa makes that worse. The concept of qw/qa was a
hurdle for me, but having got past that, the fact it has both (...) and
[...] variants isn't a big extra step.
Being a named operator, it's at least readily searchable in the
documentation, which isn't the case for all of Perl's idiosyncrasies.
And both being spelt with only letters yet not being a dictionary word
should make web searches for “Perl qa” reasonable.
And of course newcomers are welcome not to use it.
> In all of your examples I see you using square brackets. What if
> someone uses parens, braces, fore-slashes, etc.?
That's up to authors to write code in a way that seems reasonable to
them. Personally I always use angled brackets in qw<...>: because they
are the type of bracket that features the least anyway, so visually it's
more distinct from other constructs (and, initially, also because it's
the most similar to what was Perl 6's <...> construct, so making
‘upgrading’ from v5 to v6 slightly smoother).
Given what qa and [...] each do, square brackets seem a most reasonable
choice to use with the qa operator. But there may be reasons for making
other choices, some of which may make code less readable; that's down to
> 1) Will someone intuit what `return qa( foo bar )` does?
If you mean somebody who's already aware of the qa operator
instinctively spotting at a glance that that function returns a
reference rather than a list, maybe not. Parens seem like they could be
the most misleading delimiter for qa — but I think the inconsistency
from explicitly banning them would be worse.
And currently to me, the qa there really stands out (from its
unfamiliarity), so I probably would notice what's going on.
> 2) Will someone intuit that `qa( foo bar )` is closer to qw than to q
> or qq?
If you mean somebody who's never encountered the qa operator before
guessing its use, again perhaps not.
But again, I wouldn't _a priori _ have been able to say what the
difference between print and say is — or which way round they would be.
At least with qa, the a is mnemonic, so once knowing about the operator,
it's easy enough to remember.
And actually, maybe some would work it out. Look at some of the places
where [qw/.../] is used: in many of those, it's clear from the context
of the surrounding code that the value is a reference to an array —
being iterated over, or being one of multiple arrays passed by reference
to a function.
It isn't necessary that every Perl feature be one that a non-Perl-
programmer could guess precisely what it does without any documentation.
We have qw; qa would be a handy variant, with a similar level of
(non-)intuition, thereby keeping the overall intuitiveness level about
the same for newcomers — while qa itself being exceedingly intuitive to
Perl programmers who already know qw.