acmp again !
forax at univ-mlv.fr
forax at univ-mlv.fr
Thu Feb 21 15:07:43 UTC 2019
----- 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.
More information about the valhalla-spec-experts