The first version of Haskell VCache is now available on Hackage. Before installing VCache, you may need to `sudo apt-get install lmdb-dev` on your Linux system, or install LMDB and its header files by some other means.
At this point, the primary features of VCache seem solid. PVars and VRefs are each first-class. The reference counting garbage collection is very simple. Structure sharing for values works. The concurrent aspects are kept simple, albeit bottlenecked at the moment by a single MVar. The batching mechanisms work very well. It seems easy to use, at least in ghci. But testing isn’t very rigorous.
There are performance improvements to be had, especially with respect to cache management.
But if you’re interested in an alternative to acid-state that can support very large values and fine-grained, first-class mutable variables, then give VCache a try. Also, let me know where the documentation can be improved.
Awelon Blue 
Sorry for being a bit offtopic to this particular post, but I have a question regarding local state.
How would you do something like reduce/aggregate/integrate/fold in RDP? You write elsewhere about functional reactive programming that “FRP supports local state through integrals or accumulators (fold over time) “. What is the alternative?
How about if some program were to push state to a memory resource, but subscribe to a stream of its last output. For example a counter which takes a number num as input and a number last_count from memory as another input and then output count to memory. Do you imagine this would have the same problems even though the local state now exists externally to the program? Do you think all state in cases like this should be persisted to disk immediately? In general how would you sum a time-varying signal if not through some kind of accumulator?
I discussed this in 2013 [1][2]. For RDP, which requires state be both external and declarative, the general idea is that we model external state resources whose behavior is influenced by a set of input signals. You just end up with something like: `
updateState :: (Eq s, Ord a) ⇒ Set a → s → s`, and every time the input set changes you recompute state `s`. The simplest approach is that you compute to a fixpoint (until s == s’), then wait for the next change in the input set.Unfortunately, waiting for a fixpoint can make it difficult to reason about progress. If you want to guarantee progress, there are more sophisticated variations: e.g. limiting computation based on time intervals or economic models. These trade easy reasoning about consistency for easy reasoning about progress. We may still idle after we reach a fixpoint, waiting until the input set changes again.
Regardless, this essentially shifts our ‘fold’ logic into some type-dependent ‘updateState’ function, and we discover or acquire external resources of this type (i.e. with stable identity).
Regarding your feedback-based memory scenario: no, this does not have the same problems as local state. For example, a new version of the code can still ‘pick up’ right where an older version left off, i.e. modeling a logically instantaneous handoff.
However, feedback-based memory has its own problems. If you do not have a mechanism for rollback and replay, you won’t be able to model logically instantaneous fixpoints, Thus, you’ll need a delay step before you’re allowed to observe the updated state. This delay step would interfere with conventional imperative programming: you cannot read your own writes, at least not within a transaction. RDP is designed to have good rollback and replay mechanisms, but even there I’d favor an explicit delay for known feedback loops.
A more explicit state model will typically be more robust, efficient, and easier to reason about.
And I don’t believe state should always be persisted immediately. It seems useful to me that durability be a domain-layer property, e.g. you don’t need durability for updating a shopping cart, but you might want it when committing to a purchase. VCache does persist everything to disk, but uses a background thread and batches such that only the subset of recent ‘durable’ transactions need to wait for their batch to commit to disk.
Interesting. I think I get it more or less now, I’m gonna have to try playing around with implementing external state in some programs and see if I can get a bit of feel for it.