acmp again !

[forax at univ-mlv.fr]

----- Mail original -----
> De: "Brian Goetz" <brian.goetz at oracle.com>
> À: "Remi Forax" <forax at univ-mlv.fr>, "John Rose" <john.r.rose at oracle.com>
> Cc: "valhalla-spec-experts" <valhalla-spec-experts at openjdk.java.net>
> Envoyé: Jeudi 21 Février 2019 14:37:31
> Objet: Re: acmp again !

>> Again pick your poison.
> 
> The phrase "pick your poison" is misleading because it suggests all
> poisons are equally fatal.  And these two poisons are very, very
> different.  (Alcohol is a poison, and when taken recursively can indeed
> be fatal, but that's not the usual outcome, nor is it usually a deterrent.)
> 
> With the "always false" semantics, a fundamental building block of the
> language has perennially astonishing semantics in situations that will
> be routinely encountered by all users.  (We've seen languages where the
> `==` operator has semantics people can't understand; we don't want to be
> them, or have to deprecate `==` in favor of `===` because the language
> failed so hard the first time.)

I think you are mixing acmp and ==.
You can have acmp with the always false semantics and have an opt-in operator overloading mechanism so calling == on a value type is equivalent to calling equals(), but at language level, not at the VM level.
This is very equivalent to what we have now with int and Integer, an == of ints is a special semantics while == of Integers is acmp.

> 
> With the second, the performance will sometimes be mildly surprising
> when some wise guy thinks he's being clever and writes some ridiculous
> code, like a recursive value list.  Then he'll be told to cut that out,
> and life will go back to normal.

Composing lambdas that are parameterized creates the kind of recursive value types the Substitutibility test will not like.

> 
> This argument feels to me like "let's snatch defeat from the jaws of
> victory."  For years, we thought it was impractical that we could unify
> values and references.  But we are now 95% of the way there!
> Substitutibility is a sound, intuitive generalization of `==` over both
> refs and values.

Substitutibility is not a sound generalization.
But it doesn't mean the is no way to win, it's just that the Substitutibility test is not the way to win.

> 
> While we're on the subject of fantasy, let me call attention to another
> fantasy that we've been engaging in: that somehow values can remain this
> "weird, off-to-the-side thing."  In Q-world they were -- and when you
> were writing code, you always had to be aware of whether you were
> dealing with values or objects (and generic code had to learn new rules
> because they might be dealing with either.) But that's not the world
> we've built (thankfully!)  Here, values will be a common, every day
> occurrence (Optional, LocalDateTime) that all Java code will have to
> deal with.  (They're Objects!)  We have to give people a sound,
> intuitive model for dealing with the union of refs and values, because
> they're going to have to deal with that.  And we're almost there, as
> long as we don't blow it.

yes, that's exactly my point, we should not blow it by trying to have all objects operations ==, synchronized, identityHashCode, etc trying to masquerade the fact that those operations will never exactly works as their reference counterparts and that a 95% emulation is not a good idea because we want a sound and reliable model.

> 
> I realize that we started out hyper-focused on the performance aspects
> (because there'd be no point in doing values in the first place if we
> didn't care about performance.)  But, users will not thank us if we
> routinely choose confusing semantics because its faster.  Now it's time
> to focus on delivering a programming model that makes users say "why
> didn't you do that 20 years ago" -- and we can do that. This is winning;
> let's take it.

it's not about being faster, it's about not being randomly unpredictably slower. 

Rémi