The two current examples of an evil expression block are do {} and eval {},
which require a semicolon terminator. However, with eval {} leaving, that
leaves just do {}, which does (or should) fall more in line of thinking of
grep {}, map {}, and sort {}: the other expression blocks. For do {}, the
block just happens to be the only (and therefore, trailing) argument. (In
other words, from an language perspective, do {} really should be presented
more as 'do' and less as '{}'. Much of the block confusion came from the
specialization of do-while and do-until. But both of these are illegal in
Perl 6, so there's no longer a reason to propagate that misconception.)
With try {} appearing to be a proper block, that would leave do {} the only
beneficiary of the Lone Bracket hack. (For now. I continue this below.)
So, in essence, you are trading "you need to remember that do {} is just an
expression, treat is as such" to "do {} is an expression. You can write it
as a block (as long as the close bracket is on a line by itself), and we'll
tack on the semicolon for you, but don't write it as a block when you want
an expression, unless you put the rest of the expression on the same line as
the bracket." Although each individual rule is simple, the overall
semantics have become quite complex for such a small subsection of the
language. And attempting to leverage that against a lone bracket, I feel is
a mistake. From a linguistical perspective, that seems to be more
presentationally based, rather than contextual.
Most everything in Perl is done in context, so why not leverage that
instead? After all, the semi-colon will be needed to terminate an anonymous
hash assignment, yes?
my $ahash = {
foo => bar
};
It seems to me that when people use a block as a code block, they simply
don't make it do expressionish things. Like capture the return
value. Blocks are almost always - there are always Damians in the world -
used in a void context.
my $a = do {
....
}
No, it's not a block, it's an expression. It shouldn't even be presented as
a potential block. You've a do {} in the midst of a long string of things,
it shouldn't terminate simply because I'm formatting for clarity.
do {
...
}
could be a block. Particularly now that base blocks are forbidden, this
will be a block. The question is whether the expression continues
afterwords:
+ 1 for @x;
The parser should be able to determine whether the expression continues
on the next line. You either get an operator or a statement modifier, or
the block is terminated. But for the user who has to remember all the rules,
there's nothing to do. He just writes it. Contextual. Not presentational.
The Apo surmises that some other blocks may become expression blocks,
such as BEGIN {}. I assume CHECK {} and INIT {}, as well? END {} doesn't
make sense. How about any of the new blocks?
Now, you've added even more special cases to the semi-colon rule.:
BEGIN { foo() };
END { foo() }
Some will take them - sometimes - and others won't, at all. Sure, you could
always put a semicolon there, and create a null statement, but you don't do
that now, so why should you start?
Once again, I think the void contextual clues should be differentiating
between block and expression usage. Perl already exprects you to understand
differing behavior in void, scalar, and list context, and Perl 6 is expected
to add more. Why not continue in that direction here, instead of veering
off in some strange direction.
--
Bryan C. Warnock
[EMAIL PROTECTED]
