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

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

Thread Previous | Thread Next
From:
Neil Bowers
Date:
June 1, 2022 09:44
Subject:
Re: Pre-RFC: syntax for quote-words-arrayref
Message ID:
beab4f58-18e3-47e8-9cd5-572c9c7727a1@Spark
Hi Garu!

> 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

A good question to ask. I mentally think of this as a single construct, but I have to use two constructs to write it. Given it’s so widely used, I think it’s worth providing its own construct.


> is code really that more clear/legible as qa[...] than it is with [ qw(...) ]?

In short, yes :-)

I remember that the first N times I saw [qw/ … /] I initially had a "huh, wtf is that?". I think it is more of an improvement for beginners and casual Perl programmers, than for heavyweights, who may still use the existing idiom even with qa[] available, due to muscle memory.


> will qa() or qa|| or qa// etc be allowed?

Yes, I think it would, but by convention I’d expect almost everyone to use qa[].

If we went the qs[] route instead, then I think the bracketing characters should be restricted.


> 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 :)

I don’t feel qualified to comment on your laziness, but (a) I’ve a friend I could ask ;-), and (b) see https://www.goodreads.com/en/book/show/54304124-laziness-does-not-exist



>> 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.

Ah. Re-reading what I wrote, maybe you thought I was saying that you should be able to quote things inside qa[]?
That’s not what I was trying to say. I meant that if you want to quote things (e.g. due to spaces), then don’t use the qa[] operator at all.

    my $ref = ["thing with spaces", qw/ one two three /];


> 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.

I think that if you don’t want interpolation, then you don’t use qs.


The benefit is not really about fewer characters, but about clarity. I would use qa[] and qs[] if we went that way. But I don’t really like

    my $href = qs{  a x  b y  c z };

because you’ve lost the visual hint of => that it’s a hash. It looks like a list. So we’d have to consider allowing => as a no-op, which also feels yucky.

qs is a lot more complex than qa to implement and maintain, and though some people seem to like the idea of interpolation and comments, I don’t see the evidence supporting it, which I do for qa. And if we add qa first, even if people love it and then say then want qs as well, already having qa reduces the value of a subsequent qs.

Neil


Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About