Control Invocation Syntax++

[Bruce Chapman]

OK, got it.


I remember Neal once blogged about BGGA and addressed why the control
invocation was a statement not an expression. I am trying to find a link to
that now. 

OK, got it. Not blogged but in BGGA v0.5
<quote>
Rationale: This is not an expression form for a very good reason: it looks
like a statement, and we expect it to be used most commonly as a statement
for the purpose of writing APIs that abstract patterns of control. If it
were an expression form, an invocation like this would require a trailing
semicolon after the close curly brace of a controlled block. Forgetting the
semicolon would probably be a common source of error. The syntax is
convenient for both synchronous (e.g. see withLock) and asynchronous (e.g.
see Executor.execute) use cases.
</quote>

I think the argument there about needing a terminal ';' when used as a
statement makes sense, however I can also see how making it an expression
enables the benefit of composition through method chaining. An obvious
solution is to allow both statement form (using {}) AND expression form
(using ()) but is that overkill?

There is at least one other way to achieve composition and which does not
require 
Control invocation to be an expression - maybe that is sufficient for the
(presumably) rare cases where an API designer wants to allow composition of
control invocation syntax as the best way for API users to interact with
some part of the API.


Bruce

-----Original Message-----
From: Peter Levart [mailto:peter.levart at gmail.com] 
Sent: Wednesday, 23 December 2009 11:11 a.m.
To: Bruce Chapman; closures-dev at openjdk.java.net
Subject: Re: Control Invocation Syntax++

On Tuesday 22 December 2009 22:10:48 Bruce Chapman wrote:
> Peter Levart said:
> 
> First, the syntax of parenthesized expression migh allow the expression in
> it to be optional:
> 
>     ParExpression:
>         ( [BlockStatements] Expression )
>         ( BlockStatements )
> 
> 
> I respond:
> 
> But a ParExpression is a kind of expression, so in your second form, what
> would be the value and type of that expression since statements don't have
> value or type?  I guess there is no answer which is why the expression is
> mandatory.
> 

I meant value "null", type "Void". Just like the following expression:
(Void)null;

That is the expression Neal is proposing to be automatically inserted after
block statements in 
0.6b variant of Control Invocation Statement.

Peter