Typically you wouldn't change the compiled code too much, it changes what is valid to type check and inserts casts as necessary. In general, flow typing just makes more programs type check.
You have to emit the plumbing for something like flow typing to work. You can't omit the type checking because you cannot account for all the possible call sites at compile time, that will lead to a combinatorial explosion. You do end up generating code to pass arguments with temporary type information.
Take the example of a variant type, which is what I'm most interested in.
You have something like type X = int32 | string | boolean | SomeCustomType
When you then write a function that accepts X as a type you need to be able to pass any of these things into that function. To do that you need a auto user defined type that can carry the information, in C that might look like this
struct {
union {
int a;
char* b;
boolean c;
} data;
Tag type,
}
then your type assertions can work on this. If you wrote this in my fancy language:
if x != nil {
// x cannot be nil here
x.foo
}
the equivalent C code for this would be something like
void f(X x) {
if (x.type != WELL_KNOWN_NIL) {
x.data.foo // we know it's safe to access foo (assuming we typed X as Foo | nil)
}
}
Trying to solve this at compile time without any runtime checks might be possible but I don't know that it would be better, it might be too slow if I have to solve some nasty combinatorial problems. This is at least somewhat easy to explain.
Take the example of a variant type, which is what I'm most interested in.
You have something like type X = int32 | string | boolean | SomeCustomType
When you then write a function that accepts X as a type you need to be able to pass any of these things into that function. To do that you need a auto user defined type that can carry the information, in C that might look like this
struct { union { int a; char* b; boolean c; } data; Tag type, }
then your type assertions can work on this. If you wrote this in my fancy language:
if x != nil { // x cannot be nil here x.foo }
the equivalent C code for this would be something like
void f(X x) { if (x.type != WELL_KNOWN_NIL) { x.data.foo // we know it's safe to access foo (assuming we typed X as Foo | nil) } }
Trying to solve this at compile time without any runtime checks might be possible but I don't know that it would be better, it might be too slow if I have to solve some nasty combinatorial problems. This is at least somewhat easy to explain.