30 research outputs found

    Path-sensitive Type Analysis with Backward Analysis for Quality Assurance of Dynamic Typed Language Code

    Full text link
    Precise and fast static type analysis for dynamically typed language is very difficult. This is mainly because the lack of static type information makes it difficult to approximate all possible values of a variable. Actually, the existing static type analysis methods are imprecise or slow. In this paper, we propose a novel method to improve the precision of static type analysis for Python code, where a backward analysis is used to obtain the path-sensitivity. By doing so, our method aims to obtain more precise static type information, which contributes to the overall improvement of static analysis. To show the effectiveness of our method, we conducted a preliminary experiment to compare our method implementation and the existing analysis tool with respect to precision and time efficiency. The result shows our method provides more precise type analysis with fewer false positives than the existing static type analysis tool. Also it shows our proposed method increases the analysis time, but it is still within the range of practical use.Comment: 9 pages with 6 figure

    Blame Tracking and Type Error Debugging

    Get PDF
    In this work, we present an unexpected connection between gradual typing and type error debugging. Namely, we illustrate that gradual typing provides a natural way to defer type errors in statically ill-typed programs, providing more feedback than traditional approaches to deferring type errors. When evaluating expressions that lead to runtime type errors, the usefulness of the feedback depends on blame tracking, the defacto approach to locating the cause of such runtime type errors. Unfortunately, blame tracking suffers from the bias problem for type error localization in languages with type inference. We illustrate and formalize the bias problem for blame tracking, present ideas for adapting existing type error debugging techniques to combat this bias, and outline further challenges

    Do Machine Learning Models Produce TypeScript Types That Type Check?

    Get PDF
    Type migration is the process of adding types to untyped code to gain assurance at compile time. TypeScript and other gradual type systems facilitate type migration by allowing programmers to start with imprecise types and gradually strengthen them. However, adding types is a manual effort and several migrations on large, industry codebases have been reported to have taken several years. In the research community, there has been significant interest in using machine learning to automate TypeScript type migration. Existing machine learning models report a high degree of accuracy in predicting individual TypeScript type annotations. However, in this paper we argue that accuracy can be misleading, and we should address a different question: can an automatic type migration tool produce code that passes the TypeScript type checker? We present TypeWeaver, a TypeScript type migration tool that can be used with an arbitrary type prediction model. We evaluate TypeWeaver with three models from the literature: DeepTyper, a recurrent neural network; LambdaNet, a graph neural network; and InCoder, a general-purpose, multi-language transformer that supports fill-in-the-middle tasks. Our tool automates several steps that are necessary for using a type prediction model, (1) importing types for a project's dependencies; (2) migrating JavaScript modules to TypeScript notation; (3) inserting predicted type annotations into the program to produce TypeScript when needed; and (4) rejecting non-type predictions when needed. We evaluate TypeWeaver on a dataset of 513 JavaScript packages, including packages that have never been typed before. With the best type prediction model, we find that only 21% of packages type check, but more encouragingly, 69% of files type check successfully.Comment: Published at the 37th European Conference on Object-Oriented Programming (ECOOP 2023

    Set-theoretic Types for Erlang

    Full text link
    Erlang is a functional programming language with dynamic typing. The language offers great flexibility for destructing values through pattern matching and dynamic type tests. Erlang also comes with a type language supporting parametric polymorphism, equi-recursive types, as well as union and a limited form of intersection types. However, type signatures only serve as documentation, there is no check that a function body conforms to its signature. Set-theoretic types and semantic subtyping fit Erlang's feature set very well. They allow expressing nearly all constructs of its type language and provide means for statically checking type signatures. This article brings set-theoretic types to Erlang and demonstrates how existing Erlang code can be statically typechecked without or with only minor modifications to the code. Further, the article formalizes the main ingredients of the type system in a small core calculus, reports on an implementation of the system, and compares it with other static typecheckers for Erlang.Comment: 14 pages, 9 figures, IFL 2022; latexmk -pdf to buil

    Static Typing of Complex Presence Constraints in Interfaces

    Get PDF
    Many functions in libraries and APIs have the notion of optional parameters, which can be mapped onto optional properties of an object representing those parameters. The fact that properties are optional opens up the possibility for APIs and libraries to design a complex "dependency logic" between properties: for example, some properties may be mutually exclusive, some properties may depend on others, etc. Existing type systems are not strong enough to express such dependency logic, which can lead to the creation of invalid objects and accidental usage of absent properties. In this paper we propose TypeScriptIPC: a variant of TypeScript with a novel type system that enables programmers to express complex presence constraints on properties. We prove that it is sound with respect to enforcing complex dependency logic defined by the programmer when an object is created, modified or accessed

    Parametric Denotational Semantics for Extensible Language Definition and Program Analysis

    Full text link
    We present a novel approach to construction of a formal semantics for a programming language. Our approach, using a parametric denotational semantics, allows the semantics to be easily extended to support new language features, and abstracted to define program analyses. We apply this in analysing a duck-typed, reflective, curried dynamic language. The benefits of this approach include its terseness and modularity, and the ease with which one can gradually build language features and analyses on top of a previous incarnation of a semantics
    corecore