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

Re: RFC: Multiple-alias syntax for for

Thread Previous | Thread Next
From:
Nicholas Clark
Date:
June 9, 2021 08:53
Subject:
Re: RFC: Multiple-alias syntax for for
Message ID:
20210609085314.GU16703@etla.org
On Tue, Jun 08, 2021 at 09:55:23PM +0200, Branislav ZahradnĂ­k wrote:
> On Tue, 8 Jun 2021 at 13:21, Nicholas Clark <nick@ccl4.org> wrote:
> 
> > So, the plan for discussing the proposed RFC process was to feed an idea
> > through it, and see how we get from idea to RFC to implementation.
> > (Assuming that we don't reject the idea.)
> >
> > About two months ago Rik had mentioned to me the idea of implementing this
> > (currently illegal) syntax to iterate over hashes:
> >
> >     for my ($key, $value) (%hash) { ... }
> >
> >
> Alternative proposal (as part of more complex proposal I'm preparing, based
> on https://gist.github.com/happy-barney/d94d3a6d30b4529ab86ef5ea6c78a043)
> Just as code samples
> 
> # iterate by two elements, die odd number of numbers
> for (@list) {
>     has ($key, $value);
> }
> 
> # iterate by three elements, use default values if @list % 3 != 0
> for (@list) {
>     has $first;
>     has $second := :default => 'foo';
>     has $third := :default => 'bar';
> }
> 
> # iterate over keys only
> for (%hash) {
>     has $key := :is => HASH::key;
> }

I'm not sure what that wins over the existing

    for my $key (keys %hash) {
    }

and using your `has` approach the key/value pairing could be written as

    # iterate by two elements, die odd number of numbers
    for (%hash) {
        has ($key, $value);
    }

relying on existing list flattening.

I appreciate that this is syntax that is intended to be massively more
flexible, but it's conjectured on several things that aren't yet designed,
let alone implemented

* `has` for class attributes
* extending `has` more generally (here, for blocks)
* variable binding syntax `:=`
* some level of auto-boxing on HASHes, or a HASH namespace that behaves in
  "interesting" ways with the parser.

I think that this could make sense once Cor is in the core, but unlike the
proposal, it's not something that we could have land next week - it's part
of a much bigger (coherent) design, that isn't firm yet.


Also, this is Perl - "There's More Than One Way To Do It" is acceptable.
("But I hesitate to make ten" also applies).

The two syntaxes for the same thing can coexist in the future - one is
"easy things easy", the other enables "hard things possible".


We don't need to get into a tailspin about "which is more Pythonic".
We can have both. Having one doesn't rule out the other.

(This seems to be what happens on Stack Overflow etc as soon as it becomes
apparent that there are multiple reasonable solutions to a problem, and
hence it is axiomatic that is necessary to figure out which is unequivocally
best.)

Nicholas Clark

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