interactions between type annotations and language model APIs.

[Werner Dietl]

Eric, Jon, all,

I don't see how variance comes into play, Eric.
A very simple example:

(bool ? new @A Object() : new @B Object())

To determine the type of the ternary expression, we need to compute
the least upper bound of the two cases.
For a particular type system, the LUB of @A and @B might be @C.
It would be nice if the compiler "asked" a plug-in for what the LUB of
the two types is, instead of taking @A, @B, or @A @B.

Currently, the compiler doesn't use either annotation, which to me is
better than incorrectly taking the wrong annotation.
Not promoting type annotations makes re-computation easier. If
incorrect type annotations are promoted, an external tool would also
need to know which type annotations from the compiler are correct and
which are incorrectly promoted.

So I see two options:
- provide a mechanism for external tools to decide how type
annotations are combined. From Jon's answer I take it that that is
unlikely to happen.
- only have type annotations in the locations explicitly written by
the programmer, which is the current behavior.

Eric, from your answer it sounds like you're working on changing the
current behavior.
Can you share more details of how you want to "preserve type
annotations everywhere they ought to be"?

cu, WMD.


On Thu, May 8, 2014 at 6:24 PM, Eric McCorkle <eric.mccorkle at oracle.com> wrote:
> 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.
>>



-- 
http://www.google.com/profiles/wdietl