Type synonyms #1865
Merged
Type synonyms #1865
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
byorgey
force-pushed
the
feature/type-synonyms
branch
from
7eb5f52 to
d72bf4f
Compare
mergify bot
pushed a commit
that referenced
this pull request
May 28, 2024
Splitting out an independent refactoring to simplify #1865. There were many places in the code where we were pattern-matching on `ProcessedTerm` and/or `Module`, sometimes only to extract a single field, *e.g.* ``` ProcessedTerm (Module s _) _ _ <- maybeInitialCode ``` This was already getting a bit out of hand, and it also meant that any time we wanted to add an extra field to either `ProcessedTerm` or `Module` (as I will be doing in #1865), we would have to change every single such place in the code to add an extra wildcard pattern. This PR is a refactoring to 1. Derive lenses for all the fields of `ProcessedTerm` and `Module`, and 2. Prefer extracting named fields via lenses over pattern-matching in most places in the code. There were a few places in the code where we destructure a `ProcessedTerm` and use almost all the fields (e.g. when initializing a robot machine); I left those alone, first because extracting all the individual fields would be tedious, but more importantly because if we ever added any new fields in the future, it's likely we would actually want to use them in those contexts as well.
byorgey
force-pushed
the
feature/type-synonyms
branch
from
d72bf4f to
d4c3e96
Compare
mergify bot
pushed a commit
that referenced
this pull request
May 28, 2024
There were a bunch of fused-effects related utils that lived in a module in `swarm-scenario`; but all of them were completely generic except for the `simpleErrorHandle` function which is specific to `SystemFailure`. So, this PR: - Moves `simpleErrorHandle` to `Swarm.Game.Failure` - Moves the rest of the module into the `swarm-util` package so it can be used elsewhere. This is another refactoring in preparation for #1865.
mergify bot
pushed a commit
that referenced
this pull request
May 28, 2024
We used to represent types with a different constructor for each different sort of type, e.g. there was a constructor `TyFunF` which took two types as arguments, etc. This refactoring creates a new type `TyCon` which has things like `TCFun` and `TCBase` and represents various types as an application of a `TyCon` to some arguments. For example function type `t1 -> t2` would be represented no longer as `TyFunF t1 t2` but instead as `TyConApp TCFun [t1, t2]`. This is slightly more roundabout, and it does make parsing slightly trickier, but it greatly simplifies and shortens code for e.g. unification, extracting free variables, etc. (because what used to be many essentially identical cases now turn into a single case). It also paves the way for #1865, so we have a way to represent new type constructors defined by the user. E.g. if the user defined `tydef Maybe a = Unit + a` then we would represent the type `Maybe Int` as something like `TyConApp (TCUser "Maybe") [TyBase BInt]`. This also means that types like `Int Unit` are no longer a parse error, so we need kind checking to rule out applications of type constructors to the wrong number of arguments; this PR adds such kind checking as well. Having some sort of kind checking is unavoidable when allowing the user to define their own new type constructors (with an arbitrary number of arguments).
byorgey
force-pushed
the
feature/type-synonyms
branch
3 times, most recently
from
4d5d738 to
1a4874a
Compare
byorgey
force-pushed
the
feature/type-synonyms
branch
from
1a4874a to
6d002f5
Compare
byorgey
commented
Jun 1, 2024
| @@ -1,4 +1,4 @@ | |||
| syn keyword Keyword def end let in require | |||
| syn keyword Keyword def tydef end let in require | |||
There was a problem hiding this comment.
I wanted to update the vscode configuration as well but wasn't sure of the right way to do it --- @kostmo?
There was a problem hiding this comment.
I guess it's here, but I'm not acquainted with the mechanics:
There was a problem hiding this comment.
Oh, OK, no worries, for some reason I thought you had created the VSCode configuration, but I see now I was misremembering. I'll create an issue for it: #1887 .
kostmo
approved these changes
Jun 1, 2024
byorgey
added
the
CHANGELOG
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.
Adds type synonym declarations to the language, like so:
tydefbehaves very similarly todefexcept that it defines a new (parameterized) type instead of a new term.Note that higher-kinded types are not yet supported; for example we cannot say
tydef Foo f = Unit + f Int(in fact this would be a syntax error since type variables cannot be at the head of an application). However there is nothing stopping us from adding that in the future; I just wanted to keep things simple for now.If you know of any scenario code that would be a good candidate for using type synonyms, let me know --- it would be nice to update a few scenarios as a better stress test of type synonyms before merging this.
Closes #153.