in reply to Is silent use of $_ for empty argument lists reasonable for "shortcut" functions?

Most of the time I wouldn't be tempted to write functions that operate on $_ if given no arguments. trim($_) is just not a big hardship compared to trim() (although I do use implicit $_ in some cases, I usually don't with chomp(), for example).

If I had a function that used $_ when given no arguments, then I'd likely not support taking a list of arguments (because of the ambiguity you noticed). Though, if you aren't likely to run into a relatively old version of Perl, then there is a somewhat ugly way around the ambiguity problem that I'm reluctant to mention because somebody would probably use it: 

sub trim(;\[$@]@)
{
    return _trim( $_ )
        if  ! @_;
    my $ref= shift @_;
    return _trim( eval{@$ref;1} ? @$ref : $$ref, @_ )
}

[download]

The ugliest part being that it breaks simple things like, my $l= trim(<STDIN>).

- tye        

  • Comment on Re: Is silent use of $_ for empty argument lists reasonable for "shortcut" functions? (E2CUTE)
  • Select or Download Code

Replies are listed 'Best First'.
Re^2: Is silent use of $_ for empty argument lists reasonable for "shortcut" functions? (E2CUTE)
by Wyrdweaver (Beadle) on Aug 26, 2007 at 09:36 UTC
    Interesting, I never thought of that method to figure out the arguments. But you're right, forcing the 1st argument into a reference breaks too many usual idioms (such as trim(<STDIN>) as you mentioned).

    I wish that "@_" was undef when a function is called with no arguments (as opposed to called with an empty array). Or, that there was some other way to detect no arguments without forcing the 1st argument into a reference.

    I appreciate the "spoiler". I'll add it to my perl KB (even if I never use it).

    - Wyrd
[reply]

      I wish / ... / that there was some other way to detect no arguments without forcing the 1st argument into a reference.

      There is, kind of. 

      sub foo {
    (caller(0))[4]
        or return foo($_);

    ...;
}

      [download]
      This will make $_[0] become aliased with $_ if foo was called with &foo and without the parenthesis. Personally I wouldn't use this. It will only lead to trouble.

      lodin

[reply]
[d/l]
[select]
        Yes, I looked into caller() and noted that caller()[4] is false if the function is called with the old function notation without ()'s, i.e. no new @_ is created when the function was called. But allowing users to use "&foo" as the function call when desiring "foo($_)" would seem to be a recipe for as much perlish surprise and sorrow as forcing the first argument into a reference.

        Sigh.

        Does Perl6 have the same limitations in determining argument construction for functions?

        - Wyrd
[reply]
[d/l]
      I thought about the undef vs. empty thing myself. It'd be rare, but it might break things for some people.

      Then I thought about $#_, which turns out to be -1 for both cases. I imagine changing it to, say, -2 for the empty list wouldn't break much, but there's always that chance. It also seems a little too magical and would definitely be a FAQ if it was done that way.

      I had pretty much the same thoughts about $_[-1]. Making it special for this case could be handy, but it's probably a bad idea.

      It'd be really nice if there was a variable or a built-in one could check that says whether there were any arguments to a function or not without enumerating them. Of course, a new built-in could break programs that have name conflicts with the new built-in. 

      sub foo {
    if ( has_args ) {
        foreach ( @_ ) {
            # ...
        }
    } else {
        # ..., but with $_
    }
}

      [download]
      Even an additional field on the end of caller could work I suppose, but (caller(0))[4] seems unsuitable at present. Perhaps if it returned 0 for &foo, 1 for foo(...), and zero-but-true for foo() it would be handy here. The nice advantage to adding to the end of an array that already gets returned is that it only breaks where one is taking [-1] as an element from the array... which is the same issue I guess as above.

      I like the zero/one/zero-but-true option for the fact that currently people probably only test for truth and not for equality to one, so making a special case such as empty args with parentheses or an empty list (pretty much the same for this scenario) probably wouldn't break anything. Of course, someone somewhere would get paged into work for a broken production system if just to prove me wrong.

[reply]
[d/l]
[select]

In Section Seekers of Perl Wisdom