Proposal: Block Expressions for Java

[Joseph D. Darcy]

Hi Neal.

While I have some sympathy for expression-oriented rather than 
statement-oriented languages, my general reaction to this proposal is 
that it doesn't offer much incremental utility for expressing and 
simplifying programming idioms commonly used today, which is the main 
goal for Project Coin.

Some more comments in line...

Neal Gafter wrote:
> [Resending in plain text]
>
> Block Expressions for Java
>
> AUTHOR(S):
>
> Neal Gafter
>
> OVERVIEW
>
> FEATURE SUMMARY:
>
> A parenthesized expression can now contain additional statements, for
> example declarations of temporary local variables to avoid recomputing
> a value used only within the expression.  This feature is especially
> useful in machine-generated code.
>
> MAJOR ADVANTAGE:
>
> Allows the declaration of local temporary variables closer to the
> point of use.  Simplifies programs that generate Java code, as
> temporary variables that are used in only a single expression can be
> declared with the expression.
>
> MAJOR BENEFIT:
>
> Simplifies some patterns of code (see above).  Makes it easier to
> write expression-oriented code even though many APIs are statement- or
> side-effect-oriented.  Allows temporaries to be declared closer to the
> point of use.
>
> MAJOR DISADVANTAGE:
>
> Slightly more complex language specification.  Like most other
> language features, can be overused to the detriment of the readability
> of the code.
>
> ALTERNATIVES:
>
> In many cases, there are alternate though awkward ways of writing the
> code, such as introducing small helper functions that are used only
> once or introducing temporary variables.
>
> EXAMPLES
>
> SIMPLE EXAMPLE:
>
> double pi2 = (double pi = Math.PI ; pi*pi); // pi squared
>
> ADVANCED EXAMPLE:
>
> public static final Map<Integer,Integer> primes = (
>     Map<Integer,Integer> t = new HashMap<Integer,Integer>();
>     t.put(1, 2); t.put(2, 3); t.put(3, 5); t.put(4, 7);
>     Collections.UnmodifiableMap(t));
>
> DETAILS
>
> SPECIFICATION:
>
> Grammar: the grammar for a parenthesized expression [JLS 15.8.5] is changed to:
>
> ParExpression:
>  ( BlockStatementsopt Expression )
>
> Note that the existing syntax for a parenthesized expression is a
> special case of this.
>
> Meaning of Expressions: The specification for a parenthesized
> expression should be modified to describe its new execution semantics:
> The block statements (if any) are executed in sequence, from left to
> right, exactly as in a block statement.  The result of the
> parenthesized expression is the result of evaluating its
> subexpression.
>   

So what about return, break, and continue statements inside the 
BlockStatements?

> Definite Assignment: The definite assignment rules for this construct
> are almost identical to that for the block statement.  The definite
> assignment state before the subexpression is the definite assignment
> state following the last block statement.
>
> Exception Checking: A parenthesized expression can throw exception
> type E if any statement or expression immediately contained in it can
> throw E.
>
> Scoping: Local variables and classes declared by an immediately
> contained statement is in scope until the end of the parenthesized
> expression.
>
> Meaning of Statements: No changes.
>
> Type System: No changes.
>
> COMPILATION:
>
> Compilation is straightforward, with one minor exception (no pun
> intended).  The compiler must arrange the generated code such that the
> stack is empty at the beginning of any try statement that can complete
> normally when the try statement is embedded within a parenthesized
> expression.  That is because the VM empties the stack when exceptions
> are handled.  This can be accommodated by spilling values from the
> stack into VM locals.
>   

That doesn't necessarily sound minor!

> TESTING:
>
> Since the language change is completely local, it can be tested by
> exercising each of its interactions described above.
>
> LIBRARY SUPPORT:
>
> None required.
>
> REFLECTIVE APIS:
>
> No changes required.
>
> OTHER CHANGES:
>
> It would be desirable, at the same time that this change is made, to
> update the non-public Tree API that can be used with APT to express
> the syntax extension.
>   

FYI and to be precise on notation, we will *not* be updating apt to work 
with JDK 7 language features at all.  In contrast, the JSR 269 language 
model and annotation processing API used by javac will be updated.  The 
tree API will be updated as needed for any new language features, and, 
as you imply, using javac-specific APIs (i.e. non JCP APIs) it is 
possible to use the Tree API with JSR 269 annotation processing.

Cheers,

-Joe

> MIGRATION:
>
> None required.
>
> COMPATIBILITY
>
> BREAKING CHANGES:
>
> No breaking changes.
>
> EXISTING PROGRAMS:
>
> No effect on existing programs.  This is a pure extension.
>
> REFERENCES
>
> EXISTING BUGS:
>
> None.
>
> URL FOR PROTOTYPE (optional):
>
> None.
>
>