ADT destructuring

[yannham]

Depends on #1799

This PR adds support for ADTs (enum variants) in patterns. Patterns can currently only be used in destructuring, which isn't very useful for ADTs: you have to know the tag in advance to be able to actually destructure them. However, it's a first way to inspect enum variants, and a stepping stone toward full pattern matching as we will use the same notion (and the same Rust type in practice) for patterns in a match expression, and common implementations for type elaboration as well as the extraction code.

Content

• introduces three new primops to be able to desugar the new enum variant pattern (%enum_unwrap_variant%, %enum_is_variant%, %enum_get_tag%) as well as a new internal contract $enum_variant
• adds a pattern type for enum variants
• implements type elaboration for this new pattern
• implements desugaring of this new pattern to normal (non-destructuring) let bindings
• add tests

Follow-ups

• Add a pattern for enum tags (enum variants without argument). The reason it's not been done is that currently enum tags are probably better described as constant of the language, and that we can add constants all at once, to be able to match on numers, boolean and strings as well (it might become false if we introduce the Unit type and the () value)

[yannham]

for some reason we need the inline pragma to get LALRPOP to accept the grammar as non-ambiguous (it was suggested by LALRPOP error message itself).

[vkleen]

We're introducing a lot of differences between enum tags and aenum variants, and it makes me wonder if we shouldn't either allow something like [| 'Foo,, 'Foo Number |] or really go with the unit type route were discussing. But I think that's better addressed in another iteration on the idea.

[dpulls]

🎉 All dependencies have been resolved !

[yannham]

and it makes me wonder if we shouldn't either allow something like [| 'Foo,, 'Foo Number |] or really go with the unit type route were discussing. But I think that's better addressed in another iteration on the idea.

This is actually a very good point. We can go both routes (make them different, or make 'Foo x a supercase of 'Foo), but we should be consistent. If both constructs are really distinct, then they shouldn't conflict in a row type - they're almost like different dimensions, because you could match on 'Foo and 'Foo x without ambiguity.