feat: implement corset type checker #431
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
DavePearce
force-pushed
the
393-implement-corset-type-checker
branch
3 times, most recently
from
596b311 to
25e6c0e
Compare
This adds a small number of valid and invalid tests for checking typing.
Whilst this is a fairly esoteric part of the corset language, it is nevertheless necessary to implement in order to faithly recreate the language's semantics.
This puts in place a fairly primitive form of type inference, which doesn't really do anything at this time. However, most of the machinery is now in place...
This puts in place the ability to resolve an if as either an if-zero or an if-notzero depending on whether the condition is loobean or boolean. In the case that it is neither, then an error is reported. At this stage, however, the mechanism for infering the type of an arbitrary expression remains somewhat limited.
This adds support for checking that guards have boolean semantics. For now, checking constraints have loobean semantics is implemented but not enabled. The problem is that it breaks a lot of the existing tests!
This fixes a number of tests which have been broken as a result of the introduced type checking process. The biggest issue here is that we really need the ability to put return types on functions in order to resolve some situations.
This adds support for function return types, and updates a larger number of tests to use "vanishes!" to meet the loobean requirements for a constraint. This also relaxes the rules for combining types for addition and subtraction, following what corset does. In addition, this introduces a very minimal standard library which (at this time) includes only the "vanishes" declaration.
This reworks the memory example so that it now: (a) compiles; (b) makes use of the stdlib (what there is of it) to improve the overall look. There is an outstanding issue related to the return types of functions. Specifically, it seems that corset infers the return type when it is not specified.
This puts in place a naive algorithm for type inference of function invocations. Its somewhat awkward, but it reflects the original corset language.
The corset language supports an interesting notion of type inference in the case that a function is declared without an explicit return type being given. Specifically, it types it polymorphically at the call site based on the types of the given arguments.
This fixes some problems with the existing finalisation algorithm. Firstly, it was sometimes finalising things more than once (which is wasteful). Secondly, it was not finalising at a fine-enough granularity (which caused problems for constant definitions which referred to themself). Finally, there were still some gremlins related to binding.
This puts through various minor fixes for the quick tests. What remains now is to update the larger tests. At this stage, performance may be starting to become an issue.
This pulls over as much of the original corset standard library as possible at the moment (which is actually most of it). There are a couple of outstanding issues to be resolved around overloading, etc.
This updates the slow test to be almost exactly as they were original defined (i.e. using the full corset syntax). At this stage, there are a number of outstanding issues which remain, and some of the tests have parts commented out.
DavePearce
force-pushed
the
393-implement-corset-type-checker
branch
from
da9b1fe to
404a7eb
Compare
This adds another test case, and fixes a minor issue with the memory example.
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 puts in place a relatively minimal type checker. There is more to do to flesh this out, but the fundamental mechanisms are in place.