Mailing List Archive

Perhaps the star is excess boilerplate when we can get the same syntax
error without it?

my @a = (1..10);
> my %h = (1..10);
>
> my $b = @a[]; # syntax error near "[]"
> my $c = %a[]; # syntax error near "[]"
> my $e = @h{}; # syntax error near "{}"
> my $f = %h{}; # syntax error near "{}"
>
> my $B = @a[*]; # syntax error near "[]"
> my $C = %a[*]; # syntax error near "[]"
> my $E = @h{*}; # syntax error near "{}"
> my $F = %h{*}; # syntax error near "{}"
>

On Sun, Jun 20, 2021 at 2:54 AM Ricardo Signes <perl.p5p@rjbs.manxome.org>
wrote:

> Porters,
>
> I feel confident that this should be an RFC, but our process says "post to
> p5p before writing up an RFC," and "write something less format" sounds
> great. So:
>
> I would like to propose a new piece of syntax. It's not my own original
> idea, it's come from a few places and individuals independently, but I'm
> the one who's ready to go to bat for it here. It is the *everything
> slice*.
>
> An everything slice is a slice that includes every element in an
> aggregate. We can hash out syntax, but let's start by saying "it's a slice
> where the subscript is replaced by a literal asterisk."
>
> So:
>
> @array[*]; # equivalent to @array[ 0 .. $#array ];
> %array[*]; # equivalent to %array[ 0 .. $#array ];
>
> @hash{*}; # equivalent to @hash{ keys %hash };
> %hash{*}; # equivalent to %hash{ keys %hash };
>
>
> No, this is *not* the same as writing @array or %hash. For one thing,
> when the \ operator is applied to a slice, it produces a list of references
> to individual elements, not a reference to the container. Similarly,
>
> This provides an easy way to get all the keys and values of an array,
> which pairs nicely with multi-target for:
>
> for my ($i, $v) (@array[*]) {
> ...
> }
>
>
> You can get a reverse lookup for arrays:
>
> my %index_for = reverse %array[*];
>
>
> You can assign a large list to an array without growing it:
>
> @array = (1 .. 10);
> @array[*] = @hundred_items; # @array remains 10 long
>
>
> So: if this is going to get shot down before it gets to an RFC, now's the
> time, but honestly I think you'll probably get to see me write an RFC for
> this within a week.
>
> --
> rjbs
>

??????? Original Message ???????
On Saturday, June 19th, 2021 at 8:53 PM, Ricardo Signes <perl.p5p@rjbs.manxome.org> wrote:

> Porters,
>
> I feel confident that this should be an RFC, but our process says "post to p5p before writing up an RFC," and "write something less format" sounds great. So:
>
> I would like to propose a new piece of syntax. It's not my own original idea, it's come from a few places and individuals independently, but I'm the one who's ready to go to bat for it here. It is the everything slice.
>
> An everything slice is a slice that includes every element in an aggregate. We can hash out syntax, but let's start by saying "it's a slice where the subscript is replaced by a literal asterisk."

This is my only comment, though I tried to carefully read your proposal. In principle I personally like it, but don't use slices as often as I probably should.

I am detecting some conflcit here with slice (every "even" indexed element") and "every" element. Is it correct to say that '*' below means every "tuple" (pair)?

For example, I can do:
my %hash = (qw/one 1 two 2 three 3);

And similarly, the following 2 are equivalent:

my @array1 = %hash;
my @array2 = (qw/one 1 two 2 three 3/);

Am I reading this right that, the '*' notation is actually sending a tuple of each $key/$val pair? If this is the case, my only suggestion is that there be some other semantic hint other than the "{}" that this is doing the "slice" (or "pair-wise") thing. It does seem a lot more clear when keys are explicitly written as the "slice". With this in mind "slice notation" is a thing and it might behoove us to investigate this a bit futher. But I do personally like the idea of indicating via "{}" to 'send all pairs".

And FWIW, bash associative arrays us "@". Which would probably be confusing for us. E.g.,

#!bash
for i in "${!array[@]}"
do
echo "key : $i" echo "value: ${array[$i]}"
done

I do particularly like this general idea expressed below as,

@array[*] = @hundred_items; # @array remains 10 long

But I feel like going back and looking at well developed "slice notation" is likely in order. Even if it's to take a look at PDL, which surely has crossed this bridge.

Cheers,
Brett

> So:
>
> @array[*]; # equivalent to @array[ 0 .. $#array ];
> %array[*]; # equivalent to %array[ 0 .. $#array ];
>
> @hash{*}; # equivalent to @hash{ keys %hash };
> %hash{*}; # equivalent to %hash{ keys %hash };
>
> No, this is not the same as writing @array or %hash. For one thing, when the \ operator is applied to a slice, it produces a list of references to individual elements, not a reference to the container. Similarly,
>
> This provides an easy way to get all the keys and values of an array, which pairs nicely with multi-target for:
>
> for my ($i, $v) (@array[*]) {
> ...
> }
>
> You can get a reverse lookup for arrays:
>
> my %index_for = reverse %array[*];
>
> You can assign a large list to an array without growing it:
>
> @array = (1 .. 10);
> @array[*] = @hundred_items; # @array remains 10 long
>
> So: if this is going to get shot down before it gets to an RFC, now's the time, but honestly I think you'll probably get to see me write an RFC for this within a week.
>
> --
> rjbs

??????? Original Message ???????
On Saturday, June 19th, 2021 at 9:20 PM, Philip R Brenan <philiprbrenan@gmail.com> wrote:

> Perhaps the star is excess boilerplate when we can get the same syntax error without it?
>
>> my @a = (1..10);
>> my %h = (1..10);
>>
>> my $b = @a[]; # syntax error near "[]"
>> my $c = %a[]; # syntax error near "[]"
>> my $e = @h{}; # syntax error near "{}"
>> my $f = %h{}; # syntax error near "{}"
>>
>> my $B = @a[*]; # syntax error near "[]"
>> my $C = %a[*]; # syntax error near "[]"
>> my $E = @h{*}; # syntax error near "{}"
>> my $F = %h{*}; # syntax error near "{}"

I was sort of thinking the same thing after I sent my first reply. It also seems to avoid the problem of getting painted into a corner. This might be a good first pass until a more comprehensive slice notation could be developed.

Cheers,
Brett

> On Sun, Jun 20, 2021 at 2:54 AM Ricardo Signes <perl.p5p@rjbs.manxome.org> wrote:
>
>> Porters,
>>
>> I feel confident that this should be an RFC, but our process says "post to p5p before writing up an RFC," and "write something less format" sounds great. So:
>>
>> I would like to propose a new piece of syntax. It's not my own original idea, it's come from a few places and individuals independently, but I'm the one who's ready to go to bat for it here. It is the everything slice.
>>
>> An everything slice is a slice that includes every element in an aggregate. We can hash out syntax, but let's start by saying "it's a slice where the subscript is replaced by a literal asterisk."
>>
>> So:
>>
>> @array[*]; # equivalent to @array[ 0 .. $#array ];
>> %array[*]; # equivalent to %array[ 0 .. $#array ];
>>
>> @hash{*}; # equivalent to @hash{ keys %hash };
>> %hash{*}; # equivalent to %hash{ keys %hash };
>>
>> No, this is not the same as writing @array or %hash. For one thing, when the \ operator is applied to a slice, it produces a list of references to individual elements, not a reference to the container. Similarly,
>>
>> This provides an easy way to get all the keys and values of an array, which pairs nicely with multi-target for:
>>
>> for my ($i, $v) (@array[*]) {
>> ...
>> }
>>
>> You can get a reverse lookup for arrays:
>>
>> my %index_for = reverse %array[*];
>>
>> You can assign a large list to an array without growing it:
>>
>> @array = (1 .. 10);
>> @array[*] = @hundred_items; # @array remains 10 long
>>
>> So: if this is going to get shot down before it gets to an RFC, now's the time, but honestly I think you'll probably get to see me write an RFC for this within a week.
>>
>> --
>> rjbs

On Sat, Jun 19, 2021, at 10:31 PM, oodler@cpan.org <mailto:oodler%40cpan.org> wrote:
> I am detecting some conflcit here with slice (every "even" indexed element") and "every" element. Is it correct to say that '*' below means every "tuple" (pair)?

I'm sorry, but I just don't understand any part of your reply.

The asterisk here is standing in for all valid keys. Given the variables %X or @X, subscripting with an asterisk is equivalent to subscripting with "keys %X" or "keys @X".

--
rjbs

On Sun, Jun 20, 2021 at 3:54 AM Ricardo Signes <perl.p5p@rjbs.manxome.org>
wrote:

> …
> This provides an easy way to get all the keys and values of an array,
> which pairs nicely with multi-target for:
>
> for my ($i, $v) (@array[*]) {
> ...
> }
>
>
Typo: s/@array/%array/

… right? (I'm not used to i/v array slice syntax yet, but if that's not
the intent, I'm missing something here.)


On the bikeshedding, I was also thinking of @array[], though that makes
me think of Raku's Zen slices:
https://docs.raku.org/language/subscripts#Zen_slices

So … are there any traps in confusing everything-slices with Zen slices?

Alterntively, are there traps in confusing everything-slices with Raku's
Whatever-slicing (which gets the star)?


Eirik

On Sat, 19 Jun 2021 21:53:27 -0400
"Ricardo Signes" <perl.p5p@rjbs.manxome.org> wrote:

> No, this is *not* the same as writing @array or %hash. For one
> thing, when the \ operator is applied to a slice, it produces a list
> of references to individual elements, not a reference to the
> container. Similarly,

As does \(@arr)

eval: my @arr = (4,5,6); my @refs = \(@arr); [ @refs ]
[ \'4', \'5', \'6' ]

(the final [] there just to make it print in "list context")

> @array[*]; # equivalent to @array[ 0 .. $#array ];
> @hash{*}; # equivalent to @hash{ keys %hash };

These two seem borderline unnecessary - as rvalues they are just @array
and %hash. You do point out the way that assigning into @array[*] as an
lvalue won't grow the array - I guess for that usecase it could be
interesting.

> %hash{*}; # equivalent to %hash{ keys %hash };

Isn't this values %hash ?

> %array[*]; # equivalent to %array[ 0 .. $#array ];

This one is the only one I can see that appears to add a
sufficiently-useful ability to justify the syntax. It has a certain
neatness if you consider adding the others.

Can we further imagine that these would also be allowed on refs via
arrows?

foreach my ($idx, $val) ( $aref->%[*] ) {
...
}

That's a 6-symbol punctuation operator.

I remain unconvinced.

Overall, I still feel that it will stomp on less future syntax and be
"friendlier" if we spelled this "enum" or "enumerate" or somesuch
keyword, instead:

foreach my ($idx, $val) ( enum @array ) { ... }

foreach my ($idx, $val) ( enum $aref->@* ) { ... }

Perl already has a reputation for being dense punctuation soup - can we
not make it worse?

--
Paul "LeoNerd" Evans

leonerd@leonerd.org.uk | https://metacpan.org/author/PEVANS
http://www.leonerd.org.uk/ | https://www.tindie.com/stores/leonerd/

On Sat, Jun 19, 2021, at 10:59 PM, Eirik Berg Hanssen wrote:
> On Sun, Jun 20, 2021 at 3:54 AM Ricardo Signes <perl.p5p@rjbs.manxome.org> wrote:
>> This provides an easy way to get all the keys and values of an array, which pairs nicely with multi-target for:
>> for my ($i, $v) (@array[*]) {
>> ...
>> }
>
> Typo: s/@array/%array/

This was a typo.

> So … are there any traps in confusing everything-slices with Zen slices?
>
> Alterntively, are there traps in confusing everything-slices with Raku's Whatever-slicing (which gets the star)?

I am not keen on "nothing" as a signifier. Consider that right now, @array[()] produces an empty list.

I don't like that a pair of empty parens, put seemingly where one expects a list, are different to putting nothing. Better that each kind of nothing act like the other, and that something different looks different.

--
rjbs

On Sun, Jun 20, 2021, at 8:01 AM, Paul "LeoNerd" Evans wrote:
> > %hash{*}; # equivalent to %hash{ keys %hash };
>
> Isn't this values %hash ?

Nope.

DB<4> %hash = (a => 1, b => 2, c => 3)

DB<5> x [ %hash{ keys %hash } ]
0 ARRAY(0x7f8a53c60bb0)
0 'c'
1 3
2 'b'
3 2
4 'a'
5 1

That's a pair slice. Note the use of the % sigil in all caes. @hash{ keys %hash } would've been the same as values.

> Can we further imagine that these would also be allowed on refs via
> arrows?
>
> foreach my ($idx, $val) ( $aref->%[*] ) {
> ...
> }

Yes, it must be allowed there for postfix dereference to remain first class.

> Overall, I still feel that it will stomp on less future syntax and be
> "friendlier" if we spelled this "enum" or "enumerate" or somesuch
> keyword, instead:

"kv"

> Perl already has a reputation for being dense punctuation soup - can we
> not make it worse?

I'll admit that this line of argument rarely sways me, but I know other people are more bought in.

--
rjbs

On Sat, Jun 19, 2021 at 09:53:27PM -0400, Ricardo Signes wrote:
> Porters,
>
> I feel confident that this should be an RFC, but our process says "post to p5p before writing up an RFC," and "write something less format" sounds great. So:

"Less formal"?

The discussion all seemed be around "this is a good idea, but how should the
syntax work?", not "this don't seem to be worth it", so that implies

|
v
Exploratory RFC
"we think this idea is worth exploring"
(Help us figure out how this will work)


yes, please write an RFC.

I was assuming that you get the next available number in the repository at
the point when README.md is updated with your RFC's title.

(which I assume is going to be something more like
"everything slices for arrays and hashes" than "everything-slices")

Nicholas Clark

2021-6-20 10:54 Ricardo Signes <perl.p5p@rjbs.manxome.org> wrote:

> Porters,
>
> I feel confident that this should be an RFC, but our process says "post to
> p5p before writing up an RFC," and "write something less format" sounds
> great. So:
>
> I would like to propose a new piece of syntax. It's not my own original
> idea, it's come from a few places and individuals independently, but I'm
> the one who's ready to go to bat for it here. It is the *everything
> slice*.
>
> An everything slice is a slice that includes every element in an
> aggregate. We can hash out syntax, but let's start by saying "it's a slice
> where the subscript is replaced by a literal asterisk."
>
> So:
>
> @array[*]; # equivalent to @array[ 0 .. $#array ];
> %array[*]; # equivalent to %array[ 0 .. $#array ];
>
> @hash{*}; # equivalent to @hash{ keys %hash };
> %hash{*}; # equivalent to %hash{ keys %hash };
>
>
>
>
Personally, I'm interested in everything slice.

I feel that the next two are a natural pair.

my @nums = $nums->[1, 2, 3];
my @nums = $nums->[*];

Are you planning the RFC?

A new slice syntax should look closely at what Python does. The start and end are separated by a colon and the range is half-closed, so "start up until end", as commonly used in C-style for-loops and C++ iterators. Either can be omitted and so an "everything slice" is list[:].

I think the half-closed range is more elegant than Perl's .. giving a fully inclusive range, which then requires the $#a syntax to give one less than the length of @a. In Perl I guess it would look something like

@array[:3] # equivalent to @array[0 .. 2]
@array[0:2] # equivalent to @array[0, 1]
@array[:$len] # equivalent to @array[0 .. $len - 1]
@array[:] # equivalent to @array[0 .. $#array]



This email and any files transmitted with it are CONFIDENTIAL and are intended solely for the use of the individual(s) or entity to whom they are addressed. Any unauthorised copying, disclosure or distribution of the material within this email is strictly forbidden. Any views or opinions presented within this email are solely those of the author and do not necessarily represent those of PGIM Limited, QMA Wadhwani LLP or their affiliates unless otherwise specifically stated. An electronic message is not binding on its sender. Any message referring to a binding agreement must be confirmed in writing and duly signed. If you have received this email in error, please notify the sender immediately and delete the original. Telephone, electronic and other communications and conversations with PGIM Limited, QMA Wadhwani LLP and/or their associated persons may be recorded and retained. PGIM Limited and QMA Wadhwani LLP are authorised and regulated by the Financial Conduct Authority. PGIM Limited (registered in England No. 3809039) has its registered office at Grand Buildings, 1-3 Strand, Trafalgar Square, London WC2N 5HR and QMA Wadhwani LLP (registered in England No. OC303168) has its registered office at 9th Floor, Orion House, 5 Upper St. Martin's Lane, London, England, WC2H 9EA.

Please note that your personal information may be stored and processed in any country where we have facilities or in which we engage service providers. If you provide personal information to us by email or otherwise, you consent to the transfer of that information to countries outside of your country of residence and these countries may have different data protection rules than your country.

To learn about our privacy policies, please use this link<https://www.pgim.com/disclaimer/privacy-center> to read the Privacy Notices.

Op 19-08-2021 om 10:17 schreef Ed Avis:
> A new slice syntax should look closely at what Python does.? The start
> and end are separated by a colon and the range is half-closed, so
> "start up until end", as commonly used in C-style for-loops and C++
> iterators.? Either can be omitted and so an "everything slice" is list[:].
>
> I think the half-closed range is more elegant than Perl's .. giving a
> fully inclusive range, which then requires the $#a syntax to give one
> less than the length of @a.? In Perl I guess it would look something like
>
> @array[:3]????? ? # equivalent to @array[0 .. 2]
> @array[0:2]?? ?? # equivalent to @array[0, 1]
> @array[:$len]? # equivalent to @array[0 .. $len - 1]
> @array[:]??????? ? # equivalent to @array[0 .. $#array]


How about reusing .. for that?


@array[..2]????? ? # equivalent to @array[0 .. 2]
@array[0..1]?? ?? # equivalent to @array[0, 1] (this already works today)
@array[..$len-1]? # equivalent to @array[0 .. $len - 1]
@array[..]??????? ? # equivalent to @array[0 .. $#array]

AFAICS these are currently syntax errors.

HTH,

M4

@array[..2] # equivalent to @array[0 .. 2]

I think that's a nice generalization of the current syntax. I think similar proposals have been discussed on this list before.


This email and any files transmitted with it are CONFIDENTIAL and are intended solely for the use of the individual(s) or entity to whom they are addressed. Any unauthorised copying, disclosure or distribution of the material within this email is strictly forbidden. Any views or opinions presented within this email are solely those of the author and do not necessarily represent those of PGIM Limited, QMA Wadhwani LLP or their affiliates unless otherwise specifically stated. An electronic message is not binding on its sender. Any message referring to a binding agreement must be confirmed in writing and duly signed. If you have received this email in error, please notify the sender immediately and delete the original. Telephone, electronic and other communications and conversations with PGIM Limited, QMA Wadhwani LLP and/or their associated persons may be recorded and retained. PGIM Limited and QMA Wadhwani LLP are authorised and regulated by the Financial Conduct Authority. PGIM Limited (registered in England No. 3809039) has its registered office at Grand Buildings, 1-3 Strand, Trafalgar Square, London WC2N 5HR and QMA Wadhwani LLP (registered in England No. OC303168) has its registered office at 9th Floor, Orion House, 5 Upper St. Martin's Lane, London, England, WC2H 9EA.

Please note that your personal information may be stored and processed in any country where we have facilities or in which we engage service providers. If you provide personal information to us by email or otherwise, you consent to the transfer of that information to countries outside of your country of residence and these countries may have different data protection rules than your country.

To learn about our privacy policies, please use this link<https://www.pgim.com/disclaimer/privacy-center> to read the Privacy Notices.

On Wed, Jun 23, 2021, at 7:24 AM, Nicholas Clark wrote:
> yes, please write an RFC.

At long last, I have done this.

https://github.com/Perl/RFCs/blob/master/rfcs/rfc0005.md

I *think* I have followed the procedure correctly. I found the documentation a bit confusing, but possibly I'm just tired today. I think it'd be useful to review it in terms of making a simple "what to do next at every step" document. But as we're only 5 RFCs in, this may be premature. Or maybe this is why we're only 5 RFCs in. ????

--
rjbs