annotations for Kawa

[Per Bothner <per at bothner dot com>]

Those of you who've been following Kawa CVS check-ins may have
noted that the low-level support for annotations is now mostly
there in gnu.bytecode.

The next issue is the syntactic support.  As suggested before,
the most logical syntax for an individual annotation is probably:

  (@AnnotationType keyword1: exp11 ... keywordN: exprN)

where AnnotationType is an annotation type name (identifier),
and exp1..exprN are compile-time-constant expressions.

As in Java, the shorthand:

  (@AnnotationType expr)

is short for:

   (@AnnotationType value: expr)

Annotations can be "attached" to declarations.  But we have a number
of choices.  For simple variable declarations we have these choices:

[v1] (define (@Deprecated) var ::type init-expr)
[v2] (define var (@Deprecated) ::type init-expr)
[v3] (define var ::type (@Deprecated) init-expr)

For a field declaration in a class we also have options.
(The examples use the object form that defines an anonymous
class, but define-class and define-simple-class are similar.)

[f1] (object () ((@Deprecated) var ::type option-pair...))
[f2] (object () (var (@Deprecated) ::type option-pair...))
[f3] (object () (var ::type (@Deprecated) option-pair...))
[f4] (object () (var ::type  option-pair... (@Deprecated)))

Java has the annotations before the new name, so would match [v1] and
[f1] best.  However note in the in Java the type and modifiers also
come before the name, while in Kawa-Scheme they come after.  So I
don't think [v1] or [f1] really make sense.  Personally, I don't
think [v3] or [f3]/[f4] look right.  So my preference would be:

[v2] (define var (@Deprecated) ::type init-expr)
[f2] (object () (var (@Deprecated) ::type option-pair...))

For a method declaration in a class, we have:

[m1] (object () ((meth (@Deprecated) arglist) ::rettype option-pair... 
body))
[m2] (object () ((meth arglist) (@Deprecated) ::rettype option-pair... 
body))

The advantage of [m1] is that it follows the rule that the annotations go
after the new name.  The advantage of [m2] is that annotations are in 
the same
category as return-type specifier and option-pairs and should be in the same
area in the definition syntax.  I'm leaning to [m2].

For a class one of these:

[c1] (define-class MyClass (@Deprecated) (MySuper) option-pair... member...)
[c2] (define-class MyClass (MySuper) (@Deprecated) option-pair... member...)

The advantage of [c1] is that it follows rule that the annotations go after
the new name, thus consistent with [m1].  The advantage of [c2] is that
it is consistent with grouping the annotations with the option-pairs.
I like [c1] more, though it may be less consistent with the other choices.
If one thinks of the (MySuper) spec as "corresponding to" a ::type
specifier, then I guess [c1] is consistent with that.

Note we're talking about recommended syntactic placement of annotations
in declarations - i.e. the preferred style.  The actual compiler might be
a bit more lenient.  For example it might allow annotations inter-mingled
with option-pairs.

Note that JSR 308 (slated for Java 8) may add annotations on types.
I think if these get added to Kawa the following would make sense:

(define str ::(@NonNull)Container (...))

I.e. a type annotation would be a prefix of the type specifier.

Comments?
--
	--Per Bothner
per@bothner.com   http://per.bothner.com/