Add static typechecker #26
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
ruuda
force-pushed
the
types
branch
2 times, most recently
from
e663d6e to
df73db2
Compare
ruuda
force-pushed
the
types-static
branch
6 times, most recently
from
b19c00a to
8c5d83e
Compare
Merged
ruuda
force-pushed
the
types-static
branch
3 times, most recently
from
dcfacbb to
327da58
Compare
|
Some learnings from the past two days: I wasn’t so happy with the messy and verbose ways the typechecker was implemented, having to check for |
ruuda
force-pushed
the
types-static
branch
5 times, most recently
from
5a6bd84 to
96e8952
Compare
ruuda
force-pushed
the
types-static
branch
3 times, most recently
from
7144717 to
8854d06
Compare
I thought of this case after writing it yesterday. Especiall an arity error can occur, and by default we don't add a call frame, so then replacing may be dangerous if there was a different frame on the stack already. Though now that I'm writing this, I don't think that case can happen.
This is only moving things around (and altering some doc comments), no functional changes.
The previous cases that covered these are now caught statically by the typechecker, but we can sidestep that with an Any annotation.
Now that the typechecker can determine whether something is a dict or set (or list) literal, we can use that information in the evaluator. The complexity moved to the typechecker already, so now we reap the benefits and simplify the evaluator. In fact there is another opportunity to simplify the evaluator further by eliminating the SeqOut type entirely, but I'll do that in a follow-up commit. The SeqOut served its purpose though, because the typechecker is based on it.
Now that the evaluator knows what kind of collection to expect, because of the typechecker, we no longer need to carry this runtime SeqOut thing around and match on it all the time. We can work with closures instead! This has more advantages: * We don't build up vecs of keys and values when we build a dict, we can build the dict directly. * Same for sets. * Maybe LLVM will even inline stuff? * If I want to do the unique dicts that deny duplicate keys, that is now much easier too. Just return an error from on_assoc. But performance aside (which I really don't know if it matters, I haven't measured), this mainly simplifies the logic, even though the length of the code is about the same.
Some code in the evaluator where I previously had a to do because of typechecks is now resolved!
We will likely have at least as many elements as syntactic elements. (This is not always the case, you could have "if", but that would be silly, I don't expect it to be common.) You can have many more with loops, but for large (or even small) lists of static size, this could help to avoid a few reallocations and not waste so much excess. (But then the growth could create more excess ...)
Still not supported. Maybe just implementing it is less work ...
Some of these are now no longer runtime errors but static errors.
I think I accidentally moved it there when refactoring the type modules.
Also include a shorter version of the type name in messages now.
No, I don't want to admit "_" as a type name. When we still had "Dynamic", then yes that was too verbose. But "Any" is fine, we don't need "_". There should be one -- and preferably only one -- obvious way to do it. That way was not obvious to me at first though even though I'm Dutch.
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.
Description
This pull request grew waaaay too big. I should have broken it up earlier, but I failed to do so and it became hard to break up because everything is entangled.
Anyway, this adds a static typechecker. The final diff for this pull request is my third attempt at it. I started out pushing down expectations and inferring bottom-up, but it was messy, and I got stuck on functions. Then I switched to having different Rust types for expected types and inferred types, and that worked very well, I implemented it almost all the way — until I got to function arguments, where the expectation and actual type are reversed due to function types being contravariant in the arguments. So that entire approach was a dead end, back to having one
Typetype it was. But it helped to clarify the type lattice, and the handling of the subtype check (return aDeferif we want a runtime check). It also inspired tracking sources of types, which enables clarifications in error messages.To do
runtime_for whether they should be renamed totypecheck_.TODOs and see if they need to be resolved.