hg: amber/amber: hooking records to patterns

[Brian Goetz]

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.

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.

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.