interactions between type annotations and language model APIs.

[Eric McCorkle]

On 05/08/14 18:10, Werner Dietl wrote:
> In this message:
> 
> http://mail.openjdk.java.net/pipermail/compiler-dev/2014-May/008758.html
> 
> Alex raises the issue of "generator" methods and how  "the "correct"
> thing to do would be to inspect the TypeMirror argument and thread its
> type annotations into the TypeMirror result."
> 
> I agree that better support for type annotations in these methods
> would be great.
> It would also be awesome if subtyping, type inference, and other type
> operations were aware of type annotations.

In my ongoing work, I have taken careful steps to preserve type
annotations everywhere they ought to be.  Now, I can't guarantee at this
point that every single type that conceptually ought to have annotations
will, but this is a first step.

The prior step to making any such guarantee is figuring out what the
spec does, or ought to say.  Some cases are clear, others are not so clear.

Subtyping is such an example.  It is possible to think up examples of
type annotations that should be preserved for subtypes, others that
ought to be preserved for supertypes, and others that ought not to be
preserved at all.  (Stated more formally: we can think of type
annotations as commutative unary type functions, which means we might
see any kind of variance).

> In the Checker Framework we need to go to great effort to re-calculate
> some computations that the compiler already performed, just to add the
> right type annotations. This is error prone and we might produce
> incorrect results.
> 
> However, one complication is that to correctly "thread" type
> annotations through such computations, it is not enough to take the
> annotations from one side or the other or to append the lists of type
> annotations. For uses in type systems, you want to perform an
> operation like building the least upper bound or greatest lower bound
> of the two sets of type annotations.
> These operations depend on the particular interpretation of type
> annotations and I don't see how the compiler could independently
> perform the right operation.
> 
> It would be awesome if there were a way for outside tool-builders to
> adapt the behavior of the compiler in such situations.
> Is this something you are considering when planning these changes?

If type annotations had a notion of variance, I think that would solve
most of the cases I encountered in my recent patch.  I can't say for
sure it would solve them all, though.

> Cheers,
> cu, WMD.
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: eric_mccorkle.vcf
Type: text/x-vcard
Size: 314 bytes
Desc: not available
URL: <http://mail.openjdk.java.net/pipermail/type-annotations-dev/attachments/20140508/6017c507/eric_mccorkle.vcf>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 901 bytes
Desc: OpenPGP digital signature
URL: <http://mail.openjdk.java.net/pipermail/type-annotations-dev/attachments/20140508/6017c507/signature.asc>