[External] : Re: Can pattern methods be total ?

[forax at univ-mlv.fr]

----- Mail original -----
> De: "Brian Goetz" <brian.goetz at oracle.com>
> À: "Remi Forax" <forax at univ-mlv.fr>
> Cc: "amber-spec-experts" <amber-spec-experts at openjdk.java.net>
> Envoyé: Mardi 26 Janvier 2021 15:52:12
> Objet: Re: [External] : Re: Can pattern methods be total ?

>> I've certainly a more runtime oriented approach, everything the runtime needs to
>> link in order to perform pattern matching are what i call pattern methods.
> 
> So, there's really three layers here: the language model, the runtime
> model, and the translation scheme.  From a runtime perspective,
> deconstructors can translate to static methods (we don't need a new VM
> concept for this.)  We need to keep our eye on the translation and
> runtime model, but I'm pretty confident we have multiple efficient
> translation schemes available to us, so I'm focused right now on the
> language model.  Things like "deconstructors are total" can (like
> checked exceptions) be a language fiction that is erased away in
> translation, if we like.

The checking of being total or not at runtime is only important for the instance method when there is overriding,
apart if you want the typechecker to validate that the bytecode does not have partial runtime artifact (like by example return no-match) inside a total method.

> 
>> for records, the compact deconstructor doesn't have to specify the bindings
>> because they can be derived from the declaration.
> 
> Not so fast!  Yes, for a record _without an explicit canonical
> deconstructor_, we can derive a canonical deconstructor which delegates
> to getters (just as we can derive a canonical constructor.)  But, just
> as you can "override" the canonical constructor with your own (subject
> to rules), users should be able to similarly "override" the canonical
> deconstructor.
> 
> Of course, by that time, there will exist records in the wild without
> deconstructors, so we have a compatibility challenge.  One way to
> resolve that challenge is to indirect the lookup through indy/condy, so
> that we can reflectively look at the record class and see if it has an
> appropriate member, or whether we have to synthesize one.

yes,
i was talking about a potential _compact_ deconstructor if we decide to have one, not the fact that the compiler and the metafactory should act as if there is a canonical deconstructor when there is none.

record Foo(int a, int b) {
  pattern [int, int] Foo() {  // canonical deconstructor
    ...
  }

  pattern Foo() {  // compact deconstructor
    ...            // the bindings are inferred !
  }
}

Rémi