hg: amber/amber: hooking records to patterns

[forax at univ-mlv.fr]

----- Mail original -----
> De: "Brian Goetz" <brian.goetz at oracle.com>
> À: "Remi Forax" <forax at univ-mlv.fr>
> Cc: "Vicente Romero" <vicente.romero at oracle.com>, "amber-dev" <amber-dev at openjdk.java.net>
> Envoyé: Vendredi 6 Avril 2018 21:21:10
> Objet: Re: hg: amber/amber: hooking records to patterns

> I think you're trying to solve a different problem.
> 
> The descriptor for an Extractor is like the descriptor for a method,
> except that it allows for multiple "return" values.  (If we had multiple
> return, we'd just use a method.)
> 
> You ask: "why does an extractor need a descriptor at all".  While you
> might be able to derive it from the return types of the components, they
> might actually not be the right types.  Suppose we have:
> 
>     class Foo {
>         ArrayList list;
>     }
> 
> and we have a pattern that yields a binding variable of type `List`.  If
> the component MH were Foo::list, it would (a) yield the wrong type, and
> (b) the type might be unstable if the implementation were to change.
> Having a stable descriptor for what the pattern yields as bindings as
> separate from the implementation for how to produce those bindings is
> necessary for stability.

All the problems of type you can have are true not only for the extractor but also for the getter/component method too,
so if you already the right type encoded in the component method, you do not need to provide the same information as a descriptor.

> 
> The association of patterns to factories (which are inverses) is a
> higher-level concept.  We may want a way to describe a pattern-factory
> pair, for example for the reasons you describe, but that's a separate
> abstraction to bind them together, not a property of the extractor.

yes.

Rémi

> 
> On 4/6/2018 2:59 PM, forax at univ-mlv.fr wrote:
>> You can extract the arity and the types from the array of components,
>> the arity is the number of components, the type is the return type of the method
>> type of each component.
>>
>> I agree that the primary constructor may not exist for all classes but for a
>> record, there is one,
>> and having the array of components and the constructor allows to do a full round
>> trip, object -> components -> object,
>> so you can build any serializations, the different kind of cloning (shallow or
> > not) on top of that.