hg: valhalla/valhalla/langtools: Add some functional juice to javac code

[David Chase]

I’d be interested in knowing the ultimate intention for tuples; if it is value types,
this subtyping is less useful because I think we intend restricted subtyping among
value types.  If we use them to model a parameter list (maybe not for Java) tuple
subtyping can indeed mask errors — if we have overloading among

  foo [ animal ]
  foo [ fish, fish ]

and call “foo [ trout, eagle ]” instead of a type error, we invoke the first one.
Similar surprises are possible in a pattern matching world.

David

On 2014-08-12, at 2:10 PM, Remi Forax <forax at univ-mlv.fr> wrote:

>> 
>> Regarding subtyping vs. flat - main motivation here:
>> 
>> http://gbracha.blogspot.co.uk/2007/02/tuples.html
>> 
>> By Liskov, a 3-element tuple is also a 2-element tuple - i.e. it has a first and second element. It's a different way of thinking about tuples - if you think about them as record types, what I ended up with is closer with what the theory says. Maybe we don't care this degree of fidelity - but again, this is an internal implementation.
> 
> Liskov is about types and behaviors, there is no field in Liskov world.
> I think that if Tuple3 is a subtype of Tuple2, it will hide some bugs instead of allowing polymorphic code.
> Mapping a Tuple3 to a Tuple2 by explicitly discarding one arguments is IMO better.
>  stream.map(tuple3 -> new Tuple2<>(tuple3.item0, tuple3.item1)). ...
> and again, tuples are value types for me; if you want subtyping, you should not use class inheritance
> but tuple implementation should implement a hierarchy of interfaces.