Removal of function types
Brian Goetz
brian.goetz at oracle.com
Wed Jul 7 11:16:00 PDT 2010
> The latest (6 July) lambda document removes function types. I support
> this (even though they were in FCM).
Indeed it does. People will ask why, so let me share my thinking here. Among
other reasons:
1. There are two basic approaches to typing: nominal and structural. The
identity of a nominal is based on its name; the identity of a structural type
is based on what it is composed of (such as "tuple of int, int" or "function
from int to float".)
Most languages pick mostly nominal or mostly structural; there are not a lot
of languages that successfully mix nominal and structural typing except
"around the edges." Java is almost entirely nominal (with a few exceptions:
arrays are a structural type, but at the bottom there is always a nominal
element type; generics have a mix of nominal and structural too, and this is
in fact part of the source of many of people's complaints about generics.)
Grafting a structural type system (function types) onto Java's nominal type
system means new complexity and edge cases. Is the benefit of function types
worth this?
2. We've been using SAM types for years, and Java developers are comfortable
with them. If we added function types, it would immediately bifurcate the
libraries (both JDK and external) into "old style" libraries (those that use
SAM types) and "new style" libraries (those that use function types.) That's
a big ugly seam in the middle of the platform.
3. No reification. There was a long thread about how useful it would be for
function types to be reified. Without reification, function types are hobbled.
For these reasons and others, we would prefer to leave out function types now.
> - Removing them reduces the scope, thus increasing the delivery likelihood
> - Function types look pig ugly with exception transparancy
> - Function types are a very different concept to the rest of Java,
> which is very name based
> - Function type don't visually look much like types (which are names
> everywhere else)
> - SAMs centralise the definition of Javadoc and give a meaningful name
> - function types don't
> - Function types were causing trouble when in a list/array due to
> generic erasure
> - Removing them removes some of the most contentious syntax debates
> - Function types can be added later if the right approach is taken (as
> in the doc) of declaring lambda expressions to have no expressible
> type.
>
> I suggest using this thread to comment on the removal of function types :-)
>
> Stephen
>
More information about the lambda-dev
mailing list