Front page | perl.perl5.porters |
Postings from June 2022
Re: Pre-RFC: syntax for quote-words-arrayref
Thread Previous
|
Thread Next
From:
Oodler 577 via perl5-porters
Date:
June 4, 2022 23:00
Subject:
Re: Pre-RFC: syntax for quote-words-arrayref
Message ID:
Ypvj6TnpZHxZZ5DQ@odin.sdf-eu.org
* breno <oainikusama@gmail.com> [2022-05-31 16:36:13 -0300]:
> 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?
This would be a boon for humans who use references a lot, knowing a priori
that they are indeed going to do, either:
my @x = qw[a b c];
my $x = \@x;
or
my $x = [ qw/a b c/ ];
In both cases, something like the following is desirable (for me, as someone
who does this quite a bit):
my $x = qa[a b c];
>
> 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 :)
It's not lazy, it's one of those things that offer additional idiomatic efficiencies
if one is making use of references. My tendancy is to use references as often
as possible because I know that this is how I code. Additionally, once you get past
simple hashes or arrays, *all* data structures have to use references; so you now
get to do this without additional cruft:
my $thing = {
a => qa[ b c d ],
...
};
As opposed to:
my @a = qw/b c d/;
my $thing = {
a => \@a,
...
};
So the pay off must be viewed beyond the simple hash or array.
Another example of arrays of arrays, where the issue that qa[]
solves is even more pronounced; i.e., it requires an addition
line per element in an AoAs.
my @thing2 = (
qa[ a b c],
qa[ 1 2 3],
...
);
Additionally, having something allows for interpolation of
variables would be a boon for similar reasons; but what this
ends up looking like is:
my $foo = [ qw/a b c/, $thing1, $thing2, $thing3 ];
But it'd be cool to write something like,
my $foo = qA[ a b c $thing1 $thing2 $thing3 ];
But what this is really moving towards is a declarative
way to construct an arbitrarily complex data structure.
And I guess this is how I am evaluating it, what q* type
helpers can there be to make this process as efficient as
possible? What this begins to look like to me is something
that I find most of these things tend to - specialized
operators that focus on the construction or deconstruction
of complex data types. It's the same genre of operator as
things like zip/unzip, kv, etc - basically the ability
to precisely build or "query" arbitrary data structures.
Cheers,
Brett
(no comments past here...)
>
> <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.
--
--
oodler@cpan.org
oodler577@sdf-eu.org
SDF-EU Public Access UNIX System - http://sdfeu.org
irc.perl.org #openmp #pdl #native
Thread Previous
|
Thread Next