Sharing Analysis in the Pawns Compiler

Pawns is a programming language under development that supports algebraic data types, polymorphism, higher order functions and"pure"declarative programming. It also supports impure imperative features including destructive update of shared data structures via pointers, allowing significantly increased efficiency for some operations. A novelty of Pawns is that all impure"effects"must be made obvious in the source code and they can be safely encapsulated in pure functions in a way that is checked by the compiler. Execution of a pure function can perform destructive updates on data structures that are local to or eventually returned from the function without risking modification of the data structures passed to the function. This paper describes the sharing analysis which allows impurity to be encapsulated. Aspects of the analysis are similar to other published work, but in addition it handles explicit pointers and destructive update, higher order functions including closures and pre- and post-conditions concerning sharing for functions.


25
This paper describes the sharing analysis done by the compiler for Pawns [1], 26 a programming language that is currently under development. Pawns supports 27 both declarative and imperative styles of programming. It supports algebraic 28 data types, polymorphism, higher order programming and "pure" declarative The "!" annotation on parameter p declares the first argument of assign 167 is mutable. The default is that arguments are not mutable. As well as check- 168 ing for annotations on assignments and function calls, sharing analysis is used 169 to check that all parameters which may be updated are declared mutable in assign would also need to be declared mutable in the type signature and the 177 assignment to p would require v to be annotated. In general, there is an inter-178 dependence between "!" annotations in the code and pre-and post-conditions. 179 More possible sharing at a call means more "!" annotations are needed, more 180 sharing in (recursive) calls and more sharing when the function returns.

181
Curried functions and higher order code are supported by attaching sharing 182 and destructive update information to each arrow in a type, though often the 183 information is inferred rather than being given explicitly in the source code. For 184 example, implicit in the declaration for assign above is that assign called with general, a type with N arrows in the "spine" has K + N formal parameters in 191 the description of sharing, with the first K parameters being closure arguments.

192
The following code defines binary search trees of integers and defines a func-193 tion that takes a pointer to a tree and inserts an integer into the tree.       The core of the algorithm is to compute the alias set after a statement, given 445 the alias set before the statement. This is applied recursively for compound 446 statements in a form of abstract execution. 447 We do not prove correctness of the algorithm but hope our presentation is  3 Self-aliasing for arguments and results is usually desired. For the rare cases it is not, we may provide a mechanism to override this default in the future.  1 :c 1 , v a .c a } ∈ a0} --(live variables in al+v1 must be annotated with ! --and must not share with abstract)   The old sharing between v1 and v3 is discarded but added again (via share1) The

578
It is also necessary to include one step of transitivity in the sharing informa-579 tion: if variable components x 1 .c 1 and x 2 .c 2 alias in post and x 2 .c 2 and x 3 .c 3 580 (may) alias before the function call, we add an alias of x 1 .c 1 and x 3 .c 3 (in postt).

581
Function parameters are proxies for the argument variables as well as any vari-582 able components they may alias and when functions are analysed these aliases 583 are not known. This is why the transitivity step is needed, and why mutable 584 parameters also require special treatment. If before the call, x 1 .c 1 and x 2 .c 2 may 585 alias with mutable parameter components v i .c 3 and v j .c 4 , respectively, and the    We start with the precondition, a 0 = {{tp.   Imprecision in the analysis of mutable parameters could potentially be reduced 739 by allowing the user to declare that only certain parts of a data structure are 740 mutable, as suggested in [1]. It is inevitable we lose some precision with recursion 741 in types, but it seems that some loss of precision could be avoided relatively    augmented with extra information related to groundness [11]. In Pawns there 832 are no logic variables but data structures are mutable, hence their sharing is 833 important.

834
However, the set-sharing domain (with enhancements) has been adapted to 835 analysis of sharing of data structures in object oriented languages such as Java

836
[14]. One important distinction is that Pawns supports algebraic data types 837 which allow a "sum of products": there can be a choice of several data con-