DrWhy has asked for the wisdom of the Perl Monks concerning the following question:

From the no-that's-not-pedantic-enough-yet department:

What's the current Perl etiquette/style/conventional wisdom on when to prepend function calls with '&' and when to leave them off? I've got a situation where there are global functions being used all over the place inside other packages. The code looks like:

my $result = &::function($arg1,$arg2, ...);

Would it be preferrable to do this instead:

my $result = ::function($arg1,$arg2, ...);

"If God had meant for us to think for ourselves he would have given us brains. Oh, wait..."

Replies are listed 'Best First'.
Re: To & or not to & ?
by tachyon (Chancellor) on Nov 11, 2004 at 23:00 UTC

    $result = function(@args) would be usual syntax. You almost never need &. The main effects of & are that it passes @_ to the called function and you don't need () after the function name to pass strict. However do note that &::function and ::function are calling main::function(). This matters if you are in another package:

    #package main; # this is implicit bar( qw( some args that were passed along ) ); foo( 'foo() stuff' ); ::foo( '::foo() stuff' ); &::foo( '&::foo() stuff' ); sub bar { &foo; } sub foo { print __PACKAGE__, " foo got '@_'\n" } foo; # bareword will work with no strictures after sub defn package Foo; foo( 'foo() stuff' ); ::foo( '::foo() stuff' ); &::foo( '&::foo() stuff' ); sub foo { print __PACKAGE__, " foo got '@_'\n" } __DATA__ main foo got 'some args that were passed along' main foo got 'foo() stuff' main foo got '::foo() stuff' main foo got '&::foo() stuff' main foo got '' Foo foo got 'foo() stuff' main foo got '::foo() stuff' main foo got '&::foo() stuff'



      Note that, & only passes @_ IF you leave off the parens.

      So that, if bar was implemented

      sub bar { &foo(); }
      then it wouldn't pass anything at all to foo. So, &FUNC should be considered a different way to call than &FUNC(), because only one of them does something different than FUNC()

      Snazzy tagline here
        because only one of them does something different than FUNC()

        Actually, all of them do something different as shown below:

        > perl -le'@_=2;sub a($$) {shift or 1};print &a' 2 > perl -le'@_=2;sub a($$) {shift or 1};print &a()' 1 > perl -le'@_=2;sub a($$) {shift or 1};print a()' Not enough arguments for main::a at -e line 1, at end of line Execution of -e aborted due to compilation errors.

        Sorry for the pedantry.

        A reply falls below the community's threshold of quality. You may see it by logging in.
Re: To & or not to & ?
by dimar (Curate) on Nov 11, 2004 at 23:10 UTC

    This question does not succumb to pedantry as much as it may appear at first glance. It is actually a very good question, and one of the nagging concerns which motivated my Subroutine Bewilderment enumerated here and here.

    Although the responses were helpful, there was no systematic response regarding ampersand (&) other than basically, "you dont need to use ampersand"... and for me that's far too generic a response.

    FWIW, there's at least 1 benefit for using ampersand: when you want to invoke a typographical convention that clearly distinguishes subroutine calls from barewords. (yes, I know, the parenthesis actually does that for you anyway, but as we know from Subroutine Bewilderment, parenthesis are not an absolute requirement ... at least not for brave souls who want to craft subroutines that work like the built-ins 'map' and 'grep' et al...

    So this does not really answer your question, other than to suggest it is not a trifling one.

Re: To & or not to & ?
by itub (Priest) on Nov 11, 2004 at 23:48 UTC
    I would say that if you have a module explicitly calling functions in the main package, your module is not modular at all! If the "global" function is needed everywhere, it should be in a separate module, importable by the other modules. Or if a module needs another package (let's say the main package) to provide it with a function, perhaps it would be cleaner if main sent a reference instead:

    package main; Bar::bar(\&foo); sub foo { # do stuff } package Bar; sub bar { # need to call a subroutine provided by the caller my $subref = shift; $subref->(); }

    The only uses I have had for &sub are to generate subroutine references and to override subroutine prototypes.

Re: To & or not to & ?
by tilly (Archbishop) on Nov 12, 2004 at 01:51 UTC
    There is no official Perl style. Currently I leave the & off and always put parens in so that I can keep the same style in several languages. YMMV.

    However as others have said, if you're using functions from package A in package B, I'd strongly recommend using Exporter in package A so that package B can explicitly import the functions that it uses.

      Of all the reasons to or not to &, this one, by Tilly, so that I can keep the same style in several languages. is probably the one I fall back to the most.

      Most of the errors I have to deal with in cross language coding come from programming in one language, then switching to another but still using the other language's syntax (or commands).

      Anything I can do to allow me to code in the language de project (working on several different ones per day) is a blessing.

Re: To & or not to & ?
by TedPride (Priest) on Nov 12, 2004 at 07:50 UTC
    I tend to use &function whenever I'm not passing variables, and function() when I am. I may switch to always using function() now that I know about @_ being passed.
      That's a good idea anyway since a bare &function in Perl 6 won't call the function, but merely return a reference to the function.