I have a few thoughts.
1) Keyword proliferation
I’m skeptical of the “slippery slope” argument. As a practical matter, how many people are both capable of writing changes to perl and also willing to do so? Too small to actually multiply the number of keywords significantly.
I keep hearing PHP given as a counterexample, but while it does have a very long list ( https://www.php.net/manual/en/indexes.functions.php <https://www.php.net/manual/en/indexes.functions.php> ), it’s clear that this includes a lot of what would in Perl be hidden away in module documentation (e.g., the many PHP functions beginning “Imagick::” or “curl_”). I’m not about to go count up the list of exportable functions or public methods in every Perl core or dual-life module, but I bet it’s comparable.
And, while I understand that it avoids conflicts with existing code to put new keywords in a package like Scalar::Util, in practice that just makes it necessary to look up things in several places rather than just one. That’s not easier; it’s just distributed, hard-to-look-up keyword proliferation rather than easier-to-look-up keyword proliferation. I think protecting new keywords with a feature flag should be sufficient, for any keyword that’s likely to be widely used, or which should be used rather than using misfeatures (“Scalar::Util::reftype" rather than “ref”), or using functions inefficiently (“List::Util::first” rather than “grep” ).
2) Attributes to functions (like “sort :num”)
The conventional way to handle this in perl is by specifying named arguments (which presumably are assigned to a hash):
mysort (order => ’num’, values => \@values);
I personally think named arguments ought to be made first-class — included in signatures and usable for core functions. I don’t know if there’s a way that an existing core function like “sort” could be made to accept them without breaking backward compatibility (although I guess “sort HASHREF” could work, if it wasn’t too slow).
3) $a and $b
I was under the impression that the reason for using $a and $b instead of @_ is primarily because using $a and $b is faster. Seems to me any alternative to using $a and $b should be at least as fast before $a and $b are deprecated.
4) sort CODEREF @list
Presumably, if it hadn’t been created before code refs were a thing, sort would accept coderefs rather than a sub name.
Nicholas Clark wrote:
> I *think* that your new suggestion is only "not currently valid syntax"
> because you omit the comma.
[…]
> Put a comma in, and the code means something else.
>
> That feels like a risky design.
print $fh “Hello, file\n”;
print $fh, “Oops\n”;
--
Aaron Priven, aaron@priven.com, www.priven.com/aaron
1) Keyword proliferation
I’m skeptical of the “slippery slope” argument. As a practical matter, how many people are both capable of writing changes to perl and also willing to do so? Too small to actually multiply the number of keywords significantly.
I keep hearing PHP given as a counterexample, but while it does have a very long list ( https://www.php.net/manual/en/indexes.functions.php <https://www.php.net/manual/en/indexes.functions.php> ), it’s clear that this includes a lot of what would in Perl be hidden away in module documentation (e.g., the many PHP functions beginning “Imagick::” or “curl_”). I’m not about to go count up the list of exportable functions or public methods in every Perl core or dual-life module, but I bet it’s comparable.
And, while I understand that it avoids conflicts with existing code to put new keywords in a package like Scalar::Util, in practice that just makes it necessary to look up things in several places rather than just one. That’s not easier; it’s just distributed, hard-to-look-up keyword proliferation rather than easier-to-look-up keyword proliferation. I think protecting new keywords with a feature flag should be sufficient, for any keyword that’s likely to be widely used, or which should be used rather than using misfeatures (“Scalar::Util::reftype" rather than “ref”), or using functions inefficiently (“List::Util::first” rather than “grep” ).
2) Attributes to functions (like “sort :num”)
The conventional way to handle this in perl is by specifying named arguments (which presumably are assigned to a hash):
mysort (order => ’num’, values => \@values);
I personally think named arguments ought to be made first-class — included in signatures and usable for core functions. I don’t know if there’s a way that an existing core function like “sort” could be made to accept them without breaking backward compatibility (although I guess “sort HASHREF” could work, if it wasn’t too slow).
3) $a and $b
I was under the impression that the reason for using $a and $b instead of @_ is primarily because using $a and $b is faster. Seems to me any alternative to using $a and $b should be at least as fast before $a and $b are deprecated.
4) sort CODEREF @list
Presumably, if it hadn’t been created before code refs were a thing, sort would accept coderefs rather than a sub name.
Nicholas Clark wrote:
> I *think* that your new suggestion is only "not currently valid syntax"
> because you omit the comma.
[…]
> Put a comma in, and the code means something else.
>
> That feels like a risky design.
print $fh “Hello, file\n”;
print $fh, “Oops\n”;
--
Aaron Priven, aaron@priven.com, www.priven.com/aaron