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

[Eugene Kuleshov]

Michael Ernst wrote:
>> -- 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.  
  I am not sure if change you suggested is the same. Check Block, 
assert... and Identifier elements. I am not sure if there is a need to 
annotate assert, but on the other hand, why not.

  Another reason to do it per node is that it will require different 
handling in the compiler. For example, to identify ranges.
> 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).
>   
  Completely agreed and that is why I've suggested Option 2 that only 
allows annotations on Block element.
>>   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.
>   
  +1. I think *Extended is a better name even if we won't use them for 
statements.
>>   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.
>   
  I think so too. Though there is a slight chance that some of the cases 
don't really need range, i.e. break, continue and return without a 
value. Some other ones, may never have multiple ranges (perhaps return 
with value). So, we need to decide between simplicity and size of the 
attribute (array will take an extra byte, unless we could use other size 
value to drive its boundary).

  regards,
  Eugene