Removal of function types

[Rémi Forax]

ahhhh, you kill my lambda :)

Le 07/07/2010 20:16, Brian Goetz a écrit :
>> 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.)
>    

They mostly complain about generics because there is no reification
(see your point 3) and because they doesn't understand where to
put ? super/extends.

Function types have several advantages over SAMs.
(remember that to be useful SAMs must be generified, see my point below).
- no need to be have to understand long error message because
   you forget a ? extends or a ? super somewhere.
- no need to box/unbox things.
- no need to find a creative name for a god damn function.

> 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?
>    

yes.

> 2.  We've been using SAM types for years, and Java developers are comfortable
> with them.

Java developers are perhaps comfortable with SAMs but
the main drawback is that there is lot of SAMs that represent
exactly same thing just because you have to give it a name.

By example, you can count the number of filter/predicate SAM
you have in the JDK:
javax.swing.RowFilter,
java.nio.file.DirectoryStream.Filter,
javax.lang.model.util.ElementFilter,
javax.stream.EventFilter,
java.io.FileFilter,
javax.swing.filechooser.FileFilter,
javax.swing.filechooser.FileNameExtensionFilter,
java.io.FilenameFilter,
java.util.logging.Filter,
javax.imageio.spi.ServiceRegistryFilter,
javax.xml.stream.StreamFilter,
javax.sql.rowset.Predicate.

There is no interopt between them, no way to create a filter
that will returns true if one of the two filters taken as argument
is true (the generic orFilter) without having to write adapters,
proxies or decorators.

Function types are important because they allow to write combinators
and to reuse them at different places of a program.


>   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.
>    

JDK already contains bifurcations, it has more than 10 ways to represent
a function that takes an object and returns a boolean.


> 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.
>    

Function type can't be reified like SAMs can't be reified because
argument of type variable aren't available at runtime.
That's it.

Rémi