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
