Inferring lambda parameter types in an argument position

[maurizio cimadamore]

On 04/03/2011 22:18, Neal Gafter wrote:
> Maurizio-
>
> That's great!  However, I should say I'm more concerned about the 
> specification than about the current prototype, because
>
> 1. The prototype will change, but what we finally get is what we have 
> to live with;
> 2. The implementation needs to agree with the specification, not 
> merely appear to "do the right thing"; and
> 3. Getting the specification right is much harder, as the spec has to 
> give some reasonable result in *all* cases, not just the ones that 
> were encountered while developing the prototype.
You are absolutely right - the compiler has been proven very helpful to 
understand the limit of what can be achieved with local type-inference 
techniques (i.e. problems with chained calls, or exception tyransparency 
to name a few). All this information will be used to feedback the spec, 
so that we will end up with something sensible on both sides, also 
considering the use cases that we have been discussing so far (which I 
think are very reasonable).
>
> Also, there are interesting cases around nested lambdas with overload 
> resolution that the spec should be capable of handling:
>
> *a.F( x -> x.G( y -> H(x, y) ) )*
The above is quite nasty - in general you only will be able to establish 
members of the type of an unspecified lambda parameter after a type for 
it has been inferred (which should be done by looking at the expected 
formal type during overload resolution). Depending on which strategy we 
decide to support in the spec, 'x.G' might or might not be a typable 
expression (e.g. part of the problem is that doing overload resolution 
with partially inferred types could lead to selecting a method that 
could turn out to be inapplicable when all inference variables have been 
inferred).  The design space is very big - I think the best solution 
would be to find a resonable compromise between expressiveness and 
language complexity; speaking of which, all examples submitted in this 
mailing list and the experiments we are starting to make on collections 
are surely a valuable resource to drive design of type-inference forward.

Maurizio
>
> That said, I certainly agree that the prototyping effort is helping to 
> figure out what to specify.
>
> Cheers,
> Neal
>
> On Fri, Mar 4, 2011 at 12:11 PM, Maurizio Cimadamore 
> <maurizio.cimadamore at oracle.com 
> <mailto:maurizio.cimadamore at oracle.com>> wrote:
>
>     Hi Neal,
>     I think we are on the same page here. The current compiler works
>     *almost* fine - only problem is inference in chained calls (i.e.
>     chained call to 'filter' in your example) - but we are working on it.
>
>     Maurizio
>
>
>     On 04/03/11 19:16, Neal Gafter wrote:
>
>         interface Mapping<In, Out>
>         {
>             Out map(In in);
>         }
>         interface IndexedMapping<In, Out>
>         {
>             Out map(In in, int index);
>         }
>         interface Predicate<E>
>         {
>             bool isSatisfied(E e);
>         }
>         interface MyList<E>  {
>         <U>  MyList<U>  map(Mapping<? super E, ? extends U>  f) ...;
>         <U>  MyList<U>  map(IndexedMapping<? super E, ? extends U>  f)
>         ...;
>             MyList<E>  filter(Predicate<? super E>  p) ...
>         }
>         *
>
>         I would like to be able to write my lambdas with parameter
>         types elided:
>         *
>         *
>         *MyList<X>  list = ...;*
>         *MyList<Y>  newList = list
>             .map( #{ x ->  new Y(x) } )
>             .filter( #{ y ->  y.IsFunny() } );*
>
>         This is all modulo syntax.  I'd prefer the syntax
>
>         *MyList<Y>  newList = list
>             .map( x ->  new Y(x) )
>             .filter( y ->  y.IsFunny() );
>         *
>
>
>