Finding the spirit of L-World

[John Rose]

On Feb 23, 2019, at 3:25 AM, Remi Forax <forax at univ-mlv.fr> wrote:
> 
> This remember me another issue, we are discussing a lot about Java the language but that's not the only language that run on the JVM, by making acmp be an equivalent of substituableEquals() we are making a choice of semantics that may be ok for Java the language but clearly this change of semantics also impact the other languages, i'm thinking about Clojure's identical? by example.

JVM languages can and will change their translation strategy
if they don't like what acmp does (regardless of what we
end up doing).  That's one reason it seems likely to me
that the losers of the acmp sweepstakes (including my
old favorite, the one that is allowed to return false
if the JVM wants to punt), should be given useful jobs
under other names, not "acmp".  My working title for
the punting acmp is System.fastSubstitutabilityCheck.

The reason acmp is hard is that it's running in old code
that hasn't yet be upgraded.  Also, we want upgrading to
be easy.  This is one reason today's generics (though not
reified) place constraints on tomorrow's reified generics.
So it's not quite correct to say "that code isn't written yet"
as if it could compile under whatever new rules we want.