> > 2) (4, 1, 2) + 7 returns (9). This is C comma behavior, and I always
> > found it incredibly non-intuitive. I'd really like to get away
> > from this, even if it means that this expression is a fatal error
> > "Can't add scalar to list".
[...]
> Agreed, however, that (2) is icky. My worry has been that removing
> C-comma behavior would break common constructs, but I haven't been able
> to find any that would really break (except obfuscated ones that would
> be better written in some other fashion anyway.) Statements like:
> foo() or (warn("blah"), next);
> work either way, because they don't rely on getting the "scalar value"
> of the list.
One thing that the C comma operator promises is that its left operand
(and all side effects) is completely evaluated before work starts on the
right operand. (This may not be strictly true in the Perl interpretation
of the operator; can a Perl5 developer comment?)
I'm pretty sure that for a Perl list, the order of evaluation of
elements isn't guaranteed, meaning that C<next> may evaluate before
C<warn> in the above example if it were treated exactly like a list.
(Again, can someone refute or support this?)
That said, I don't know of anything that the C comma operator can do
that you couldn't equivalently do with a Perl5 C<do> statement:
foo() or (do { warn("blah"); next; }); # Yes, it's ugly.
So I too support the notion that comma should always and only be a list
constructor.
--
Debbie Pickett http://www.csse.monash.edu.au/~debbiep [EMAIL PROTECTED]
Chaos, panic, & disorder - my work here is done. - button slogan
