Peer Review #1 of "Sharing analysis in the Pawns compiler (v0.2)" [peer_review]

2015 unpublished
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
more » ... n 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. PeerJ Comput. Sci. reviewing PDF | (Abstract. Pawns is a programming language under development that 8 supports algebraic data types, polymorphism, higher order functions and 9 "pure" declarative programming. It also supports impure imperative fea-10 tures including destructive update of shared data structures via pointers, 11 allowing significantly increased efficiency for some operations. A novelty 12 of Pawns is that all impure "effects" must be made obvious in the source 13 code and they can be safely encapsulated in pure functions in a way 14 that is checked by the compiler. Execution of a pure function can per-15 form destructive updates on data structures that are local to or even-16 tually returned from the function without risking modification of the 17 data structures passed to the function. This paper describes the shar-18 ing analysis which allows impurity to be encapsulated. Aspects of the 19 analysis are similar to other published work, but in addition it handles 20 explicit pointers and destructive update, higher order functions including 21 closures and pre-and post-conditions concerning sharing for functions. 22 Keywords: functional programming language, destructive update, muta-23 bility, effects, algebraic data type, sharing analysis, aliasing analysis 24 30 code, where programmers can consider the representation of data types, obtain 31 pointers to the arguments of data constructors and destructively update them. 32 Such code requires the programmer to reason at a much lower level and consider 33 aliasing of pointers and sharing of data structures. Low level "impure" code can 34 be encapsulated within a pure interface and the compiler checks the purity. This 35 requires analysis of pointer aliasing and data structure sharing, to distinguish 36 data structures that are only visible to the low level code (and are therefore 37 safe to update) from data structures that are passed in from the high level code 38 (for which update would violate purity). The main aim of Pawns is to get the 39 PeerJ Comput. Sci. reviewing PDF | (CS-2015:03:4448:2:0:NEW 1 Aug 2015) Reviewing Manuscript 2 benefits of purity for most code but still have the ability to write some key 40 components using an imperative style, which can significantly improve efficiency 41 (for example, a more than twenty-fold increase in the speed of inserting an 42 element into a binary search tree). 43 There are other functional programming languages, such as ML [2], Haskell 44 [3] and Disciple [4] , that allow destructive update of shared data structures but 45 do not allow this impurity to be encapsulated. In these languages the ability 46 to update the data structure is connected to its type 1 . For a data structure to 47 be built using destructive update its type must allow destructive update and 48 any code that uses the data structure can potentially update it as well. This 49 prevents simple declarative analysis of the code and can lead to a proliferation 50 of different versions of a data structure, with different parts being mutable. For 51 example, there are four different versions of lists, since both the list elements 52 and the "spine" may (or may not) be mutable, and sixteen different versions 53 of lists of pairs. There is often an efficiency penalty as well, with destructive 54 update requiring an extra level of indirection in the data structure (an explicit 55 "reference" in the type with most versions of ML and Haskell). Pawns avoids 56 this inefficiency and separates mutability from type information, allowing a data 57 structure to be mutable in some contexts and considered "pure" in others. The 58 main cost from the programmer perspective is the need to include extra annota-59 tions and information in the source code. This can also be considered a benefit, 60 as it provides useful documentation and error checking. The main implementa-61 tion cost is additional analysis done by the compiler, which is the focus of this 62 paper. 63
doi:10.7287/peerj-cs.22v0.2/reviews/1 fatcat:73e3pfmecbdxpnn6jgctyr637a