in reply to Re^2: Function Prototypes and Array vs. List (Pt. 2)
in thread Function Prototypes and Array vs. List (Pt. 2)

But the reverse call isn't one level removed. The call to reverse is the first argument and it is being evaluated in scalar context. In your example you have only one case of using a literal list in the foo_bar() call, which gives you a prototype error. In all other cases you are calling foo_bar() with a single expression that will be evaluated according to the context of the first (or only in your case) prototype.

Replies are listed 'Best First'.
Re^5: Function Prototypes and Array vs. List (Pt. 2)
by tadman (Prior) on Jun 13, 2002 at 15:06 UTC
    We're getting extra helpings of humble pie today, that's for sure. My bad.

    In a prior version of the code, I'd put reverse in a few of the functions, for example:
    sub returns_rtwo { return reverse qw[ foo bar ]; }
    To cut down on duplication, I'd left them out.

    Here's a little snippet that takes that one step further:
    #!/usr/bin/perl -w use strict; sub foo_p($) { print "$_[0]\n" } sub foo { print "$_[0]\n" } sub baz { qw[ foo bar ] } sub zab { reverse baz() } sub bam { return (baz(),zab()) } sub bar { return bam() } foo(bar()); foo_p(bar());
    On a regular, unprotyped function, you get your regular 'foo', but a prototyped version of same is a whole different thing.

    If you've got prototyped functions, you're going to have to get serious, I suppose, and stick to the letter of the law. No extra parameters, no mis-typed values, and no "random junk".

    Update:
    Considering the normal, unmolested return value of bar() is 'foo','bar','bar','foo', it is odd that you get 'raboof' because of the forced scalar(). The last function is trying to return an array with four values, so you'd think, at least on some plane of existence, that you'd get 4 in the end, but this is not the case. The only way you get this is if you assign to a temporary array:
    sub bar { return my @foo = bam(); }
      Re your update.

      scalar(bar()) calls bar in scalar context, thus bar's return() is in scalar context and is equivelant to return scalar(bam()), which means bam's return is equivelant to return scalar(baz(),zab()), which means each of baz() and zab() are called in scalar context and the result of the last one is returned.

      That propogation is no more suprising than what you get if you had used an explicit scalar coercion in your unprototyped version, foo(scalar bar()).