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 10, 2021 08:07
Subject:
Re: RFC: Multiple-alias syntax for for
Message ID:
20210610080648.GX16703@etla.org
On Thu, Jun 10, 2021 at 07:28:16AM +0000, Nicholas Clark wrote:
> On Thu, Jun 10, 2021 at 01:43:43AM +0200, Nicolas Mendoza wrote:

> > I'm sorry if this is the wrong place to comment, but I see several comments
> > about the proposition itself, so here goes:
> 
> No, this is totally the right place to comment.

And after a coffee, I realise that this is how I think the RFC process
should work. In that

1) this discussion should be summarised in the RFC itself
2) the Author should do this

So as (ghost author) for this RFC, I pushed the appended commit.

Nicholas Clark

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

commit 50e30612a2fc96a2d20b050ab450cc5bfc98c429 (HEAD -> master)
Author: Nicholas Clark <nick@ccl4.org>
Date:   Thu Jun 10 09:57:35 2021 +0200

    Record why permitting `undef` in the list of scalars is a rejected idea.

    Also record explicitly why permitting hashes and arrays isn't worth it.

    This explanation prompted by Nicolas Mendoza asking useful questions.

diff --git a/rfcs/rfc0001.md b/rfcs/rfc0001.md
index f2c812f..b93b17e 100644
--- a/rfcs/rfc0001.md
+++ b/rfcs/rfc0001.md
@@ -52,7 +52,7 @@ The proposed syntax solves all of these.

 ## Examples

-*FIXME* - are there useful examples that aren't in the Motivation/
+*FIXME* - are there useful examples that aren't in the Motivation?

 ## Prototype Implementation

@@ -60,6 +60,28 @@ The proposed syntax solves all of these.

 ## Rejected Ideas

+### Permit `undef` in the list of scalars
+
+    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).
+
+But it adds considerable runtime complexity. The easiest implementation is if there are exactly *n* scalars, all declared in the `for` loop itself, because this way they occupy adjacent Pad slots. This means that there is only one extra integer to store in the optree, which used both to calculate the *n*-at-a-time **and** the addresses of the target variables.
+
+Adding `undef` to the mix rules out a simple, clear implementation.
+
+### Permit @array or %hash in the list of lexicals
+
+    for my ($key, $value, %rest) (%hash) { ... }
+    for my ($first, $second, @rest) (@array) {... }
+
+Syntactically these all "work", and don't violate the assumption that all lexicals are in adjacent Pad slots. But it would add complexity to the runtime. Generalising *1 scalar at a time* to *n at a time* is mostly just adding a C `for` loop around some existing (known working) code.
+
+Implementing these would mean adding code for what is basically a funky way of writing
+
+    { my ($key, $value, %rest) = %hash; ... }
+    { my ($first, $second, @rest) = @array; ... }
+
 ## Open Issues



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