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

Re: Elevator pitch, deprecating $a/$b sort globals by using sub{}

Thread Previous | Thread Next
Oodler 577 via perl5-porters
July 5, 2021 15:33
Re: Elevator pitch, deprecating $a/$b sort globals by using sub{}
Message ID:
* Martijn Lievaart <> [2021-07-04 17:40:09 +0200]:

> Hi list
> Karl Wiliamson's remarks about $a/$b as a quirk got me thinking. With
> signatures as a language feature it's feasable to make sort not only take a
> blok or a subroutine name, but also a sub. That means $a and $b for sort can
> be deprecated in the long run, and eventually turned off with a feature flag
> if we so choose.
> So basically,
>     sort { $a->{x} <=> $b->{x} } @list
> could be written as:
>     sort sub($a,$b){ $a->{x} <=> $b->{x} } @list
> which is currently a syntax error.

I can see a value in allowing inline, anonymous subroutines where
signatures (and prototypes) are allowed; however the suggestion
above seems to be conflating




For BLOCK, $a/$b are necessary. However, this may point to the
actual "missing feature" of:

sort CODEREF LIST, which would in practice look like:

  my @sorted_list = sort \&mysub @list;


  my @sorted_list = sort sub { my ($lhv, $rhv) = @_; ... } @list;

The only potential weakness of (ii) is that there is no way to
capture a reference of the CODEREF defined inline; this would be
helpful if one used a C<state> variable inside of the inline CODEREF.
However, I can't think of a traditional way to capture the the
reference to the inline CODEREF with affecting what C<sort> returned,

  my ($sorted_list_ref, $coderef) = sort sub { ... } @list;.

> Yes, it is longer, but less of a wart. It lessens the cognitive load, avoids
> the $a/b global variables and makes the language more consistent.
> I do understand that this does not come for free, someone has to build this,
> and build it so it's as efficient as current $a/b usage when applicable. But
> maybe someone feels it is worth enough to have a second look at it.
> An argument against it, is that it adds yet another way to use sort, which
> already has three modes of operation. I think it is worth it, but that is
> certainly something to be considered, it lessens the cognitive load on one
> side and adds to it on another.

The cognative load might be alleviated, as others suggested, but hiding the
C<$a <=> $b> needed for non-default numerical (ascending) sort to be represented
by non-BLOCK things, so add a new class of specifier:

sort HOW @list

Where C<HOW> is a well defined set of orderings, e.g.:

  sort :NUMERICAL: @list

  sort :NUMERICAL:DESC: @list

Of course, you could get the worst of all worlds by supporting *SQL:

  sort q{ORDER by $_->{a} DESC} @list; 

*incidentally, ORDER (at least in MySQL) is numerical,


> So what does p5p think? RFC worthy? a stupid idea? Re-submit later when
> signatures are in more common use?
> HTH,
> M4
> P.S. That means 'sort \&x, @list;' probably should be valid too, which
> points to a syntax problem, why does the this one have a comma, but the
> 'sub($a,$b){}' version does not? There is some room for bikeshedding here.
> However, allowing this does not really add anything, as 'sort x @list;'
> already achieves the same thing, and easier at that. So allowing it would
> either be for consistency, or an artifact of implementation.

SDF-EU Public Access UNIX System - #openmp #pdl #native

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