Haskell is a lazy programming language, in which a value is not fully computed before observed in a function; this easily allows for infinite structures, mutual recursion, and parallel processing. Oz/Mozart uses logic variables, which allow us to declare a variable, share it in a structure, and unify it in concurrent computation.
I find myself tempted to lift these features into a distributed programming system. Presumably, I could save some bandwidth by implicitly passing around a reference to a large value, then lazily grabbing the value when it proves necessary. We could call these ‘remote values’.
However, remote values fail. Here’s why:
- disruption and partitioning: distributed systems have failure modes that a local runtime does not, including disruption (both temporary and permanent). However, a ‘value’ is an immutable concept, so we cannot observe ‘disruption’ while looking at a value.
- denial of service: Lazy values could be injected deep into a service, crossing multiple trust boundaries, then denied when observed. This is a potential security risk. Security risks should always be obvious in the model.
- effectful observation: in an open system, even under ideal network conditions, we cannot enforce a condition that observing the value is effect-free. We cannot protect the ‘value’ abstraction. This can also be a security risk, in the form of covert channels or analysis of exactly which information is observed.
- GC concerns: Distributed GC is very difficult, and usually heuristic. Heuristics failure would violate the ‘value’ abstraction. And the costs of collecting remote values might easily outweigh the benefits.
Note: we can still benefit from remote parallel processing for values, so long as we could regenerate the computation (or even run it locally) after it fails. That is really a separate issue, since it assumes a closed system.
Also, we can explicitly model futures and promises with effectful objects and agents, subject to disruption. Explicit, effectful objects at least make the security and partial failure risks much clearer to developers. This should be done via library because developers must be aware of the model.