Typed Method handles

[Neal Gafter]

On Mon, Jun 13, 2011 at 5:52 PM, Rémi Forax <forax at univ-mlv.fr> wrote:

> Hi Neal,
>
> On 06/14/2011 01:54 AM, Neal Gafter wrote:
> > Paulo-
> >
> > I think you misunderstood the technical meaning of my comment, its
> intended
> > tone, and my corporate affiliation.
> >
> > What I meant by "if we can't then we'll regret not doing it today" is
> that I
> > do not believe we will be able to add reified function types in the
> future
> > because it would break existing code (I can expand on this point if you
> > like).
>
> Please expand. I'm curious.
>


See <http://gafter.blogspot.com/2006/11/reified-generics-for-java.html>.

I believe that existing (erased) code cannot compatibly be retrofitted to be
reified.  That is in part because there is a great deal of code out there
that "takes advantage" of the fact that generics are erased.  In addition,
there are many existing generic APIs and implementations of those APIs that
are erased, and SE 7 is likely to add many more in the form of aggregate
operations.  Code using these APIs does not and will not preserve type
arguments at runtime, so I believe that even if we *add* reification to
Java, erasure will remain a part of the language for these APIs.

Furthermore, I believe that we will want lambdas and function types to have
some reasonable level of interoperation with SAMs and these APIs.  For
example, we might have some conversion from a SAM to a function type.  But
if the SAM is erased (as they are likely to be in SE 7), then there is no
place for the type arguments to "come from" in building an instance of the
function type.  Similarly, if you are implementing an "erased" SAM type and
building a function/lambda within the body of the implementation, the caller
is unlikely to have passed in types for the type parameters (remember,
existing generic SAMs are erased).  So the function type you build must be
"erased".  Consequently, even if we add reification, we will still have to
support erasure and all the complexities it causes.

So what do I mean about "adding reified function types breaking existing
code", since there are no function types today?  The problem is that
fully-reified function types could only be used in restricted
circumstances.  If function types are specified so that they are always
reified, programmers would find the the restrictions very burdensome
(function types wouldn't be allowed in the presence of erased types), and
code that works in some contexts using (reified) function types would have
to be completely rewritten using different techniques in the presence of a
non-reified type (e.g. generic types that predate the introduction of
reification).  This is actually worse than the existing restrictions on
arrays.

By this time you might well wonder what the point of adding reification is,
or why we are waiting to add function types (the problems with function
types and erasure that have to be addressed today would still have to be
addressed in this imaginary reified future).

Some people believe I am wrong, and that Java can be uniformly reified (i.e.
no more erasure) without breaking a significant fraction of existing code.
I think that would be really wonderful, but I'm skeptical that it is
possible.  The techniques that have been discussed sometimes infer the
"wrong" parameter type at runtime, and the program might fail due to a type
error much later.  Java is widely used enough that the compatibility
requirement is quite strong, and breaking real code in such a subtle and
difficult-to-debug way is unlikely to be acceptable.  Incidentally, programs
that would fail in this way work fine with erasure.

I believe Brian is holding out hope that I'm being too pessimistic.


> There are some technical questions about function types that must be
> solved:
>

Yes, we can't have a language feature without designing it.


>     A function type is an object type or not ?
>

I've never heard any suggest anything but yes.


>     Basically it should be like an array type, but array type are reified,
>
    Does it mean that function type should be reified.
>
    In that case, what about function type that use a generics.
>     A function type using only reified type is reified or not ?
>

Array types are effectively deprecated in contexts in which they encounter
generics, and are not statically typesafe.  That obviously won't work for
function types.  That's the basic problem of trying to use the same
approach.

Also some syntax questions are hard to solve :
>   - what is the syntax for function type ?
>

Yes, one would have to be selected.


>   - how a human can parse a function type with a function type as
> parameter type

    and/or return type ?
>

Much more easily than the corresponding idiom with SAM types.  See <
http://gafter.blogspot.com/2010/02/syntax-option-for-project-lambda.html>.
The simplest example of the kind of problem you mention would be currying.
With function types:

static <T,U,V>
(T)->(U)->V curry((T,U)->V function) {
     return t->u->function(t,u);
}
*
*Using SAM types (but the same lambda syntax) it would look something like
this:

static <T,U,V>
Function1<? super T, ? extends Function1<? super U, ? extends V>>
curry(Function2<? super T, ? super U, ? extends V> function) {
    return t->u->function(t,u);
}

The same example is given with exception transparently in the quoted blog
post.

Cheers,
Neal