Fix handling of wildcard match cases #1243
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
added 2 commits
November 10, 2023 11:24
We had been using thunks, lambdas that take no arguments, to encode the
eliminators for wildcard match cases. I.e., the match expression
```
match foo {
| _ => bar
}
```
Was being converted into our builtin exotic thus:
```
matchVariant(foo, "_", () => bar)
```
This made sense because in the case of the wildcard match we are
discarding the variant, and there is no argument to be supplied to the
eliminator.
However:
1. We don't really support nullary lambdas (even tho we are making use
of them at several places in our code currently).
2. Since we are committed to using the exotic builtin operators, and there
is no way to specify the effect of a variadic builtin with unpredictable
arguments, we could not give this builtin the correct effect signature.
So I have changed the way wildcard cases are encoded, to also use unary
lambas that just ignore their argument. This simplifies a lot of the
match typing and evaluation, so it is the right call overall.
|
After this is in, I'll write a more extensive series of tests using the constructs, along with documentation and release notes announcing the feature. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This is a followup to #1242 and #1232.
While the preceding gave basic support for sum type constructors and
eliminators, we did not have support for properly typing "wildcard" or default
match cases.
This PR simplifies the representing and logic around such cases and extends the
constraint generator to give the correct typing for match expressions that
include a default case.
The gist:
A match expression of the form
Is now typed to apply to a variant
<A : t, B : u | v >wherevis an freerow variable. The open row accounts for the fact that the wildcard handles the
rest of the labels, whatever they may be.
The constraint generator is also expanded with error handling to catch cases
where redundant wildcard's or match statements are included.
CHANGELOG.mdfor any new functionalityREADME.mdupdated for any listed functionality