Front page | perl.perl5.porters |
Postings from May 2022
Re: Pre-RFC: syntax for quote-words-arrayref
Thread Previous
|
Thread Next
From:
Martijn Lievaart
Date:
May 31, 2022 17:08
Subject:
Re: Pre-RFC: syntax for quote-words-arrayref
Message ID:
06d8eeee-efff-6e2c-5be1-6abd7fb6a2fc@rtij.nl
Op 31-05-2022 om 09:40 schreef Neil Bowers:
> 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 ];
And I for one would LOVE this.
>
> (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.
> This seemed to be well received. Until ...
>
> Rik said why not go all-in and spec out a new swiss army chainsaw quoter,
> which can take options, so, using qz as an example:
>
> $a = qz:d[ a b c ]; # 'd' says delimiter determines type, arrayref
> $h = qz:d{ ... }; # hashref
> @a = qz:d( a b c ); # list, i.e. like qw( ... )
>
> But also:
>
> $a = qz:id[ a $b c ]; # i: interpolative
> $a = qz:dx[
> a # with a comment
> b
> c # another comment
> ];
> At least two people liked the comments and interpolation.
I like the comments and the interpolation, but not this syntax. Not at all.
>
> I find myself wishing we had qa[] on a regular basis. I've never wished
> for an equivalent for hashrefs, or for comments, or interpolation.
> The => already gives us barewords on the left;
> do people really want it for the values as well?
> Enough people?
Comments, yes. Interpolation, yes. Hashrefs, yes, but way lower priority.
>
> The motivation for qa[] is that it's easier to read, and less to type.
> The chainsaw undoes that saving, plus now we have two ways to quote
> basic word lists.
Yes. What you showed up there was horrible, AFAIC.
>
> I couldn't see myself using it, and it's more confusing looking for the
> casual reader/programmer than the syntax I was originally trying to
> improve.
> I want to make life easier for the 38% of CPAN authors, not the some
> small number of very experienced Perl programmers.
>
> So really, I just want qa[], but if I can't get that past the pesky PSC,
> then we could consider having the options of Rik's idea always turned on,
> and we name it qs, or the smart quote operator[2]?
As you say yourself below, 'smart' may not be the smartest name (pun
intended). Other than that, this looks so natural.
>
> $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.
Yeah, allowing qs() makes sense. I would use it.
>
> 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.
I find I do write literal strings on the right hand side of => quite
often. So I think it has value, although more limited than qa.
# Table to convert old labels into new labels
$conv = qs{ foo => bar, fee => baz };
>
> 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'.
Yes.
>
> 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 do. I would use comments and interpolation. And hashrefs. I would love
this feature, although we may (should?) still bikeshed over the name.
HTH,
M4
Thread Previous
|
Thread Next