Polya:True Type Polymorphism for Mobile Ambients

Abstract

Previous type systems for mobility calculi (the original Mobile Ambients, its variants and descendants, e.g., Boxed Ambients and Safe Ambients, and other related systems) offer little support for generic mobile agents. Previous systems either do not handle communication at all or globally assign fixed communication types to ambient names that do not change as an ambient moves around or interacts with other ambients. This makes it hard to type examples such as a messenger ambient that uses communication primitives to collect a message of non-predetermined type and deliver it to a non-predetermined destination.In contrast, we present our new type system PolyA. Instead of assigning communication types to ambient names, PolyA assigns a type to each process P that gives upper bounds on (1) the possible ambient nesting shapes of any process P to which P can evolve, (2) the values that may be communicated at each location, and (3) the capabilities that can be used at each location. Because PolyA can type generic mobile agents, we believe PolyA is the first type system for a mobility calculus that provides type polymorphism comparable in power to polymorphic type systems for the λ-calculus. PolyA is easily extended to ambient calculus variants. A restriction of PolyA has principal typings.

Instant Polymorphic Type Systems for Mobile Process Calculi: Just Add Reduction Rules and Close

“…The Poly✶ type system descends from (but significantly generalises and enhances) our earlier work [2] on PolyA, a polymorphic type system specific to Mobile Ambients. It inherits from PolyA the difference from most other type systems for mobility calculi that the emphasis is on types for processes rather than types for (ambient or channel) names.…”

“…We have checked that it works for π-calculus, a large number of ambient calculi, and a version of the Seal calculus. In [2] we claimed PolyA would be easy to extend to ambient-like calculi by hand, but extending the proofs for PolyA manually would be tedious. With Meta✶ we have developed the theory to do such extensions fully automatically.…”

“…1 Like every nontrivial type system with an inference algorithm, Poly✶ can be used as a control/data flow analysis to provide the substratum for more specialised automatic program analyses. 2 (Readers who are uncomfortable about applying the term "type system" to Poly✶ are invited to think "versatile program analysis framework" each time we write "type system".) However, we have no pretension of subsuming all other analysis techniques for mobility or process calculi in general.…”

“…This is different from, and 1 These fine tuning options are omitted from this paper due to lack of space, but they are described in detail in the implementation's documentation. 2 Indeed it is well known [20,3] that the difference between an advanced flow analysis and an advanced type system is often just a question of different perspectives on the same underlying machinery. The presentation of Poly✶ is closer to the data-flow viewpoint than is common for type systems, though this of course does not make Poly✶ any less a type system.…”

“…Therefore the closing operation described below cannot keep adding edges and nodes to the graph indefinitely and will eventually stop. (These two restrictions replace the notions of "discrete" and "modest" types in [2], which sometimes admitted slightly more precise types, but were very complex and hard to understand).…”