[JSR308] Others possible syntaxes for type annotations

[Maxim Kizub]

The proposition was about using uniform syntax for type parameters and 
annotations.
In this way type annotation syntax IS non-ambiguous, uniform and 
logical. Compare
1) @A String @B string;
2) @A String<@B> string;
The case (1) has strange reading rules, because it looks like (@A 
String) (@B string), but must be read as @A (String @B) string.
In contrast, in case (2) it's obvious, that @B belongs to type String, 
not to the variable.

Postfix type operators and syntax imports are syntax sugar, which proved 
to be very continent for me.
If you want to use type annotations, there will be a few very often used 
(like @NonNull or @CheckNull) standard
annotations, and a few project-specific (some projects will actively use 
@Immutable types, some will need
@NonNLS or @Interned strings and so on). Instant repetition of these 
annotations will make the code unreadable,
and postfix type operators will fix this problem (because there will be 
not too much annotations for types in a
concrete program). And the problem does exist, otherwise we would not 
use [] type operator
for arrays (and * & type operators in C++), but were satisfied with 
Array<Array<int>> instead of int[][].

If you don't want to add new keywords to the language, it's possible to 
reuse old keywords. Like

for type? do type<@CheckNull>;
or
@class type?  instanceof  type<@CheckNull>;

and so on. And since JSR 308 needs to change Java syntax - making the 
syntax convenient and readable is in scope of the JSR.

PS Programming language syntax and keywords must correspond to its 
current state. In russian alphabet during last centuries
a few letters were removed and added. Thanks to these changes, russians 
currently have alphabet which allows to write
words as they are pronounced. Unlike english. ;)
For example, type/method modifiers like "native", "synchronized", 
"strictfp" and all others are, in fact, annotations (which must be
supported by all java compilers and JVMs), and shell be replaces with 
"@Native", "@Synchronized", "@StrictFP" and so on,
to reflect latest language changes. But this is really not the scope of 
JSR 308.

Eugene Kuleshov wrote:
>
>  I am not sure if type aliasing is either a good idea or in scope of 
> the JSR 308. Though it is been considered a bad idea to add new 
> keywords to Java language, including "typedef" or "syntax".
>
>  As for alternative syntaxes, I spoke to Neal Gafter at the JavaOne 
> last week and he explained his idea for non-ambiguous syntax for 
> annotations to me. He was planning to send his proposal along with 
> Java language grammar changes to this list.
>
>  regards,
>  Eugene
>
>
> Maxim Kizub wrote:
>> Hello.
>>
>> For type annotations there may be others syntax solutions, not only 
>> prefix vs postfix.
>>
>> First, annotations may be seen as "external" type parameters. This 
>> can be expressed as
>>
>> Type<@NonNull> or List<String, @ConcurentAccess("write")> (or maybe 
>> use ; to separate arguments and annotations)
>>
>> Next, type annotations may be shortened using typedefs, like
>>
>> typedef StringNN String<@NotNull>;
>> typedef String0 String<@Nullable>;
>>
>> I tried to use typedefs (in my KievCompiler, which is used now as the 
>> core language for SymADE project, http://www.symade.org),
>> but found, that much more useful (for me) were postfix operators for 
>> types, defined by typedefs. For instance, we can define
>>
>> typedef type? type<@Nullable>;
>> typedef type! type<@NotNull>;
>> typedef type# type<@Immutable>;
>>
>> and then we can use operators on any type or combine multiple postfix 
>> operators together
>>
>> String? (equivalent to String<@Nullable>)
>> String!# (equivalent to String<@NotNull, at Immutable>)
>>
>> The same "type operator" definition syntax can be unified and used 
>> for all type parameters, for instance,
>>
>> typedef tp& WeakRef<tp>;
>>
>> will allow define weak references using & postfix type operator. Of 
>> cause, since there is little ASCII operators left,
>> it will be better to allow unicode operators (punctuation, 
>> mathematical, arrows, technical symbols and others
>> unicode subranges).
>>
>> Actually, [] and ... may be seen as "standard" type operators defined as
>>
>> typedef type[] java.lang.Array<type>;
>> typedef type... java.lang.Vararg<type>;
>>
>> Also, since typedefs are expected to be common for the whole project, 
>> java can have special import for syntax,
>> i.e. like it has "import static ...;" we may add "import syntax ...;" 
>> and record typedefs (as well as common imports for
>> the project) in the named section (in KievCompiler I also use "import 
>> syntax" to define operators - unicode image
>> plus priority, arity and association).
>>
>>