Makes sense. I think if we abstract over it (Val) that’s fine for examples.
We should have a way to control this. Programs may want to read the latest version of an object (by contacting the controller), but they may also want to just read the cached version. I proposed using some sort of “history identifier” in the desiderata topic, which is a possible approach to this problem (all reads would be relative to the history set in the current VM context).
It’s just that filters can’t typically be written in terms of only object IDs – object IDs themselves don’t contain any information about the actual objects, so the program would always need to fetch all the objects and then iterate over them (sending some message, say), which doesn’t seem helpful.
In the abstract model perhaps we could start just with a filter specified in terms of a program which takes an object ID as input and returns true or false. In practice we won’t be able to make arbitrary-program filters efficient but I think it’d be fine for now in the model – we should at least get the model correct first, then we could simplify to a DSL or such.
Hmm, this feels wrong to me in terms of abstraction boundaries – we want to be able to compile to RM transactions, transaction functions, etc., but a big reason for designing and formalizing a VM in the first place is for the developer to only need to reason about the VM semantics (and not care what we compile it to or how).
Hmm I could be wrong here, I just don’t see yet how filtering by identifier would work (per above). Do you have an example?