Commit 9ac0c7f0 authored by Giuseppe Castagna's avatar Giuseppe Castagna
Browse files

typo

parent 48fbf168
......@@ -911,17 +911,18 @@ non standard type-environments that map expressions rather than
variables to types. But all the rest is standard type-theory (and we
are confident that we can get rid also of the few last non-standard
features). Compare now this with existing work. The work of Typed
Racket does a really good job in giving a foundation to occurrence typing,
but still it uses types with logical predicates and pointers to type
environments (the latter akin to what we do), and tailors its analysis to a
predefined set of pure expressions and to truthy and false
results. But, hands down, it works on a real widely used programming
language. Flow and TypeScript are amazing industrial implementations
that are based on strong theoretical foundation but they are far from
providing any foundation to this research: it happened more than once
that we found some examples that our work captured and on which
TypeScript and Flaw failed and that after a couple of months were fixed
and magically worked in one or the other.
Racket does a really good job in giving a foundation to occurrence
typing, but still it uses types with logical predicates and pointers
to type environments (the latter akin to what we do), and tailors its
analysis to a predefined set of pure expressions and to truthy and
false results. But, hey, it works on a real widely used programming
language with a large base of existing code. Flow and TypeScript are
amazing industrial implementations that are based on strong
theoretical foundation but they are far from providing any foundation
to this research: it happened more than once that we found some
examples that our work captured and on which TypeScript and Flaw
failed and that after a couple of months were fixed and magically
worked in one or the other.
\end{answer}
Finally, the implementation section makes me think that the flow
......@@ -940,7 +941,7 @@ function types which are intersections of arrow types?)
that comes from the context of a type-case is thus lost. But if we
can apply occurrence typing also on other expressions, by splitting
the types of these expressions not only because they are tested by a
type-case but also because it is interesting to do it then we would
type-case but also because this yields more precise types, then we would
have solved the problem. We are pretty confident that we can have it
within a pure type-theoretic approach, without resorting to flow
analysis. We are currently working on it.
......
Markdown is supported
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment