Introduce application syntax for ADTs #1825
Merged
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.
Now that typechecking, pattern matching and core contracts are implemented for ADTs (enum variants), we switch from the temporary to the final syntax, which is just to use the same application syntax as for function application.
There was an unforeseen ambiguity: function argument patterns can be chained for multi-ary function, for example
fun {x,y} {z} => x + y + z
. This would clash with unparenthesized enum variants:fun 'Foo 'Bar =>
could be eitherfun ('Foo) ('Bar)
orfun ('Foo 'Bar)
.This PR chooses the first one: for a top-level function pattern argument, we only allow parenthesized enum variants such as
fun ('Foo 'Bar)
. Thusfun 'Foo 'Bar =>
is necessarilyfun ('Foo) ('Bar)
. The rationale being that it's more in line with other patterns, where each top-level space delimit function arguments, as infun x y
,fun {x} {y}
, etc.Doing so, we apply the same restriction to nested enum variants, to forbid patterns like
let 'Foo 'Bar 'Baz = x
, which could be parsed unambiguously as'Foo ('Bar 'Baz)
, but are quite confusing.