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

Re: RFC: Multiple-alias syntax for for

Thread Previous | Thread Next
From:
Dan Book
Date:
June 10, 2021 08:25
Subject:
Re: RFC: Multiple-alias syntax for for
Message ID:
CABMkAVXSujrWp96Q8gx6cT5M-=NOnySYYWYxh9m73djP0-dYqw@mail.gmail.com
On Thu, Jun 10, 2021 at 3:28 AM Nicholas Clark <nick@ccl4.org> wrote:

>
> I admit some guilt and inconsistency here - *I* preferred using `for` in
> the code examples because it's 4 characters shorter.
>
> *but* I realised that that makes the title `Multiple-alias syntax for for`
> which is daft. So I changed *that* to `foreach`. And now it's inconsistent.
> Bad programmer, no cookie.
>
> I don't know what is best.
>

My preference is to refer to the syntax construct descriptively as
"foreach", since although it is an exact synonym in the grammar, the
C-style for loop is never referred to as a "foreach". Separately from what
any person may decide to write in the actual code.


> > for my ($a, $b, $c) (@array) { … } # int($#array / 3) + ($#array % 3)
> > iterations?
>
> This is a question that has to be decided...
>
> What happens here if the list count isn't an integer multiple of 3?
>
> To me, the most obvious answer was substitute undef if it's not
> (ie don't die, and don't ignore what would be incomplete 'tuples' at the
> end)
>
> So if the list has 10 elements, it iterates as
>
>     One     Two     Three
>     Four    Five    Six
>     Seven   Eight   Nine
>     Ten     undef   undef
>
> and with 11, that last iteration is
>
>     Ten     Eleven  undef
>

This was my assumption as well and seems the most reasonable thing to do.
It's consistent with regular list assignment.


> > for my ($a, $b, undef) ((1,2,3)) { … } # one iteration or syntax error--
>
> Right. This is the interesting question...
>
> I'm suggesting syntax error.
>
> I think the slightly better question would be express it as
>
>     for my ($a, undef, $c) (1 .. 9) { ... }
>
>
> It's a reasonable generalisation of list assignment, where you can assign
> to
> undef to mean "ignore this value". I can see that this *might* be useful.
> It's also safe syntax to implement (although I didn't try, and I'm not sure
> how hard it would be).
>
> I'd like to stick to forbidding this, because it makes the implementation
> harder.
>

I also see how it could be useful, but on the other hand it is exactly the
same in practice as my ($x, $y, $z) but with some (imagined or real)
microoptimization of not aliasing the second value/using up that variable
name. I don't think it's useful enough to outweigh complication to the
implementation.

-Dan

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