in reply to Re^2: (RFC) Arrays: A Tutorial/Reference
in thread (RFC) Arrays: A Tutorial/Reference
I guess they do.
I hate being cruel... but read the parser.
Or is that also a kind of disambiguation (of the match operator)?
In one sense, those parentheses only mark the empty list, but it's probably more accurate to say that those do create a list. That's only true for the empty list however, as parsers have a very difficult time identifying invisible, non-existent characters.
Hmm.. here they obviously don't force list context?
Correct. Why would you expect them to do so? They're immaterial to the expression, just as in my $x = ( 2 + 2 );.
If parentheses did create lists, what would you expect this code to do?
my $x = ( 1 + 2 ) * 3;Perl doesn't have a strict leftmost-applicative evaluation order, so the parentheses are necessary to disambiguate precedence.
That's the exact reason why the parentheses are necessary to group lists, but do not create lists. In:
my @fib_values = 1, 1, 2, 3;... the expression my @fib_values = 1 is a complete expression to the parser as it is. Now it may be completely unambiguous to you that the entire expression is a list assignment, but there are plenty of more complicated assignment forms that involve mixed expressions such that Perl will give you a warning that it may have guessed wrong in this case.
Note also that you don't need parentheses when passing an argument list to a function or especially a built-in operator... again, unless you need to disambiguate something.
|
---|
Replies are listed 'Best First'. | |
---|---|
Re^4: (RFC) Arrays: A Tutorial/Reference
by shmem (Chancellor) on Jan 13, 2007 at 20:16 UTC | |
by rir (Vicar) on Jan 15, 2007 at 03:52 UTC | |
by shmem (Chancellor) on Jan 15, 2007 at 08:24 UTC | |
by rir (Vicar) on Jan 17, 2007 at 01:41 UTC |