[JSR308] A simple proposal for recursive annotations

[Lex Spoon]

On Jun 7, 2009, at 11:11 PM, Jonathan Aldrich wrote:
>>> (because the annotations in the static checking system may be
>>> parameterized in different ways than Java type parameterization).
>> I admit this strikes me the same way as it struck an earlier  
>> poster.  It looks like a bad trajectory for the annotation language  
>> to be significantly more sophisticated than the annotated language.
>
> Sorry, I wasn't proposing anything more than just the ability to  
> build up annotations recursively, like any recursive data structure  
> in Java. It turns out that's enough to encode parameterization in  
> annotation-based type systems.  If you thought I was proposing  
> adding "native type parameters" to annotations, well, that would be  
> interesting but as you say is clearly outside the scope of the JSR.

>
> For examples of where you might want to encode "annotation  
> parameters" in different places in a library than already have type  
> parameters, see my earlier message to the list.

I presume you are talking about this thread from October:

https://lists.csail.mit.edu/pipermail/jsr308/2008-October/000487.html

I have now read the above message.  I thought a few days ago that you  
meant some form of self-referential annotations.  Instead, you seem to  
be talking about allowing annotations to be used in places where  
literals are currently required.  I might have chosen "nested  
annotations" to avoid the self-referential connotation, but let's go  
with recursive.  Indeed it's a narrower scope than I realized.   
However, my conclusion is the same.  Let's dig in.

I agree with you that there is a welcome expressiveness increase in  
what you describe.  The examples you give remind me strongly of recent  
ETHZ work on "universe" types, and that work certainly benefited from  
Scala's analogous features.  However, I still think a language is  
better served if its annotation language reuses the core language's  
expression language rather than designing its own.  The main benefit  
is one of orthogonality, although it also looks like less work.

First let's consider whether it's sufficient.  As far as I can tell,  
using expression forms such as new expressions and array literals  
would suffice for your use cases, just as they sufficed for the  
Universe types group.  What do you think?  The recipe is  
straightforward: imagine Java syntax to construct the type, and then  
change the initial "new" to "@".

For example, here is a sequence based on an example from the October  
email:

@OwnershipArgs({@Shared})    // recursive annotations
new OwnershipArgs(new Shared())  // run-time type
@OwnershipArgs(new Shared())  // expressions within annotations


I believe this example works out fine.  Can you think of examples  
where the expressions approach would be problematic?

Sufficiency is not the only issue, of course.  Let's look at the two  
you raise here:


>> If the annotation language seems too constraining, I would propose  
>> what we did for Scala's annotations.  Specifically, Scala allows  
>> arbitrary expressions to be embedded within the annotations.  That  
>> approach keeps the annotations group from becoming a general- 
>> purpose language design group, it allows a very general language of  
>> annotations, and it provides synergy with the underlying language.   
>> As one example of this synergy, someone designing an a set of  
>> annotations can arrange that evaluating the embedded expression  
>> would give a run-time representation of an equivalent type.
>
> That would be great, both in terms of expressiveness and a nicer  
> syntax for saying complex things.  But I think it would also be a  
> much bigger change than recursive annotations, which are uglier  
> syntactically but can at least express what you want....

I have the opposite conclusions: the ones you propose are better  
syntax, but take more work.  I wonder where we are not matching up in  
our analysis?

For the quality of the syntax, I believe the October email is better,  
especially for array literals.  However, it strikes me as ideally  
something better taken up in the core language.  For example,  Java  
could allow  "new Foo" if the constructor has no parameters.  Also,  
Java could allow "{foo1, foo2}" as an array whenever the context makes  
the array type clear.  Is the core language sufficiently stuck that  
the annotations group is ready to vote no confidence on it and make  
our own?

For the necessary amount of work, much of the appeal to me is to reuse  
existing design work!  All that is needed for the expressions version  
is to decide on how to pickle the information into class files and to  
extend the API to give access to the information.  The October email  
implies strictly additional work: designing the new syntactic forms  
for annotations themselves.

Perhaps I can provide one clarification that I didn't mention in my  
last email.  It is certainly not necessary to allow *all* Java  
expressions.  In particular, drop anonymous inner classes.



>> All this said, it first seems important to accomplish 308's main  
>> task of allowing annotations on types at all.  Extending the set of  
>> annotations is a further step beyond the main scope, isn't it?
>
> There are a set of annotation expressiveness tweaks already in the  
> proposal which are not directly "allowing annotations on types" but  
> are supportive of that.  I'd put recursive annotations in that  
> category, with the justification of encoding annotation  
> parameterization and/or mimicking/shadowing the existing (recursive)  
> structure of types in Java.  It's a judgment call--but my sense is  
> that if we can figure out the details, this is a high-value addition  
> and is as well in scope as other items in the current proposal.

My mistake.

Overall, I believe I now see what you are getting at with  
expressiveness.  It still strikes me as a helpful finesse, though, to  
reuse the core language's expression syntax rather than design a new  
one.

Lex

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.csail.mit.edu/pipermail/jsr308/attachments/20090608/12b6ec7d/attachment.htm