poly-expression type inference pothole

[John Rose]

P.P.P.S.  I just noticed this commentary in Part D:
> 	• The receiver in a method invocation, field access, etc. (exp.foo()) is not a poly expression because the target type is unknown—it would be impossible to enumerate every type that has a particular member (foo, in this case). There has been some interest in allowing inference to "chain": ina().b(), passing type information from the invocation of b to the invocation of a. This adds another dimension to the complexity of the inference algorithm, as partial information has to pass in both directions; it only works when the erasure of the return type of a() is fixed for all instantiations (e.g.List<T>). This feature would not fit very well into the poly expression model, since the target type cannot be easily derived.

It looks like what I'm asking for is allowing inference to chain through dot.  In that case, my two examples are some what illusory.

The high-level point is that unless inference can chain through dot, default methods will be much weaker (w.r.t. inference) than static methods, and so APIs will be driven to non-fluent (function-oriented) notations.  This is the time to fix it, not later, after we've invented lots of APIs.