Automated Sized-Type Inference and Complexity Analysis

TL;DR

This paper presents an automated methodology for size-type inference and complexity analysis of higher-order functional programs, combining advanced type systems, transformations, and constraint solving, capable of handling complex examples.

Contribution

It introduces a fully automated approach with an abstract index language and index polymorphism, enabling analysis of complex higher-order programs beyond existing methods.

Findings

Successfully analyzes complex higher-order programs

Automated process reduces manual effort

Prototype implementation demonstrates practical applicability

Abstract

This paper introduces a new methodology for the complexity analysis of higher-order functional programs, which is based on three components: a powerful type system for size analysis and a sound type inference procedure for it, a ticking monadic transformation and a concrete tool for constraint solving. Noticeably, the presented methodology can be fully automated, and is able to analyse a series of examples which cannot be handled by most competitor methodologies. This is possible due to various key ingredients, and in particular an abstract index language and index polymorphism at higher ranks. A prototype implementation is available.

Equations

$$\mathtt{twice}\mathrel{::}\forall i.\ ({{\color[rgb]{0,0.3,0}\definecolor[named]{pgfstrokecolor}{rgb}{0,0.3,0}{{\mathtt{Nat}}}}}_{i}\to{{\color[rgb]{0,0.3,0}\definecolor[named]{pgfstrokecolor}{rgb}{0,0.3,0}{{\mathtt{Nat}}}}}_{i+1})\to{{\color[rgb]{0,0.3,0}\definecolor[named]{pgfstrokecolor}{rgb}{0,0.3,0}{{\mathtt{Nat}}}}}_{i}\to{{\color[rgb]{0,0.3,0}\definecolor[named]{pgfstrokecolor}{rgb}{0,0.3,0}{{\mathtt{Nat}}}}}_{i+2}\hbox to0.0pt{$\;$,\hss}$$

$$\mathtt{twice}\mathrel{::}\forall i.\ (\forall j.{{\color[rgb]{0,0.3,0}\definecolor[named]{pgfstrokecolor}{rgb}{0,0.3,0}{{\mathtt{Nat}}}}}_{j}\to{{\color[rgb]{0,0.3,0}\definecolor[named]{pgfstrokecolor}{rgb}{0,0.3,0}{{\mathtt{Nat}}}}}_{j+1})\to{{\color[rgb]{0,0.3,0}\definecolor[named]{pgfstrokecolor}{rgb}{0,0.3,0}{{\mathtt{Nat}}}}}_{i}\to{{\color[rgb]{0,0.3,0}\definecolor[named]{pgfstrokecolor}{rgb}{0,0.3,0}{{\mathtt{Nat}}}}}_{i+2}\hbox to0.0pt{$\;$.\hss}$$

$$\mathtt{foldr}{\,:\,}(\forall i.\ \alpha\to{{\color[rgb]{0,0.3,0}\definecolor[named]{pgfstrokecolor}{rgb}{0,0.3,0}{{\mathtt{List}}}}}_{i}\ \beta\to{{\color[rgb]{0,0.3,0}\definecolor[named]{pgfstrokecolor}{rgb}{0,0.3,0}{{\mathtt{List}}}}}_{i+j}\ \beta)\to{{\color[rgb]{0,0.3,0}\definecolor[named]{pgfstrokecolor}{rgb}{0,0.3,0}{{\mathtt{List}}}}}_{k}\ \beta\to{{\color[rgb]{0,0.3,0}\definecolor[named]{pgfstrokecolor}{rgb}{0,0.3,0}{{\mathtt{List}}}}}_{m}\ \alpha\to{{\color[rgb]{0,0.3,0}\definecolor[named]{pgfstrokecolor}{rgb}{0,0.3,0}{{\mathtt{List}}}}}_{m\cdot j+k}\ \beta\hbox to0.0pt{$\;$;\hss}$$

$$\tau ,\rho ,\xi ::=$$

$$s,t::=$$

$$p,q::=$$

$$u,v::=$$

$$\displaystyle a,b\mathrel{::=}{}i\mid\mathsf{f}(a_{1},\dots,a_{\operatorname{\mathsf{ar}}(\mathsf{f})})\hbox to0.0pt{$\;$.\hss}$$

$$\tau ,\zeta ::=$$

$${\mathtt{B}}_a{⊑}_{\mathcal{J}}{\mathtt{B}}_{b}a{\le }_{\mathcal{J}}b{\rho }_{\_}1\to {\tau }_{\_}1{⊑}_{\mathcal{J}}{\rho }_{\_}2\to {\tau }_{\_}2\text{lx@proof@logical@and}{\rho }_{\_}2{⊑}_{\mathcal{J}}{\rho }_{\_}1{\tau }_{\_}1{⊑}_{\mathcal{J}}{\tau }_{\_}2\forall \vec{i}.{\tau }_{\_}1{⊑}_{\mathcal{J}}{\rho }_{\_}2\text{lx@proof@logical@and}{\rho }_{\_}2\text{⋅}⩾{\tau }_{\_}2{\tau }_{\_}1{⊑}_{\mathcal{J}}{\tau }_{\_}2\vec{i}\notin \mathrm{FVar}({\rho }_{\_}2)$$

$$\Gamma ,x:\rho {⊢}^{\mathcal{J}}x:\tau \rho \text{⋅}⩾\tau \Gamma {⊢}^{\mathcal{J}}s:\tau \text{lx@proof@logical@and}s\in \mathcal{F}\cup \mathcal{C}s::\rho \rho \text{⋅}⩾\tau$$

$$\Gamma {⊢}^{\mathcal{J}}st:\tau \text{lx@proof@logical@and}\Gamma {⊢}^{\mathcal{J}}s:(\forall \vec{i}.{\zeta }_{\_}1)\to \tau \Gamma {⊢}^{\mathcal{J}}t:{\zeta }_{\_}2{\zeta }_{\_}2{⊑}_{\mathcal{J}}{\zeta }_{\_}1\vec{i}\notin \mathrm{FVar}(\Gamma {\upharpoonright }_{\mathrm{FVar}(t)})$$

$$\varnothing {⊢}_{\mathsf{FP}}\mathtt{f}:\tau \mathtt{f}::\forall \vec{i}.\tau \Gamma \uplus \{x:\rho \}{⊢}_{\mathsf{FP}}tx:\tau \Gamma {⊢}_{\mathsf{FP}}t:\rho \to \tau$$

$$\Gamma_{\_}1\uplus\Gamma_{\_}2\vdash_{\mathsf{FP}}s\ t\mathrel{:}\tau\{a/i\}\begin{array}[]{c}(\operatorname{\mathsf{FVar}}(\Gamma_{\_}1)\cup\operatorname{\mathsf{FVar}}(\tau))\cap(\operatorname{\mathsf{FVar}}(\Gamma_{\_}2)\cup\operatorname{\mathsf{FVar}}({{\mathtt{B}}}_{a}))=\varnothing\\ \Gamma_{\_}1\vdash_{\mathsf{FP}}s\mathrel{:}{{\mathtt{B}}}_{i}\to\tau\qquad\Gamma_{\_}2\vdash_{\mathsf{FP}}t\mathrel{:}{{\mathtt{B}}}_{a}\qquad s\not\in\mathcal{X}\end{array}$$

$$\Gamma {⊢}_{\mathsf{FP}}l:\tau ⟹\Gamma {⊢}^{\mathcal{J}}r:\zeta \text{ for some monotype ζ with ζ⊑Jτ,}$$

Full text

1 Introduction

One successful approach to automatic verification of termination properties of higher-order functional programs is based on sized types [9]. In sized types, a type carries not only some information about the kind of each object, but also about its size, hence the name. This information is then exploited when requiring that recursive calls are done on arguments of strictly smaller size. Estimating the size of intermediate results is crucial for complexity analysis, but up to now, the only attempt of using sized types for complexity analysis is due to Vasconcelos [11], and confined to space complexity. If one wants to be sound for time analysis, size types need to be further refined, e.g., by turning them into linear dependently types [6].

Since the first inception in the seminal paper of Hughes et. al. [9] the literature on sized typed has grown to a considerable extend. Indeed, various significantly more expressive systems have been introduced, with the main aim to improve the expressiveness in the context of termination analysis. For instance, Blanqui [5] introduced a novel sized type system on top of the calculus of algebraic construction. Notably, it has been shown that for size indices over the successor algebra, type checking is decidable [5]. The system is thus capable of expressing additive relations between sizes. In the context of termination analysis, where one would like to statically detect that a recursion parameter decreases in size, this is sufficient. In this line of research falls also more recent work of Abel and Pientka [2], where a novel sized type system for termination analysis on top of $\mathsf{F}_{\_}\omega$ is proposed. Noteworthy, this system has been integrated in the dependently typed language Agda.111See http://wiki.portal.chalmers.se/agda.

As we will see, capturing only additive relations between value sizes is not enough for our purpose. On the other hand, even slight extensions to the size index language render current methods for type inference, even type checking, intractable. In this paper, we thus take a fresh look at sized-type systems, with a particular emphasis on a richer index language and feasible automation on existing constraint solving technology. Our system exhibits many similarities with the archetypal system from [9], which itself is based on a Hindley-Milner style system. Although conceptually simple, our system is substantially more expressive than the traditional one. This is possible mainly due to the addition of one ingredient, viz, the presence of arbitrary rank index polymorphism. That is, functions that take functions as their argument can be polymorphic in their size annotation. Of course, our sized type system is proven a sound methodology for size analysis. In contrast to existing works, one can also device an inference machinery that is sound and (relative) complete. Finally, this system system is amenable to time complexity analysis by a ticking monadic transformation. A prototype implementation is available, see below for more details. More specifically, our contributions can be summarized as follows:

• –

We show that size types can be generalised so as to encompass a notion of index polymorphism, in which (higher-order subtypes of) the underlying type can be universally quantified. This allows for a more flexible treatment of higher-order functions. Noticeably, this is shown to preserve soundness (i.e. subject reduction), the minimal property one expects from such a type system. On the one hand, this is enough to be sure that types reflect the size of the underlying program. On the other hand, termination is not enforced anymore by the type system, contrarily to, e.g. [5, 2]. In particular, we do not require that recursive calls are made on arguments of smaller size.

• –

The polymorphic sized types system, by itself, does not guarantee any complexity-theoretic property on the typed program, except for the size of the output being bounded by a function on the size of the input, itself readable from the type. Complexity analysis of a program $\mathsf{P}$ can however be seen as a size analysis of another program $\hat{\mathsf{P}}$ which computes not only $\mathsf{P}$, but its complexity. This transformation, called the ticking transformation, has already been studied in similar settings [7].

• –

Contrarily to many papers from the literature, we have taken care not only of constraint inference, but also of constraint solving. This has been done by building a prototype called HoSA which implements type inference and ticking, and then relies on an external tool, called GUBS, to check the generated constraints for satisfiability. GUBS borrows heavily from the advances made over the last decade in the synthesis of polynomial interpretations, a form of polynomial ranking function, by the rewriting community. It features also some novel aspects, most importantly, a bottom-up SCC analysis for incremental constraint solving. We thus arrive at a fully automated runtime analysis of higher-order functional programs. Noteworthy, we are able to effectively infer polynomial, not necessarily linear, bounds on the runtime of programs.

Both tools are open source and available from the first authors homepage.222See https://cl-informatik.uibk.ac.at/users/zini/software. HoSA is able to analyse, fully automatically, a series of examples which cannot be handled by most competitor methodologies. Indeed, it is to our best knowledge up until today the only approach that can fully deal with function closures whose complexity depends on the captured environment, compare for instance the very recent work of Hoffmann et. al. [8]. Dealing with such closures is of crucial importance, e.g., when passing partially applied functions to higher-order combinators, a feature pervasively used in functional programming.

For brevity, we only give a formalisation of our system and state the central theorem here. An extended version, including all the technical details is available online [3].

2 Our Type System at a Glance

In this section, we will motivate the design choices we made when defining our type system through some examples. This can also be taken as a gentle introduction to the system for those readers which are familiar with functional programming and type theory. Our type system shares quite some similarities with the prototypical system introduces by Hughes et. al. [9] and similar ones [4, 11], but we try to keep presentation as self-contained as possible.

Basics.

We work with functional programs over a fixed set of inductive datatypes, e.g. {{\color[rgb]{0,0.3,0}\definecolor[named]{pgfstrokecolor}{rgb}{0,0.3,0}{{\mathtt{Nat}}}}} for natural numbers and {{\color[rgb]{0,0.3,0}\definecolor[named]{pgfstrokecolor}{rgb}{0,0.3,0}{{\mathtt{List}}}}}\ \alpha for lists over elements of type $\alpha$. Each such datatype is associated with a set of typed constructors, below we will use the constructors 0\mathrel{::}{{\color[rgb]{0,0.3,0}\definecolor[named]{pgfstrokecolor}{rgb}{0,0.3,0}{{\mathtt{Nat}}}}}{}, \mathtt{Succ}\mathrel{::}{{\color[rgb]{0,0.3,0}\definecolor[named]{pgfstrokecolor}{rgb}{0,0.3,0}{{\mathtt{Nat}}}}}\to{{\color[rgb]{0,0.3,0}\definecolor[named]{pgfstrokecolor}{rgb}{0,0.3,0}{{\mathtt{Nat}}}}} for naturals, and the constructors \mathtt{[\,]}\mathrel{::}\forall\alpha.\ {{\color[rgb]{0,0.3,0}\definecolor[named]{pgfstrokecolor}{rgb}{0,0.3,0}{{\mathtt{List}}}}}\ \alpha and the infix constructor (\mathrel{\mathtt{:}})\mathrel{::}\forall\alpha.\ \alpha\to{{\color[rgb]{0,0.3,0}\definecolor[named]{pgfstrokecolor}{rgb}{0,0.3,0}{{\mathtt{List}}}}}\ \alpha\to{{\color[rgb]{0,0.3,0}\definecolor[named]{pgfstrokecolor}{rgb}{0,0.3,0}{{\mathtt{List}}}}}\ \alpha for lists. Sized types refine each such datatype into a family of datatypes indexed by natural numbers, their size. E.g., to {{\color[rgb]{0,0.3,0}\definecolor[named]{pgfstrokecolor}{rgb}{0,0.3,0}{{\mathtt{Nat}}}}} and {{\color[rgb]{0,0.3,0}\definecolor[named]{pgfstrokecolor}{rgb}{0,0.3,0}{{\mathtt{List}}}}}\ \alpha we associate the families {{\color[rgb]{0,0.3,0}\definecolor[named]{pgfstrokecolor}{rgb}{0,0.3,0}{{\mathtt{Nat}}}}}_{0},{{\color[rgb]{0,0.3,0}\definecolor[named]{pgfstrokecolor}{rgb}{0,0.3,0}{{\mathtt{Nat}}}}}_{1},{{\color[rgb]{0,0.3,0}\definecolor[named]{pgfstrokecolor}{rgb}{0,0.3,0}{{\mathtt{Nat}}}}}_{2},\dots and {{\color[rgb]{0,0.3,0}\definecolor[named]{pgfstrokecolor}{rgb}{0,0.3,0}{{\mathtt{List}}}}}_{0}\ \alpha,{{\color[rgb]{0,0.3,0}\definecolor[named]{pgfstrokecolor}{rgb}{0,0.3,0}{{\mathtt{List}}}}}_{1}\ \alpha,{{\color[rgb]{0,0.3,0}\definecolor[named]{pgfstrokecolor}{rgb}{0,0.3,0}{{\mathtt{List}}}}}_{2}\ \alpha,\dots, respectively. An indexed datatype such as {{\color[rgb]{0,0.3,0}\definecolor[named]{pgfstrokecolor}{rgb}{0,0.3,0}{{\mathtt{List}}}}}_{n}\ {{\color[rgb]{0,0.3,0}\definecolor[named]{pgfstrokecolor}{rgb}{0,0.3,0}{{\mathtt{Nat}}}}}_{m} then represents lists of length $n$, over naturals of size $m$.

A function $\mathtt{f}$ will then be given a polymorphic type $\forall\vec{\alpha}.\ \forall\vec{i}.\ \tau\to\zeta$. Whereas the variables $\vec{\alpha}$ range over types, the variables $\vec{i}$ range over sizes. Datatypes occurring in the types $\tau$ and $\zeta$ will be indexed by expressions over the variables $\vec{i}$. E.g., the append function can be attributed the sized type \forall\alpha.\ \forall ij.\ {{\color[rgb]{0,0.3,0}\definecolor[named]{pgfstrokecolor}{rgb}{0,0.3,0}{{\mathtt{List}}}}}_{i}\ \alpha\to{{\color[rgb]{0,0.3,0}\definecolor[named]{pgfstrokecolor}{rgb}{0,0.3,0}{{\mathtt{List}}}}}_{j}\ \alpha\to{{\color[rgb]{0,0.3,0}\definecolor[named]{pgfstrokecolor}{rgb}{0,0.3,0}{{\mathtt{List}}}}}_{i+j}\ \alpha.

Soundness of our type-system will guarantee that when append is applied to lists of length $n$ and $m$ respectively, will yield a list of size $n+m$, or possibly diverge. In particular, our type system is not meant to guarantee termination, and complexity analysis will be done via the aforementioned ticking transformation, to be described later. As customary in sized types, we will also integrate a subtyping relation $\tau\sqsubseteq\zeta$ into our system, allowing us to relax size annotations to less precise ones. This flexibility is necessary to treat conditionals where the branches are attributed different sizes, or, to treat higher-order combinators which are used in multiple contexts.

Our type system, compared to those from the literature, has its main novelty in polymorphism, but is also different in some key aspects, addressing intensionality but also practical considerations towards type inference. In the following, we shortly discuss the main differences.

Canonical Polymorphic Types.

We allow polymorphism over size expressions, but put some syntactic restrictions on function declarations: In essence, we disallow non-variable size annotations directly to the left of an arrow, and furthermore, all these variables must be pairwise distinct. We call such types canonical. The first restriction dictates that e.g. \mathtt{half}\mathrel{::}\forall i.{{\color[rgb]{0,0.3,0}\definecolor[named]{pgfstrokecolor}{rgb}{0,0.3,0}{{\mathtt{Nat}}}}}_{2\cdot i}\to{{\color[rgb]{0,0.3,0}\definecolor[named]{pgfstrokecolor}{rgb}{0,0.3,0}{{\mathtt{Nat}}}}}_{i} has to be written as \mathtt{half}\mathrel{::}\forall i.{{\color[rgb]{0,0.3,0}\definecolor[named]{pgfstrokecolor}{rgb}{0,0.3,0}{{\mathtt{Nat}}}}}_{i}\to{{\color[rgb]{0,0.3,0}\definecolor[named]{pgfstrokecolor}{rgb}{0,0.3,0}{{\mathtt{Nat}}}}}_{i/2}. The second restriction prohibits e.g. the type declaration \mathtt{f}\mathrel{::}\forall i.{{\color[rgb]{0,0.3,0}\definecolor[named]{pgfstrokecolor}{rgb}{0,0.3,0}{{\mathtt{Nat}}}}}_{i}\to{{\color[rgb]{0,0.3,0}\definecolor[named]{pgfstrokecolor}{rgb}{0,0.3,0}{{\mathtt{Nat}}}}}_{i}\to\tau, rather, we have to declare $\mathtt{f}$ with a more general type \forall ij.{{\color[rgb]{0,0.3,0}\definecolor[named]{pgfstrokecolor}{rgb}{0,0.3,0}{{\mathtt{Nat}}}}}_{i}\to{{\color[rgb]{0,0.3,0}\definecolor[named]{pgfstrokecolor}{rgb}{0,0.3,0}{{\mathtt{Nat}}}}}_{j}\to\tau^{\prime}. The two restrictions considerably simplify the inference machinery when dealing with pattern matching, and pave the way towards automation. Instead of a complicated unification based mechanism, a matching mechanism suffices.

Abstract Index Language.

Unlike in [9], where indices are formed over naturals and addition, we keep the index language abstract. This allows for more flexibility, and ultimately for a better intensionality. Indeed, having the freedom of not adopting a fixed index language is known to lead towards completeness [6].

Polymorphic Recursion over Sizes.

Type inference in functional programming languages, such as Haskell or OCaml, is restricted to parametric polymorphism in the form of let-polymorphism. Recursive definitions are checked under a monotype, thus, types cannot change between recursive calls. Recursive functions that require full parametric polymorphism [10] have to be annotated in general, as type inference is undecidable in this setting.

Let-polymorphism poses a significant restriction in our context, because sized types considerably refine upon simple types. Consider for instance the usual tail-recursive definition of list reversal depicted in Figure 1. With respect to the annotated sized types, in the body of the auxiliary function $\mathtt{rev}$ defined on line 4, the type of the second argument to $\mathtt{rev}$ will change from {{\color[rgb]{0,0.3,0}\definecolor[named]{pgfstrokecolor}{rgb}{0,0.3,0}{{\mathtt{List}}}}}_{j}\ \alpha (the assumed type of $ys$) to {{\color[rgb]{0,0.3,0}\definecolor[named]{pgfstrokecolor}{rgb}{0,0.3,0}{{\mathtt{List}}}}}_{j+1}\ \alpha (the inferred type of $x\mathrel{\mathtt{:}}ys$). Consequently, $\mathtt{rev}$ is not typeable under a monomorphic sized type. Thus, to handle even such very simple functions, we will have to overcome let-polymorphism, on the layer of size annotations. To this end, conceptually we allow also recursive calls to be given a type polymorphic over size variables. This is more general than the typing rule for recursive definitions found in more traditional systems [9, 4].

Higher-ranked Polymorphism over Sizes.

In order to remain decidable, classical type inference systems work on polymorphic types in prenex form $\forall{\vec{\alpha}}.\tau$, where $\tau$ is quantifier free. In our context, it is often not enough to give a combinator a type in prenex form, in particular when the combinator uses a functional argument more than once. All uses of the functional argument have to be given then the same type. In the context of sized types, this means that functional arguments can be applied only to expressions whose attributed size equals. This happens for instance in recursive combinators, but also non-recursive ones such as the following function $\mathtt{twice}\ f\ x=f\ (f\ x)$.

A strong type-system would allow us to type the expression $\mathtt{twice}\ \mathtt{Succ}$ with a sized type {{\color[rgb]{0,0.3,0}\definecolor[named]{pgfstrokecolor}{rgb}{0,0.3,0}{{\mathtt{Nat}}}}}_{c}\to{{\color[rgb]{0,0.3,0}\definecolor[named]{pgfstrokecolor}{rgb}{0,0.3,0}{{\mathtt{Nat}}}}}_{c+2}. A (specialised) type in prenex form for $\mathtt{twice}$, such as

[TABLE]

would immediately yield the mentioned sized type for $\mathtt{twice}\ \mathtt{Succ}$. However, we will not be able to type $\mathtt{twice}$ itself, because the outer occurrence of $f$ would need to be typed as {{\color[rgb]{0,0.3,0}\definecolor[named]{pgfstrokecolor}{rgb}{0,0.3,0}{{\mathtt{Nat}}}}}_{i+1}\to{{\color[rgb]{0,0.3,0}\definecolor[named]{pgfstrokecolor}{rgb}{0,0.3,0}{{\mathtt{Nat}}}}}_{i+2}, whereas the type of $\mathtt{twice}$ dictates that $f$ has type {{\color[rgb]{0,0.3,0}\definecolor[named]{pgfstrokecolor}{rgb}{0,0.3,0}{{\mathtt{Nat}}}}}_{i}\to{{\color[rgb]{0,0.3,0}\definecolor[named]{pgfstrokecolor}{rgb}{0,0.3,0}{{\mathtt{Nat}}}}}_{i+1}.

The way out is to allow polymorphic types of rank higher than one when it comes to size variables, i.e. to allow quantification of size variables to the left of an arrow at arbitrary depth. Thus, we can declare

[TABLE]

As above, this allows us to type the expression $\mathtt{twice}\ \mathtt{Succ}$ as desired. Moreover, the inner quantifier permits the two occurrences of the variable $f$ in the body of $\mathtt{twice}$ to take types {{\color[rgb]{0,0.3,0}\definecolor[named]{pgfstrokecolor}{rgb}{0,0.3,0}{{\mathtt{Nat}}}}}_{i}\to{{\color[rgb]{0,0.3,0}\definecolor[named]{pgfstrokecolor}{rgb}{0,0.3,0}{{\mathtt{Nat}}}}}_{i+1} and {{\color[rgb]{0,0.3,0}\definecolor[named]{pgfstrokecolor}{rgb}{0,0.3,0}{{\mathtt{Nat}}}}}_{i+1}\to{{\color[rgb]{0,0.3,0}\definecolor[named]{pgfstrokecolor}{rgb}{0,0.3,0}{{\mathtt{Nat}}}}}_{i+2} respectively, and thus $\mathtt{twice}$ is well-typed.

The Ticking Transformation.

Our type system only reflect upon one extensional properties of programs, namely how the size of the output relates to the size of the input. Runtime analysis can however be reduced to size analysis, e.g. via a ticking transformation. This transformation takes a program $\mathsf{P}$ and translates it into another program $\hat{\mathsf{P}}$. The transformed program behaves like $\mathsf{P}$, but additionally computes also the runtime on the given input. Technically, the latter is achieved by threading through the computation a counter, the clock, which is advanced whenever an equation of $\mathsf{P}$ fires. A $k$-ary function $\mathtt{f}\mathrel{::}\tau_{\_}1\to\cdots\to\tau_{\_}{k}\to\tau$ of $\mathsf{P}$ will be modeled in $\hat{\mathsf{P}}$ by a function $\hat{\mathtt{\mathtt{f}}}_{k}\mathrel{::}\langle\tau_{\_}1\rangle\to\cdots\to\langle\tau_{\_}{k}\rangle\to{{\mathtt{C}}}\to\langle\tau\rangle\times{{\mathtt{C}}}$, where ${{\mathtt{C}}}$ is the type of the clock. Here, $\langle\rho\rangle$ enriches functional types $\rho$ with clocks accordingly. The function $\hat{\mathtt{\mathtt{f}}}_{k}$ behaves in essence like $\mathtt{f}$, but advances the threaded clock suitably. The clock-type ${{\mathtt{C}}}$ encodes the running time in unary notation. The size of the clock thus corresponds to its value. Our type system can estimate the size of the clock in the ticked program $\hat{\mathsf{P}}$, and thus the runtime of the considered program $\mathsf{P}$. Noteworthy, this transformation is straight forward to implement.

3 A Worked Out Example

In this section we give a nontrivial example. The sized type annotated program is given in Figure 2. The function $\mathtt{product}$ computes the cross-product $[\,(m,n)\mid m\in ms,n\in ns\,]$ for two given lists $ms$ and $ns$. It is defined in terms of two folds. The inner fold appends, for a fixed element $m$, the list $[\,(m,n)\mid n\in ns\,]$ to an accumulator $ps$, the outer fold traverses this function over all elements $m$ from $ms$.

In a nutshell, checking that a function $\mathtt{f}$ is typed correctly amounts to checking that all its defining equations are well-typed, i.e. under the assumption that the variables are typed according to the type declaration of $\mathtt{f}$, the right-hand side of the equation has to be given the corresponding return-type. Of course, all of this has to take pattern matching into account.

Let us illustrate this on the recursive equation of $\mathtt{foldr}$ given in Line 3 in Figure 2. Throughout the following, we denote by $s{\,:\,}\tau$ that the term $s$ has type $\tau$. To show that the equation is well-typed, let us assume the following types for arguments: f{\,:\,}\forall i.\ \alpha\to{{\color[rgb]{0,0.3,0}\definecolor[named]{pgfstrokecolor}{rgb}{0,0.3,0}{{\mathtt{List}}}}}_{i}\ \beta\to{{\color[rgb]{0,0.3,0}\definecolor[named]{pgfstrokecolor}{rgb}{0,0.3,0}{{\mathtt{List}}}}}_{i+j}\ \beta, b{\,:\,}{{\color[rgb]{0,0.3,0}\definecolor[named]{pgfstrokecolor}{rgb}{0,0.3,0}{{\mathtt{List}}}}}_{k}\ \beta, $x{\,:\,}\alpha$ and xs{\,:\,}{{\color[rgb]{0,0.3,0}\definecolor[named]{pgfstrokecolor}{rgb}{0,0.3,0}{{\mathtt{List}}}}}_{m}\ \alpha for arbitrary size-indices $j,k,m$. Under these assumptions, the left-hand side has type {{\color[rgb]{0,0.3,0}\definecolor[named]{pgfstrokecolor}{rgb}{0,0.3,0}{{\mathtt{List}}}}}_{(m+1)\cdot j+k}\ \beta, taking into account that the recursion parameter $x\mathrel{\mathtt{:}}xs$ has size $m+1$. To show that the equation is well-typed, we verify that the right-hand side can be attributed the same sized type. To this end, we proceed inside out as follows.

We instantiate the polymorphic type of $\mathtt{foldr}$ and derive

[TABLE]

• 2.

from this and the above assumptions we get \mathtt{foldr}\ f\ b\ xs{\,:\,}{{\color[rgb]{0,0.3,0}\definecolor[named]{pgfstrokecolor}{rgb}{0,0.3,0}{{\mathtt{List}}}}}_{m\cdot j+k}\ \beta;

• 3.

by instantiating the quantified size variable $i$ in the assumed type of $f$ with the index term $m\cdot j+k$ we get f{\,:\,}\alpha\to{{\color[rgb]{0,0.3,0}\definecolor[named]{pgfstrokecolor}{rgb}{0,0.3,0}{{\mathtt{List}}}}}_{m\cdot j+k}\ \beta\to{{\color[rgb]{0,0.3,0}\definecolor[named]{pgfstrokecolor}{rgb}{0,0.3,0}{{\mathtt{List}}}}}_{(m\cdot j+k)+j}\ \beta;

• 4.

from the last two steps we finally get f\ x\ (\mathtt{foldr}\ f\ b\ xs){\,:\,}{{\color[rgb]{0,0.3,0}\definecolor[named]{pgfstrokecolor}{rgb}{0,0.3,0}{{\mathtt{List}}}}}_{(m+1)\cdot j+k}\ \beta.

We will not explain the type checking of the remaining equations. However, we would like to stress two crucial points concerning the type of $\mathtt{foldr}$. First of all, we could only suitably type the two occurrences of $f$ in the body of $\mathtt{foldr}$ since $f$ was given a type polymorphic in the size of its arguments. Secondly, notice that the variable $j$ in the type of $\mathtt{foldr}$ relates the size of the result of the argument function to the size of the result of $\mathtt{foldr}$. This turns out to be a very useful feature in our system, as any expression that can be given a type of the form \tau\to{{\color[rgb]{0,0.3,0}\definecolor[named]{pgfstrokecolor}{rgb}{0,0.3,0}{{\mathtt{List}}}}}_{k}\ \rho\to{{\color[rgb]{0,0.3,0}\definecolor[named]{pgfstrokecolor}{rgb}{0,0.3,0}{{\mathtt{List}}}}}_{k+m}\ \rho is applicable to $\mathtt{foldr}$, even if $m$ depends on the environment of the call-site. In particular, we will be able to instantiate both $\lambda$-abstractions in the definition of $\mathtt{product}$ to such a type, despite that for the outer abstraction, $m$ depends on the size of the captured variable $ns$. It is also worthy of note that the example is only typable since the most general type for $\mathtt{foldr}$, namely (\alpha\to\beta\to\beta)\to\beta\to{{\color[rgb]{0,0.3,0}\definecolor[named]{pgfstrokecolor}{rgb}{0,0.3,0}{{\mathtt{List}}}}}\ \alpha\to\beta has been sufficiently instantiated. Our implementation HoSA performs such an instantiation when required, and can infer the sized type of $\mathtt{product}$ specified above automatically.

4 Applicative Programs and Simple Types

We restrict our attention to a small prototypical, strongly typed functional programming language. For the sake of simplifying presentation, we impose a simple, monomorphic, type system on programs, which does not guarantee anything except a form of type soundness. We will only later in this paper introduce sized types proper. Our theory can be extended straightforwardly to an ML-style polymorphic type setting. Here, such an extension would only distract from the essentials. Indeed, our implementation allows polymorphic function definitions.

Let $\mathcal{B}$ denote a finite set of base types ${\mathtt{B}},{\mathtt{C}},\dots$ . Simple types are inductively generated from ${\mathtt{B}}\in\mathcal{B}$:

[TABLE]

We follow the usual convention that $\to$ associates to the right. Let $\mathcal{X}$ denote a countably infinite set of variables, ranged over by metavariables like $\mathit{x}$, $\mathit{y}$. Furthermore, let $\mathcal{F}$ and $\mathcal{C}$ denote two disjoint sets of symbols, the set of functions and constructors, respectively, all pairwise distinct with elements from $\mathcal{X}$. Functions and constructors are denoted in teletype font. We keep the convention that functions start with a lower-case letter, whereas constructors start with an upper-case letter. Each symbol $s\in\mathcal{X}\cup\mathcal{F}\cup\mathcal{C}$ has a simple type $\tau$, and when we want to insist on that, we write $s^{\tau}$ instead of just $s$. Furthermore, each symbol $s^{\tau_{\_}1\to\cdots\to\tau_{\_}n\to\rho}\in\mathcal{F}\cup\mathcal{C}$ is associated a natural number $\operatorname{\mathsf{ar}}(s)\leq n$, its arity. The set of terms, patterns and values over functions $\mathtt{f}\in\mathcal{F}$, constructors $\mathtt{C}\in\mathcal{C}$ and variables $\mathit{x}\in\mathcal{X}$ is inductively generated as follows. Here, each term receives implicitly a type, in Church style. Below, we employ the usual convention that application associates to the left.

[TABLE]

A program $\mathsf{P}$ over functions $\mathcal{F}$ and constructors $\mathcal{C}$ defines each function $\mathtt{f}\in\mathcal{F}$ through a finite set of equations $l^{\tau}=r^{\tau}$, where $l$ is of the form $\mathtt{f}\ p_{\_}1\ \cdots p_{\_}{\operatorname{\mathsf{ar}}(f)}$. We put the usual restriction on equations that each variable occurs at most once in $l$, i.e. that $l$ is linear, and that the variables of the right-hand side $r$ are all included in $l$. To keep the semantics short, we do not impose any order on the equations. Instead, we require that left-hand sides defining $\mathtt{f}$ are all pairwise non-overlapping. This ensures that our programming model is deterministic. We assume call-by-value semantics. The call-by-value reduction relation of a program $\mathsf{P}$ is denoted by $\mathrel{\xrightarrow{\raisebox{-2.0pt}[0.0pt][0.0pt]{\text{\scriptsize$$}}}_{\mathsf{P}}}$ and defined in the expected way, see [3].

Some remarks are in order before proceeding. As standard in functional programming, only values of base type can be destructed by pattern matching. In a pattern, a constructor always needs to be fully applied. We excluded $\lambda$-abstractions from our language. In our setting, abstractions would only complicate the presentation without improving on expressivity. They can always be lifted to the top-level. Similarly, conditionals and case-expressions would not improve upon expressivity.

5 Sized Types and Their Soundness

This section is devoted to introducing the main object of study of this paper, namely a sized type system for the applicative programs that we introduced in Section 4. We have tried to keep the presentation of the relatively involved underlying concepts as simple as possible.

Indices.

As a first step, we make the notion of size index, with which we will later annotate data types, precise. Let $\mathcal{G}$ denote a set of first-order function symbols, the index symbols. Any symbol $\mathsf{f}\in\mathcal{G}$ is associated with a natural number $\operatorname{\mathsf{ar}}(\mathsf{f})$, its arity. The set of index terms is generated over a countable infinite set of index variables $i\in\mathcal{V}$ and index symbols $\mathsf{f}\in\mathcal{G}$.

[TABLE]

We denote by $\mathsf{Var}(a)\subset\mathcal{V}$ the set of variables occurring in $a$. Substitutions mapping index variables to index terms are called index substitutions. With $\vartheta$ we always denote an index substitution.

Throughout this section, $\mathcal{G}$ is kept fixed. Meaning is given to index terms through an interpretation $\mathcal{J}$, that maps every $k$-ary $\mathsf{f}\in\mathcal{G}$ to a (total) and weakly monotonic function $\llbracket\mathsf{f}\rrbracket_{\mathcal{J}}\mathrel{\colon}\mathbb{N}^{\operatorname{\mathsf{ar}}(\mathsf{f})}\to\mathbb{N}$. We suppose that $\mathcal{G}$ always contains a constant [math], a unary symbol $\mathsf{s}$, and a binary symbol $+$ which we write in infix notation below. These are always interpreted as zero, the successor function and addition, respectively. Our index language encompasses the one of Hughes et. al [9], where linear expressions over natural numbers are considered. The interpretation of an index term $a$, under an assignment $\alpha\mathrel{\colon}\mathcal{V}\to\mathbb{N}$ and an interpretation $\mathcal{J}$, is defined recursively in the usual way: $\llbracket i\rrbracket_{\mathcal{J}}^{\alpha}\mathrel{:=}\alpha(i)$ and $\llbracket\mathsf{f}(a_{1},\dots,a_{k})\rrbracket_{\mathcal{J}}^{\alpha}\mathrel{:=}\llbracket\mathsf{f}\rrbracket_{\mathcal{J}}(\llbracket a_{\_}1\rrbracket_{\mathcal{J}}^{\alpha},\dots,\llbracket a_{\_}k\rrbracket_{\mathcal{J}}^{\alpha})$.

We define $a\leq_{\mathcal{J}}b$ if $\llbracket a\rrbracket_{\mathcal{J}}^{\alpha}\leq\llbracket b\rrbracket_{\mathcal{J}}^{\alpha}$ holds for all assignments $\alpha$.

Sized Types Subtyping and Type Checking.

The set of sized types is given by annotating occurrences of base types in simple types with index terms $a$, possibly introducing quantification over index variables. More precise, the sets of (sized) monotypes, (sized) polytypes and (sized) types are generated from base types ${\mathtt{B}}$, index variables $\vec{i}$ and index terms $a$ as follows:

[TABLE]

Monotypes ${{\mathtt{B}}}_{a}$ are called indexed base types. We keep the convention that the arrow binds stronger than quantification. Thus in a polytype $\forall{\vec{i}}.\ \rho\to\tau$ the variables $\vec{i}$ are bound in $\rho$ and $\tau$. We will sometimes write a monotype $\tau$ as $\forall\epsilon.\ \tau$. This way, every type $\rho$ can given in the form $\forall\vec{i}.\ \tau$. The skeleton of a type $\rho$ is the simple type obtained by dropping quantifiers and indices. The sets $\operatorname{\mathsf{FVar}}^{+}(\cdot)$ and $\operatorname{\mathsf{FVar}}^{-}(\cdot)$, of free variables occurring in positive and negative positions, respectively, are defined in the natural way. The set of free variables in $\rho$ is denoted by $\operatorname{\mathsf{FVar}}(\rho)$. We consider types equal up to $\alpha$-equivalence. Index substitutions are extended to sized types in the obvious way, using $\alpha$-conversion to avoid variable capture.

We denote by \rho\mathrel{\mathrlap{\text{\raisebox{1.00006pt}{\hskip 1.00006pt\cdot}}}{\geqslant}}\tau that the monotype $\tau$ is obtained by instantiating the variables quantified in $\rho$ with arbitrary index terms, i.e. $\tau=\tau^{\prime}\{\vec{a}/\vec{i}\}$ for some monotype $\tau^{\prime}$ and index terms $\vec{a}$, where $\rho=\forall{\vec{i}}.\tau^{\prime}$. Notice that by our convention $\tau=\forall\epsilon.\ \tau$, we have \tau\mathrel{\mathrlap{\text{\raisebox{1.00006pt}{\hskip 1.00006pt\cdot}}}{\geqslant}}\tau for every monotype $\tau$.

The subtyping relation $\sqsubseteq_{\mathcal{J}}$ is given in Figure 3(a). It depends on the interpretation of size indices, but otherwise is defined in the expected way. We are interested in certain linear types, namely those in which any index term occurring in negative position is in fact a fresh index variable.

Definition 1** (Canonical Sized Type, Sized Type Declaration)**

A monotype $\tau$ is canonical if one of the following alternatives hold:

• –

$\tau={{\mathtt{B}}}_{a}$* is an indexed base type;*

• –

$\tau={{\mathtt{B}}}_{i}\to\tau^{\prime}$* with $i\not\in\operatorname{\mathsf{FVar}}^{-}(\tau^{\prime})$;*

• –

$\tau=\sigma\to\tau^{\prime}$* for a canonical polytype $\sigma$ and canonical type $\tau^{\prime}$ satisfying $\operatorname{\mathsf{FVar}}(\sigma)\cap\operatorname{\mathsf{FVar}}^{-}(\tau^{\prime})=\varnothing$.*

• 2.

A polytype $\sigma=\forall\vec{i}.\tau$ is canonical if $\tau$ is canonical and $\operatorname{\mathsf{FVar}}^{-}(\tau)\subseteq\{\vec{i}\}$.

• 3.

To each function symbol $s\in\mathcal{F}\cup\mathcal{C}$, we associate a closed and canonical type $\rho$ whose skeleton coincides with the simple type of $s$. We write $s\mathrel{::}\rho$ and call $s\mathrel{::}\rho$ the sized type declaration of $s$.

Canonicity ensures that pattern matching can be resolved with a simple substitution mechanism, rather than a sophisticated unification based mechanism that takes the semantic interpretation $\mathcal{J}$ into account.

In Figure 3(b) we depict the typing rules of our sized type system. A (typing) context $\Gamma$ is a mapping from variables $\mathit{x}$ to types $\rho$ so that the skeleton of $\rho$ coincides with the simple type of $\mathit{x}$. We denote the context $\Gamma$ that maps variables $\mathit{x}_{\_}i$ to $\rho_{\_}i$ ($1\leq i\leq n$) by $\mathit{x}_{1}{\,:\,}\rho_{1},\dots,\mathit{x}_{n}{\,:\,}\rho_{n}$. The empty context is denoted by $\varnothing$. We lift set operations as well as the notion of (positive, negative) free variables and application of index substitutions to contexts in the obvious way. We denote by ${\Gamma}{\restriction_{X}}$ the restriction of context $\Gamma$ to a set of variables $X\subseteq\mathcal{X}$. The typing statement $\Gamma\vdash^{\mathcal{J}}s\mathrel{:}\tau$ states that under the typing contexts $\Gamma$, the term $s$ has the monotype $\tau$, when indices are interpreted with respect to $\mathcal{J}$. The typing rules from Figure 3(b) are fairly standard. Symbols $s\in\mathcal{F}\cup\mathcal{C}\cup\mathcal{X}$ are given instance types of their associated types. This way we achieve the desired degree of polymorphism outlined in Section 2. Subtyping and generalisation is confined to function application, see rule (App). Here, the monotype $\zeta_{\_}2$ of the argument term $t$ is weakened to $\zeta_{\_}1$, the side-conditions put on index variables $\vec{i}$ allow then a generalisation of $\zeta_{\_}1$ to $\forall\vec{i}.\zeta_{\_}1$, the type expected by the function $s$. This way, the complete system becomes syntax directed. We remark that subtyping is prohibited in the typing of the left spine of applicative terms.

Since our programs are equationally-defined, we need to define when equations are well-typed. In essence, we will say that a program $\mathsf{P}$ is well-typed, if, for all equations $l=r$, the right-hand side $r$ can be given a subtype of $l$. Due to polymorphic typing of recursion, and since our typing relation integrates subtyping, we have to be careful. Instead of giving $l$ an arbitrary derivable type, we will have to give it a most general type that has not been weakened through subtyping. Put otherwise, the type for the equation, which is determined by $l$, should precisely relate to the declared type of the considered function. To this end, we introduce the restricted typing relation, the footprint relation, depicted in Figure 4. We are now able to state the well-typedness condition.

Definition 2

Let $\mathsf{P}$ be a program, such that every function and constructor has a declared sized type. We call a rule $l=r$ from $\mathsf{P}$ well-typed under the interpretation $\mathcal{J}$ if

[TABLE]

holds for all contexts $\Gamma$ and types $\tau$. The program $\mathsf{P}$ is well-typed under the interpretation $\mathcal{J}$ if all its equations are.

The following then gives our central result.

Theorem 1** (Subject Reduction)**

Suppose $\mathsf{P}$ is well-typed under $\mathcal{J}$. If $\vdash_{\mathsf{e}}^{\mathcal{J}}s\mathrel{:}\tau$ and $s\mathrel{\xrightarrow{\raisebox{-2.0pt}[0.0pt][0.0pt]{\text{\scriptsize$$}}}_{\mathsf{P}}}t$ then $\vdash_{\mathsf{e}}^{\mathcal{J}}t\mathrel{:}\tau$.

But what does Subject Reduction tells us, besides guaranteeing that types are preserved along reduction? Actually, a lot: If $\vdash_{\mathsf{e}}^{\mathcal{J}}s\mathrel{:}{{\mathtt{B}}}_{a}$, we are now sure that the evaluation of $s$, if it terminates, would lead to a value of size at most $\llbracket a\rrbracket_{\mathcal{J}}$. Of course, this requires that we give (first-order) data-constructors a suitable sized type. To this end, let us call a sized type additive if it is of the form $\forall\vec{i}.\ {{\mathtt{B}}}_{i_{\_}1}\to\cdots\to{{\mathtt{B}}}_{i_{\_}k}\to{{\mathtt{B}}}_{\mathsf{s}(i_{\_}1+\dots+i_{\_}k)}$.

Corollary 1

Suppose $\mathsf{P}$ is well-typed under the interpretation $\mathcal{J}$, where data-constructors are given an additive type. Suppose the first-order function $\mathtt{main}$ has type $\forall{\vec{i}}.{{\mathtt{B}}}_{i_{\_}1}\to\cdots\to{{\mathtt{B}}}_{i_{\_}k}\to{{\mathtt{B}}}_{a}$. Then for all inputs $d_{1},\dots,d_{n}$, if $\mathtt{main}\ d_{1}\,\cdots\,d_{k}$ reduces to a data value $d$, then the size of $d$ is bounded by $s(\lvert{d_{\_}1}\rvert,\dots,\lvert{d_{\_}k}\rvert)$, where $s$ is the function $s(i_{1},\dots,i_{k})=\llbracket a\rrbracket_{\mathcal{J}}^{\alpha}$.

As we have done in the preceding examples, the notion of additive sized type could be suited so that constants like the list constructor $\mathtt{[\,]}$ are attributed with a size of zero. Thereby, the sized type for lists would reflect the length of lists. Although we take this more natural size measure into account in our implementation, for the sake of brevity we refrained from doing so here. Note that the corollary by itself, does not mean much about the complexity of evaluating $s$. Through the aforementioned ticking transformation however allows us to reduce runtime analysis of $\mathsf{P}$ to a size analysis, which in turn can be carried out with our sized type system.

6 Conclusions

We have described a new system of sized types whose key features are an abstract index language, and higher-rank index polymorphism. This allows for some more flexibility compared to similar type systems from the literature. The introduced type system is proved to enjoy a form of type soundness. We have also implemented sized type inference in a prototype tool, called HoSA. Noteworthy, inference is fully automated, i.e., does not require any form of manual size annotations.

One key motivation behind this work is achieving a form of modular complexity analysis without sacrificing its expressive power. This is achieved by the adoption of a type system, which is modular and composable by definition. Noteworthy, modularity carries to some extend through to constraint solving. The SCCs in the generated constraint problem are in correspondence with the SCC of the call-graph in the input program, and are analysed independently.

Future work definitively includes refinements to our underlying constraint solver. It would also be interesting to see how our overall methodology applies to different resource measures like heap size etc. Concerning heap size analysis, this is possible by ticking constructor allocations. It could also be worthwhile to integrate a form of amortisation in our system. This however is left for future work.