Closed DavePearce closed 7 years ago
Right, some further points after a little bit of investigation:
The theorem prover itself is quite happy handling flow typing. Disable the type checker, and the above all pass.
This certainly makes me ponder whether or not the type checker is actually needed. Some mitigating factors:
getReturnType()
.Overall, hmmm...
... I suppose we could introduce an interface for expression typing. Say, ExpressionTyper
or TypeInference
?
One of the advantages here is that getReturnType(TypeSystem)
currently has that ugly parameter (which is necessary for extracting readable array types, etc) and we could get rid of it. A TypeInference
could then be part of a TypeSystem
perhaps?
Another advantage here is that TypeInference
instances could be composable in some way ...
Currently, the type checker does not support flow typing. For example, this fails to type check:
In principle, the theorem prover can handle this easily enough. But, its not even getting passed the type checker right now.
The key question is where do we resolve this in
TypeChecker
? Some observations:TypeChecker
determines its type usingExpr.getReturnType()
which, for a variable access, returns the type given by the correspondingVariableDeclaration
.WyalFileParser
is responsible for connectingVariableAccess
expressions withVariableDeclaration
s.In principle, we could update
WyalFileParser
to be flow sensitive and to introduce someAliasDeclarations
as it encounters them (i.e. when it seesx is int
). The problem is how it determines what the appropriate type for the alias declaration is. An easy example:When
i is int
is encountered then we create an alias declaration. But, what about here:Ok, it can determine the alias declaration as
i is !null
if it tracks the sign. What about this case:Perhaps it works if the type checker just views it as this (again by tracking sign):
These cases are all one reason why we separated variables out into their "versions", in order that those version can be typed differently according to their usage.