Feature: "Read-Only"/"Const" Persistent Data Structures

[tmagrino]

Currently, there is no way to avoid read prepares (and the resulting overhead) in situations where a data structure is intended to be immutable.

In some current FabIL programs, if the data structure does not need to be persisted or shared, we've used a POJO data structure instead of a Fabric object to avoid these overheads. However, this solution does not work for objects which must be shared across nodes in the system.

I think it would be useful to provide "const" variants of Fabric's data structures as a way to address this issue.

A proposed design sketch: provide "immutable" versions of the Fabric data structures, which can be initialized by copying from either a mutable Fabric structure or a POJO structure (although there are concerns about ensuring items in the POJO structure are all Fabric objects). Eg:

java.util.Set sTmp = new java.util.HashSet();
sTmp.add(o1);
sTmp.add(o2);
fabric.util.ImmutableSet s = new fabric.util.ImmutableSet(sTmp);

In the case of arrays, we could provide a "const" array primitive data type. Eg:

int native[] aTmp = new int[] { 0, 1, 2 }; 
const int[] ai = new const int[](aTmp);

However, I'm certainly interested in discussing alternative designs for achieving a similar result.

[tmagrino]

It's worth noting that Jif already has a concept of const arrays.

[tmagrino]

Digging into it more, Fabric does inherit const arrays in its grammar from Jif but will throw an error if they're used.