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

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

Thread Next
From:
Aaron Priven
Date:
July 7, 2021 06:10
Subject:
changes to sort (numeric, deprecating $a and $b)
Message ID:
356E8ECB-469B-4B2C-AA91-5E214B7B8EA6@priven.com
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


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