On Wed, 28 Aug 2002, Damian Conway wrote: > Any subroutine/function like C<if> that has a signature (parameter list) > that ends in a C<&sub> argument can be parsed without the trailing > semicolon. So C<if>'s signature is: > > sub if (bool $condition, &block); > > So the trailing semicolon isn't required.
Okay, so curlies always make surrounding commas optional (or verboten?), and make trailing semis optional when no more arguments are expected. This seems natural, and naturally extended to allow this $x = { 1 => 2, ... } $y = $x; or even this $x = { ... } $y = $x; since the parser sees ("$x", "=", "{") and, knowing that it only wants a single value, takes the closing "}" to be the end of the statement. This would let you do ugly things like this: @xs = (1 { $^x + 2 } 3, 4); # second element is a closure but most of the time, people would probably write readable code "by accident". Also, to follow up in two directions in two directions... First, if "if" can be defined as above, is this a syntactic or a semantic error (or not an error at all): if $test { ... } some_other_thing(); elsif $test2 { ... } # matching "if" above. I personally think it would be nifty, and would fit in with the ability to mix code with whens in a given. There'd be a bit of extra overhead involved in tracking whether or not we'd seen a true condition yet in the current if-sequence, but that's peanuts compared to other overhead. Second, is there a prototype-way to specify the arguments to "for" (specifically, the first un-parentesized multidimensional array argument)? In other words, is that kind of signature expected to be used often enough to justify not forcing people to explicitly extend the grammar? /s