So, the new rule for blocks and when the need semicolons seems to be
"You don't need a semicolon if the block is the last argument of a
subroutine which expects a block as its last argument", which is all
very well and all, but where does that leave:

    sub foo ( &block ) {...}
    ...
    $wibble = foo { ... } + 10;

The problem here is that this change makes the meaning of every brace
dependent on everything that's gone before and we're back with a
language that's at least as hard as Perl 5 was to parse. 

Now, my understanding was that the rule for 'statement terminating
braces' was


   1. brace matches rx/^^ \s* \} \s* $$/

Or, less strictly:

   2. brace matches rx/ } \s* $$/

Which I could have *sworn* was something Damian had told me was the
right thing, but I've mislaid the original mail. The idea behind this
approach, judging by the Apocalypse, is that it means that instead of
blocks needing or not needing a semicolon based on special cases, all
blocks have a simple rule.

Here's what Apocalypse 4 says on the subject:

   If there is any space before the curly, we force it to start a
   term, not an operator, which means that the curlies in question
   must delimit either a hash composer or a block. And it's a hash
   composer only if it contains a => pair constructor at the top level
   (or an explicit hash keyword on the front.) Therefore it's possible
   to unambiguously terminate an expression by following it with a
   block

Which seems to imply that:

   $wibble = foo {...} + 10;

would actually be parsed as:

   $wibble = foo {...}; +10;

Ah... hang on, that's *expression* not statement, so that should parse
as C<< $wibble = foo( sub {...}) + 10; >> which is fine. 

The rules for what the parser infers (semicolon, comma, nothing) after
a block are somewhat undefined though. How would

   func $foo {...}
   func $bar {...}
   func $baz {...}

deparse? C<< func $foo {...}; func $bar {...}; func $baz {...}; >>?
C<< func $foo {...}, func $bar {...}, func $baz {...} >>?

Am I worrying unduly about nothing?

What was my question? Argh! I'm more confused now then when I started
this message...

-- 
Piers

   "It is a truth universally acknowledged that a language in
    possession of a rich syntax must be in need of a rewrite."
         -- Jane Austen?

Reply via email to