*ptr1 = val; which changes what ptr1 points to
and may also change what other variables point to. One of the design
principles of Pawns is that if code can affect the value of a variable
(or depends on the variable), this should be obvious. For example, a Pawns
statement can have the annotation !ptr2 to indicate it may affect
variable ptr2. Even imperative Pawns code avoids the problem
of subtle undocumented interactions which can occur in other languages.
Programming with pointers requires the programmer to understand pointer aliasing and sharing of data structures. In Pawns, sharing information is declared, providing documentation and allowing the compiler to understand the sharing and check the declarations are correct. As well as declaring side-effects, the programmer declares what sharing may occur between arguments when a function is called and what sharing may occur when it returns. By tracking possible sharing we can determine if arguments of a function can be updated during its execution. If update is restricted to variables which are local to the function execution, purely functional behaviour is guaranteed. For example, a data structure can be built locally using an imperative style, then returned. Thus imperative code can be encapsulated inside a declarative interface.
Pure functional programming is the default in Pawns. Arbitrary sharing of function arguments and results is possible and update of such data structures is not allowed. However, if enough extra declarations and annotations are supplied, there are no restrictions on what can be updated anywhere.
The Disciple programming language supports similar low level imperative features to Pawns but uses "region" information rather than sharing information to limit interaction and effects. Disciple does more inference of region and side effect information than is done in Pawns, so there is more potential for "nasty surprises" and doesn't encapsulate effects to the same extent.
ML supports destructive update using data types containing
ref and Haskell's STRef monad is similar.
The type system limits interaction and effects. This has similar
consequences to the Disciple approach with respect to nasty surprises
and encapsulation and can also lead to multiple versions of a data type
and extra indirection in the representation.
The scripting language Pawn has a similar name to Pawns but they are not at all closely related in other respects. Both are influenced by C. Pawn started life as a cut-down version of C and has no types or pointers (except it supports call by reference). Pawns combines C-style pointers with a nice type system and other benefits of pure functional programming.