Re^3: implicit sort disables a chained subroutine?

Why not?

Or possibly a string variable or constant that is the name of the comparator function, though I'm not personally fond of that option.

You know, that's what it currently does. And it wouldn't make any difference in your case whether the comparator function were passed to sort as a coderef.

The problem is not that it's passing the function by name, it's how the parser decides whether an identifier at the given position is to be taken as a comparator function. I would have preferred if that required an ampersand and no parens; this would be analogous to a \&@ prototype (but of course the block is optional so sort still can't use a prototype) and would be unambiguous.

However, removing this special case from the parser at this point would break a lot of code so you're out of luck — it's ampersand and parens or a plus, no other option.

Makeshifts last the longest.

Comment on Re^3: implicit sort disables a chained subroutine?

Replies are listed 'Best First'.
Re^4: implicit sort disables a chained subroutine? by BrowserUk (Patriarch) on Jan 14, 2005 at 09:15 UTC
An it wouldn't make any difference in your case whether the comparator function were passed to sort as a coderef Hmm. I thought it would. If first parameter to sort was either a coderef or a string (constant) or bareblock, it would take it as a comparator, but if it is a bareword, then it's a (user or builtin) function that gets called and it results get passed to sort with the default comparator would be used. That would treat user functions the same as builtins are currently treated as with split in the example I showed. But you are right, that water passed under the bridge a long time since, and it is not going to change course now. It surprises me that I never encoutered this before. Examine what is said, not who speaks. Silence betokens consent. Love the truth but pardon error.	[reply]
Re^5: implicit sort disables a chained subroutine? by demerphq (Chancellor) on Jan 14, 2005 at 09:39 UTC
One interesting thing is that the behaviour of sort does change depending on the prototype of the sub being called. If it had a prototype of $$ sort would pass $a and $b in as arguments, if it has any other prototype it sets the packages $a and $b instead. Hypothetically I think it could throw an error if the prototype of the sub was (@) as that would almost certainly be DWIM getting things wrong. --- demerphq	[reply]
Re^5: implicit sort disables a chained subroutine? by Aristotle (Chancellor) on Jan 14, 2005 at 09:27 UTC
Ah, you meant coderef vs bareword as in syntax, not semantics. I agree that this behaviour is surprising. I guess that goes to show it isn't that bad a special case in practice, probably because comparator blocks are used too frequently for it to matter too much. Back in Perl4 without anonymous functions and prototypes available I guess this special case was actually good. Makeshifts last the longest.	[reply]