Setting the context

Our aim is to evolve ActionScript into a safe and efficient programming language.

There’s a lot to do.

ActionScript Language Specification
(Because you can’t improve something you don’t understand.)
ActionScript is the core scripting language in which Flash applications are developed. While its roots lie in JavaScript, there are several features in ActionScript that go beyond JavaScript (e.g., class-based inheritance, namespaces, strict-mode compilation, application domains). Unfortunately, the only “specification” of ActionScript has been its implementation, which means that some aspects of the language remain arcane, and any bugs in the implementation cause backward-compatibility problems. We are working on a rigorous definitive specification of the syntax and semantics of ActionScript programs.

Gradual Type Inference for ActionScript
(Because if you have something, it should really count.)
ActionScript enforces a combination of static and dynamic checks on programs, but it is unclear what such checks guarantee. Furthermore, there is no type inference in ActionScript. We are working towards a new gradual type system for ActionScript with the following main design intentions: (1) reconciling type inference with static types (annotations) and the dynamic type (*) via the notion of “unsafe” code regions; (2) providing meanings to types via a combination of static and dynamic checks that provably restrict runtime errors to unsafe code regions; and (3) optimizing code by eliminating dynamic checks wherever they are subsumed by static checks.

6 Responses to Setting the context

  1. Frédéric THOMAS says:

    Hi Avik,

    From the beginig of the last year you started to share few articles about “various thoughts on language design, implementation, and evolution”.

    Almost now, one year after, What’s up ?

    1- What about Type Inference, will it be implemented ?
    2- What about “rigorous definitive specification of the syntax and semantics of ActionScript” ?
    3- And at the end, what’s the news ?

  2. Avik Chaudhuri says:

    Hi Frédéric,

    Rest assured that the lethargy in blog updates does not reflect what has been going on in the past year. Very exciting progress, will share most of it in new blog posts this week.

    In brief, we did some cutting-edge research on type inference for AS; our work will be published in POPL 2012 (premier programming language research conference). We have implemented type inference in Falcon (the next-gen AS compiler), with awesome results. The spec work has been completed for all the main chapters. We are looking ahead at significant and bold revisions to AS to make it much much faster, and the best language to write games in. So much to look forward to in the next year or so!

  3. Frédéric THOMAS says:

    Thank you for your quick answer, that’s really encouraging and I’m in a hurry to see Falcon compiling my projects.

    Today, we were talking about implementing method overloading and how it could be problematic in some situations, like 2 methods named ‘test’ using Numbers for the first one and uint for the second one and I thought, maybe type inference could solve the problem, what do you think ?

  4. Frédéric THOMAS says:

    A more complete example :

    interface IA
    function foo(s:String):void;

    interface IB
    function foo(i:int):void;

    class AB implements IA, IB
    public function foo(s:String):void {}
    public function foo(i:int):void {}
    public function foo(u:uint):void {}
    public function foo(n:Number):void {}
    public function foo(o:Object):void {}

    class TestAB
    public function testFoo():void
    var ab:AB = new AB();;;

    Then there are runtime problems:

    class TestIA
    public function testFoo():void
    var ab:AB = new AB();
    callFoo(ab, “”);

    var name:String = “foo”;
    ab.foo_String_void() ?

    private function callFoo(reference:IA, value:String):void

    beside the fact 2 methods of the same name are not allowed in interfaces, can all of these cases be resolved by type inference ?

  5. Avik Chaudhuri says:

    Method overloading is not directly related to type inference; the main benefit of type inference is that it relieves the programmer from writing type annotations (you can omit types when you declare variables, functions, etc.) while still gaining the performance benefits of fully typed code.

    Method overloading works only when you can unambiguously resolve the method you are calling (some languages have static restrictions to ensure that you can, but other languages may just throw a run time error.) In your examples, only the call is unambiguous. Most of the others are ambiguous (e.g., 1 is both an int and uint, and the two types are incomparable; null belongs to both Object and String). Resolving these calls in an ad hoc way would be a bad design choice.

    But yes, overall type inference should be able to figure out what method signature is being targeted, and whether the call can be resolved unambiguously at run time.

  6. Frédéric THOMAS says:

    Thank you very much once again for your answer Avik.