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

changes to sort (numeric, deprecating $a and $b)

Thread Next
Aaron Priven
July 7, 2021 06:10
changes to sort (numeric, deprecating $a and $b)
Message ID:
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 ( <> ), 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,,

Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About