Front page | perl.perl5.porters |
Postings from May 2022
Re: Pre-RFC: syntax for quote-words-arrayref
Thread Previous
|
Thread Next
From:
breno
Date:
May 31, 2022 19:36
Subject:
Re: Pre-RFC: syntax for quote-words-arrayref
Message ID:
CAHS-WQYy2OQ7O6XRg7-0m4_je1me+1v5iBocHyHZj4GfsAyK7g@mail.gmail.com
On Tue, May 31, 2022 at 4:41 AM Neil Bowers <neilb@neilb.org> 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
are:
* 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 :)
<snip>
>
> $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
Yup.
* 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.
Cheers!
garu
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
spaces:
@x = qw( one, then two, and now three ); Maybe I'll try coming up with a
pre-rfc for that.
Thread Previous
|
Thread Next