Shallow type inference #273
Conversation
|
🎉 All dependencies have been resolved ! |
yannham
force-pushed
the
feature/shallow-type-inference
branch
from
00a1456
to
b97568f
Compare
src/typecheck.rs
Outdated
| // If there are interpolated expressions inside a string, we can't guarantee that this is a | ||
| // well-typed string (e.g. "#{1 + 1}" is not). We can only do so if all chunks are string | ||
| // literals. |
There was a problem hiding this comment.
But isn't it guaranteed that if it is well-typed (dynamically), then it is a string? In which case it's fine to return the string type in all cases.
There was a problem hiding this comment.
My rule of thumb was that it shouldn't infer a precise (Exact) type for an expression that wouldn't pass the typechecker, that is if apparent_type(e) = exact(T) then e : T must be well-typed. But "#{1 + 1} : Str is not well-typed.
That said, the semantics of interpolated string enforce that such expressions either fails with a type error or evaluate to a string at run-time indeed. So let's return Str in all cases then.
There was a problem hiding this comment.
Note that this rule already didn't apply to the Assume case. The only thing that you need of a type, in this gradual type context, is that if the expression doesn't blame, then it has this type (with a fairly strong notion of “doesn't blame”).
src/typecheck.rs
Outdated
| Term::StrChunks(chunks) if chunks.iter().all(is_literal) => { | ||
| ApparentType::Exact(Types(AbsType::Str())) | ||
| } | ||
| Term::List(_) => ApparentType::Exact(Types(AbsType::List(Box::new(Types(AbsType::Dyn()))))), |
There was a problem hiding this comment.
It's a little bit weird to call this case Exact isn't it?
There was a problem hiding this comment.
Yeah, it was in opposition to Approximated. Maybe Precise, or Inferred?
Depend on #272. Address #139. Determine the type of some unannotated let-bound expressions outside of statically typed code:
List Dyntype.what this PR doesn't do
Dyn -> Dyn). It's not clear in what practical situation you would actually need it. If needed, we can do add this later.{_ : Dyn}and{ | Dyn}, but this is maybe a sign that this a problem with the type system's definition, rather than with inferring the type of records.