Removal of function types

[Peter Levart]

On 07/07/10, Brian Goetz wrote:
> > 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?

Brian, 

I think it is and for that reason I urge you to not do anything that would prevent adding function types later (maybe in JDK8). 

The best way to make sure this doesn't happen is to specify them now, but leave them out of implementation for JDK7 (maybe even put them into the prototype but so that they can be "disabled" with a boolean flag).

I think that current specification that removes function types could be accompanied with an optional addendum called "function types". BGGA specification did something like that. This way any conflicts found between "main lambda specification" and "function types addendum" could be polished out early.

The "function types" addendum could be carried out as a community effort if Oracle has limited resources. I'm sure there are volunteers on this list (me included) if Oracle is prepared to consider this as a viable way to affect the "main specification" in areas where conflicts with "function types addendum" are identified.

What do you think?

Regards, Peter

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