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