[Jsr308-statements] JSR-308 Statements document update (discussion items and grammar changes)

[Michael Ernst]

Trevor, thanks for making the updates, and Eugene, thanks for your comments.

> -- Alternatives for the new Java syntax for annotations on statements and
> code blocks.  ...  Here is my attempt to identify all places we should
> add statement/block annotations to.

This characterization expands "Statement" in the grammar, and then prefixes
each by "Annotations".

I think it might be simpler and more consistent to replace

  Statement:
     ...  // current body of "Statement" grammar production

by

  Statement:  [Annotations] UnannotatedStatement

  UnannotatedStatement:
     ...  // current body of "Statement" grammar production


A version of the grammar that has changes in a dozen or more locations can
be offputting to readers in a misleading way.  In particular, what matters
is consistency as perceived by users.  In many cases a small grammar feels
simplest and most consistent to a user, but in some cases a larger grammar
can actually feel simpler and more coherent.  (That's especially true with
a language like Java that starts out with a grammar that is more irregular
than, say, that of Scheme.)  So I don't think that the size of the grammar
changes should be a particularly important factor in choosing among various
syntax alternatives (except insofar as it is correlated with
comprehensibility to programmers, of course).


>   In section "New Class File Attributes" [3], we need to decide if we 
> should use separate Runtime*StatementAnnotations or can reuse common 
> Runtime*TypeAnnotations attribute described in the main jsr308 spec [4] 
> and use special target_type value for statement/block annotations.

I have a slight preference for the latter, to avoid a proliferation of
attributes.  (Perhaps others will have a different opinion, though.)  We
can change the name from "Type" to "Extended" (or some other bland, less
descriptive name) if you like.

>   It is also topic for discussion if regular non-block statements should 
> be represented as a code range and not just an offset in the bytecode. 
> The reason is to make it easier to identify code for given statement. 

I agree that we should use a range, not just a single location, to identify
a statement.

>   In section "Block Syntax Support", we may need to consider using array 
> of reference_info to mark ranges of the code block in case if it is 
> split into the several ranges in the bytecode (i.e. "finally" and 
> probably some other cases).

Furthermore, we need an array to indicate multiple ranges, for instance if
a compiler reorders statements.  This is actually necessary even for
annotations on expressions as described in the main JSR 308 proposal.  Its
absence there is my fault, and needs to be corrected.  One that happens,
the statements proposal can simply use the same mechanism.  So I don't
think we need to worry about this too much (people who are concerned about
this aspect can focus on the main proposal instead).

                    -Mike