[EMAIL PROTECTED] writes:
: The two current examples of an evil expression block are do {} and eval {},
: which require a semicolon terminator. However, with eval {} leaving...
Er, eval {} isn't leaving exactly--it's turning into try {}, which is
also an expression block. Plus we potentially have BEGIN and INIT as
expression blocks. Plus any random closures that just happen to show
up in the middle of an expression.
: 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
: };
Hmm, seems like a another good spot to invoke the lone curly rule.
: 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.
If your putting more expression on the line after the }, I'd say you're
not exactly formatting for clarity. Such formatting encourages the
reader to think that a new statement is starting, who has doubtless by
this time forgotten that it's a "do" and not an "if". :-)
: 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;
And anyone who puts such a statement modifier on a do {} block deserves
whatever they get. Statement modifiers are best used on short
statements, not long ones.
: 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.
Form and content are deeply intertwingled in the human psyche.
: 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?
CHECK doesn't make sense, nor any other block-exiting hooks, since they
aren't run till after the surrounding code is done. PRE is a
possibility, though perhaps not sensical from a DbC point of view. If
there *were* a FIRST block, it would be an expression block.
: 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?
By that argument, we wouldn't ever change anything. :-)
: 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.
I think it's too easy to have accidental non-void contexts, which is
why I'm wanting to outlaw bare blocks at the statement level. But I
don't think that fact influences your argument one way or the other.
There's definitely some merit in what you say--I'm just not sure the
distant context should outweigh the close context when the block could
be arbitrarily long.
Larry
