pattern matching refactoring: explicit types for record-expanded pattern heads#10089
pattern matching refactoring: explicit types for record-expanded pattern heads#10089Octachron wants to merge 1 commit intoocaml:trunkfrom
Conversation
|
I must say that I am a bit disheartened by the complexity of the result. To handle things fully statically, we have to move from a one-dimensional axis (half-simple -> simple) to two dimensions (simple or half-simple, expanded or not). The type structure is harder to read, and explicit coercions pop up in many new places. What would other compromises look like? A first idea would be to distinguish two constructors, |
|
A possible simplification axis would be to inline the expanded head type into a simplified head in |
| val to_omega_pattern : t -> pattern | ||
|
|
||
| val omega : t | ||
| val omega : expanded |
There was a problem hiding this comment.
Ah, we cannot do this because pattern heads are not polymorphic variants, yet.
| type nonexpanded_view = [ | ||
| | Simple.nonexpanded_view | ||
| | `Or of pattern * pattern * row_desc option | ||
| ] |
There was a problem hiding this comment.
Could the `Or constructor have its own type declaration to not repeat it twice in view and expanded_view?
During the review process of #9520, it appeared that we were repeatedly expanding record patterns of the form
{ x = _; _ }into{ x = _; y = _ }because it is not-so-straightforward to track which patterns had already been expanded in such way.This PR proposes to lift the distinction between record-expanded heads and non-expanded heads into the type system, and then fearlessly remove the redundant calls to
expand_record_headinlambda/matching.ml.