Finding the spirit of L-World

[forax at univ-mlv.fr]

> De: "Brian Goetz" <brian.goetz at oracle.com>
> À: "Remi Forax" <forax at univ-mlv.fr>
> Cc: "valhalla-spec-experts" <valhalla-spec-experts at openjdk.java.net>
> Envoyé: Mardi 8 Janvier 2019 18:44:11
> Objet: Re: Finding the spirit of L-World

> On 1/8/2019 11:20 AM, [ mailto:forax at univ-mlv.fr | forax at univ-mlv.fr ] wrote:

>>> Right.  And I'm saying, we can't sell that.  Values should work like an
>>> int; you can compare ints with ==.   I think the "Currently" story
>>> doesn't wash.

>> You can not use the "work like an int" argument here, a value type can contain
>> references, so it doesn't work like an int.

> Sorry, I don't buy it.

> One of the primary use cases for value types is numerics. Are we seriously
> telling people that they can't compare non-intrinsnic numerics with `==`? I
> realize that from a VM perspective, the "values have no ==" seems sound, but
> for the 99.9999% of Java developers that are not VM engineers, I don't think a
> single one of them will buy it.
A the level of the language, very early at the beginning of valhalla, we have talk about a way to annotate equals so == on a numeric value type will be redirected to equals (instead of not compiling like now). 
This is how you make a numeric value type works like an int. 

Another primary use case is to be able encode any lightweight functional abstractions like a monad or a cursor without paying any cost at runtime, for those value types, defining == as a numeric comparison make little sense. 

Rémi 

>> John proposed to stop the recursivity at some point, but it will be very
>> surprising too !

> No, in corner cases like this (and surely this is at least a corner of a
> corner), we eat the recursion. That's the sensible equality semantics for
> embedding a linked lists in a value.

>> So for now, i think the only possible semantics is to consider that '==' means
>> an address comparison for all kind of classes (reference or value class), so a
>> value class acts like a class for == and given that a value has no address, it
>> should return false.

> That's certainly not the only solution. Nor do I think its a remotely good one
> for Java developers.