in reply to implicit sort disables a chained subroutine?

The question has already been answered, but, for what it's worth, a really easy way to avoid this is a plus sign: 
[me]$ perl -le 'sub uniq {keys%{{map{$_,undef}@_}}} print sort +uniq 1
+,4,2,2'
124
[me]$

[download]
Same technique is often useful to disambiguate other ambiguously-parsable constructs. 
------------
:Wq
Not an editor command: Wq

[download]

Replies are listed 'Best First'.
Re^2: implicit sort disables a chained subroutine?
by BrowserUk (Patriarch) on Jan 14, 2005 at 00:14 UTC

    Now that is interesting. Thanks, it's infinitely preferable to using & and brackets.

    I know and use the unary + trick for disambiguating, but I would never have thought to try that here. I would have been worried that applying unary + to a function returning a list might have resulted in a scalar context.

    Now my (mostly rhetorical) question is why does that allow the parser to recognise the function name as a sub returning a list, as opposed to a comparator function being passed?

    I suspect the answer may lie in the deparse output that shows the undisabiguated function name being passed as a string constant, despite that doing so requires the parser to see the token uniq as a bareword and silently convert it to a string constant, which it shouldn't have as strict is in force.

    I am convinced that there is a bug here. I think that sort should either take a bare block, or the address of a function, if the comparator is supplied.

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

    Under no circumstances, especially with strict in force, should it silently coerse a bareword function name into a string constant.

    Examine what is said, not who speaks.
    Silence betokens consent.
    Love the truth but pardon error.
[reply]
[d/l]

      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.

[reply]
        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]

In Section Seekers of Perl Wisdom