This is the mail archive of the
kawa@sourceware.org
mailing list for the Kawa project.
annotations for Kawa
- From: Per Bothner <per at bothner dot com>
- To: "kawa at sourceware dot org" <kawa at sourceware dot org>
- Date: Sat, 04 Dec 2010 08:08:34 -0800
- Subject: annotations for Kawa
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/