[TYPES] RFC: ARF - An interprocedural flow-based type checker
David Foster
davidfstr at gmail.com
Fri Sep 11 00:55:53 EDT 2015
On 9/10/15, 1:48 AM, Gabriel Scherer wrote:
> I was not entirely satisfied with the complexity argument you provide.
> [...]
> However, this assumption that the corner cases cover all possible
> programs is not clear to me.
Indeed. This initial analysis is just a first approximation.
> In particular, the work of Christian Mossin on flow analysis seems
relevant.
Thanks! I will take a look.
On 9/10/15, 3:52 AM, Francois Pottier wrote:
> It may be worth noting that the paper "Constraint Abstractions" by
> J. Gustavsson and J. Svenningsson offers a pleasant, constraint-based
view of
> flow analysis and a significant improvement in complexity compared with
> Mossin's algorithm.
Thanks! I will also take a look.
On 9/10/15, 8:41 AM, hgualandi at inf.puc-rio.br wrote:
> I am not familiar with the Whiley language and with the references that
> Gabriel and François provided but I am familiar with some of the
> literature on type inference for dynamically typed languages. So here
> comes a bit of a brain dump of things from my masters...
Thank you Hugo. These references are extremely useful.
> On a cursory glance, the types you infer for Python are unions of base
> types. This reminds me of the Soft Typing work for Scheme, from the 90s.
Indeed: If you have "if { x = <int> } else { x = <bool> }; return x;",
the return type will be inferred as int|bool.
> One of the interesting
> features of soft typing systems is that by classifying operations
this way
> the output in case of a type error is more informative than just
saying "I
> failed to typecheck your program because some types didn't match".
That is encouraging to hear. Having extremely clear error messages from
the type checker is a very high priority for the larger type checker I'm
designing. (It's item #3 in the mission statement.)
> One thing that you should be aware of is that global type inference is
> very brittle, which is partly a reason why people have been moving on to
> Optional Typing and Gradual Typing for dynamic languages lately [8].
By brittle do you mean that small changes in the program source text can
easily cause large parts of the program to type differently? Or some
other property?
More information about the Types-list
mailing list