>> If you write
>>
>> $burp = LISTIFY( grep {EXPR} @data );
>>
>> What's in the burp?
>By this argument, then why aren't these different?
It depends on whether you think the alpha or beta are
what you want. It's highly unclear why you aren't just
using straight scalar context there.
> @data = qw(this that and the other thing);
> $x = @lines = grep /th/, @data;
> $y = ($first, $second) = grep /th/, @data;
> $z = () = grep /th/, @data;
>
> print "$x, $y, $z"; # 5, 5, 5
>If list() were to return something different than the above, then "()="
>is not really a list constructor. Perhaps it's an array constructor? Of
>special interest is the second one, which while appearing to set only
>two values, actually creates a list (array?) of 5 somewhere. Then it
>turns around and $y gets its length.
That's because of list assignment. There are no mysteries here.
>However, curiously, split() does *NOT* do the same thing:
> $data = qq(this that and the other thing);
> $a = @lines = split /\s+/, $data;
> $b = ($first, $second) = split /\s+/, $data;
> $c = () = split /\s+/, $data;
> print "$a, $b, $c"; # 6, 3, 1
>Whoa. That's bad. I don't care which way you look at it, but that's bad.
% man perlfunc
...
When assigning to a list, if LIMIT is omitted, Perl supplies a
LIMIT one larger than the number of variables in the list, to
avoid unnecessary work.
And:
% perl -MO=Deparse -e '$a = @lines = split /\s+/, $data'
$a = (@lines = split(?\s+?, $data, 0));
% perl -MO=Deparse -e '$b = ($first, $second) = split /\s+/, $data'
$b = ($first, $second) = split(/\s+/, $data, 3);
-e syntax OK
% perl -MO=Deparse -e '$c = () = split /\s+/, $data'
$c = () = split(/\s+/, $data, 1);
There you have it. The compiler has helped you.
>We have the same exact operators, but one constructs a true list while
>the other constructs an array behind the scenes? Has anyone noticed this
>before?
This is documented behavior. I don't understand the hubbub.
>Yes, and as the simple examples above showed, there's some serious
>issues here with Perl 5's list context, IMO.
No, you just need to read how split works!
>One example you didn't address was this:
> foo( () = bar() );
>This, more than any others, is the one that drives me batty. It seems
>the solution for this to me is:
> 1. Always have bar() interpreted as a list context
> 2. Let foo()'s prototype specify arg1 as $ if it
> wants a scalar
What does that mean?
>That's certainly the most useful behavior that I can see. And if I just
>wanted to force the scalar then I could use:
> foo( scalar bar() );
>As far as I can tell through my examples, this is pretty much what
>happens now. So it might be worth just clarifying this concept.
>I would gladly drop the list() idea entirely if (a) we fix the broken
>stuff
Nothing is broken.
>and (b) clarify what we're doing with chained subs so the above
>foo() example never has to be used again.
I'm not sure what your confusion is. I'll read this again after
I wake up.
--tom
