On Thu, Feb 15, 2001 at 03:07:51PM -0800, Edward Peschko wrote:
>
> > Also, if I have:
> >
> > @a = (1 .. 10);
> > $a, $b, $c = @_;
>
> How about 'an implicit parens around a set of statements separated by commas
> in any context'? This is consistent
>
> $a, $b, $c = $d, $e, $f; # ($a, $b, $c) = ($d, $e, $f);
Do you mean:
(($a, $b), $c) = (($d, $e), $f);
perhaps?
> And if you say something like:
>
> $a, $b, $c == 10, $d == 11
>
> you need to disambiguate the sub-statements by saying
>
> $a, $b, ($c ==10), ($d == 11)
So, the cost of leaving off parens at some places, is to add them elsewhere?
What's the point? In the long run, you aren't gaining anything, all you
are doing is messing up the precedence table. It's already complicated
enough, why have a different precendence table in perl6? Fine, you might
not need the parens for my(), you suddenly need them where you don't need
them in perl5.
>
> my $a = <STDIN> # DWIM
>
> my $a, $b, $c.
>
> As for your examples:
>
> GetOptions (foo => \(my $foo), bar => \(my $bar))
>
> tie (my $shoe) => $string;
Not enough arguments for tie...
This trap is documented.
> both of these look easier to follow to me, at least.
You're kidding, right? If I wanted LISP, I know where to find it.
> > $c becomes 10. Should $c become 3 when my is placed before $a?
>
> No, I think in both cases, they should produce '3'.
Ah, more pointless changes with perl5.
I think I've seen enough of perl6 by now. I'll treasure my copy of perl5
till the end of times.
Abigail
