Just-In-Time Static Type Checking for Dynamic Languages

Re:Just-In-Time Static Type Checking for Dynamic Languages by munificent on Tuesday April 19, 2016 @06:07PM (#11530874)

It's somewhere between the two. Consider this program (in C-ish pseudocode):

    main() {
      foo();
    }

    foo() {
      if (false) {
        int i = "not an int";
      }
    }

    bar() {
      int j = "not an int";
    }

A statically typed language would report two type errors. A dynamically checked language would report none. Hummingbird would report one.

It gives a some of the benefits of static typing: it reports errors in code paths not hit through imperative branching. But it doesn't give all of it since it doesn't report errors in uncalled functions.

However, what it gives you in return is the ability to handle functions that don't even exist at program startup and are instead defined at runtime later in the program's execution through metaprogramming.

[ Parent | on HN ]

Re:Just-In-Time Static Type Checking for Dynamic Languages by MustardTiger on Wednesday April 20, 2016 @08:57AM (#11533994)

>Hummingbird would report one.

When?

>However, what it gives you in return is the ability to handle functions that don't even exist at program startup and are instead defined at runtime later in the program's execution through metaprogramming.

Those are already dynamically "type checked", how is this adding anything?

[ Parent | on HN ]

Re:Just-In-Time Static Type Checking for Dynamic Languages by munificent on Thursday April 21, 2016 @01:49PM (#11544007)

> When?

It would report the error in foo() when foo() is invoked, even though the code path containing the error is never executed.

> Those are already dynamically "type checked", how is this adding anything?

Only code paths that actually get executed are dynamically checked. This checks all code paths in the method.

[ Parent | on HN ]

Re:Just-In-Time Static Type Checking for Dynamic Languages by MustardTiger on Thursday April 21, 2016 @07:00PM (#11545937)

>It would report the error in foo() when foo() is invoked

That's "dynamic typing".

>Only code paths that actually get executed are dynamically checked. This checks all code paths in the method.

Ok, so it is extended dynamic typing. Why on earth is it being described as having anything to do with static typing?

[ Parent | on HN ]

Re:Just-In-Time Static Type Checking for Dynamic Languages by junke on Friday April 22, 2016 @03:09AM (#11547516)

Because it uses static analysis techniques, that's all. You type variables and consider all execution paths at once, instead of executing code and checking the types of values.

In particular, the code that was generated won't get executed if it can be proved beforehand that there is a type error.

I agree that in effect you won't get an error message until execution, but that does not mean that this is dynamic typing. Execution time and compile time are generally interleaved with metaprogramming so it can make sense to consider static-analysis for code at runtime.

What I found strange is the fact that it happens "Just-In-Time", which for me means at the last possible moment. This is counter-intuitive with what static typing aims to do. I would prefer "ASAP static-typing" (the code could be analyzed long before it is run).

That's why I still find the COMPILE approach of Lisp better, since we have precise control over when analysis is done.

[ Parent | on HN ]