OEP

146

Title

More general model for mobile data

Summary

Allow complex nested data structures to be built, and simplify the rules about what can be MOBILE.

Owner

Adam Sampson <ats@offog.org>

Status

Proposed

Date-Proposed

2005-09-28

Keywords

language mobiles types

Most modern applications expect to be able to build complex data structures in an efficient manner. Classical occam has no concept of references, dynamic allocation or recursive datatypes, which makes it awkward to build tree-like data structures. OEP 100 introduced the MOBILE mechanism, which provides safe references to data objects which only one process may hold at a time. This has gone some way towards making dynamic data possible in occam-pi, but you still can't construct a tree, which makes it awkward to solve many programming problems.

One approach is to allow nested mobiles: that is, if you have a MOBILE RECORD, then that may contain fields which are also MOBILE. OEP 121 defined a limited form of this. A full implementation could make it possible to build recursive structures such as trees.

DATA TYPE TREE
  MOBILE RECORD
    TREE left:
    TREE right:
    INT value:
:

To make it possible to prune trees of this sort, occam-pi would also need to provide a mechanism for setting a MOBILE variable to be undefined (which would have other uses too).

One problem with the current MOBILE mechanism is that only certain types can be mobile, and that for records mobility is determined when the record type is defined (as in the example above). For consistency, I would prefer to be able to apply the MOBILE qualifier to any existing non-mobile type -- including records -- when declaring a value of that type. I would also like to remove the restriction that only mobile records may contain mobile fields, and allow non-mobile but dynamically-sized arrays (as C99 already does).

At the same time, I would also consider renaming the MOBILE qualifier to something more generic like REF -- most other languages with explicit references just call them "references", and having a shorter keyword would make them more convenient to use. Shared references are unusual enough in the occam-pi model that they should be explicitly specified as SHARED REF or VAL REF.

OEP/146 (last edited 2007-09-27 01:16:42 by ats1)