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 21:09
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.
> 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.

Does this boil down to removing C<sort>'s support for a BLOCK? It's
in this BLOCK that $a/$b become significant.

Because I had to educate myself on the deep usage details of C<sort>
before replying, it seems that it does indeed support one to define
a subroutine - but by an undecorated name of an existing subroutine,

sort mysub @list;

It's probably safe to assume that signatures and anything available
via C<sub is available there. However, it also seems there is a
lack of support of either providing an subroutine reference or an
inline anonymous sub.

Still both (while related) seem to fall outside of the purpose of
the BLOCK support - which may be an incremental step towards what
providing a subroutine name allows.

To summarize, from this pre-RFC, I get the following potential

* eliminate BLOCK from support
* warn when $a/$b are being references in a subroutine (via SUBNAME)
* support a SUBREF (e.g., C<sort \&subref @list>)
* support inline anonymous sub (w/prototypes, signatures)

There are surely more, e.g.,; warn on $a/$b when used with anything
other than BLOCK. Another would be the rather pointless ability to
use an anonymous subroutine inline without the ability to capture
it for future use.

> 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.
> So what does p5p think? RFC worthy? a stupid idea? Re-submit later when
> signatures are in more common use?

I am not p5p, but I personally believe there is something here if it can
be refined more. I'm also not speaking from a place of any great expertise
other than the truth that, yes, I can empathize that the $a/$b thing is
a "wart" - i.e., inconsistent with other things related to scoping. Also,
sometimes I've just wanted to use $a/$b and got that "warning" that they're
special or something...

Hope that helps also.


> 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.

yes; see above. And also, as I've mentioned above, I think there is something
here. It might just more "support CODEREF/inline anonymous subs" more than
it is "get rid of $a/$b".


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