This basic flow of control abstraction is subject to variation in numerous ways including
- varying the means of matching keyed location request to keyed location submission;
- varying whether the request consumes the data, removing it from the location or simply passes a copy to a requester
- varying whether a stored continuation is removed from the location when data is supplied or simply passed the data
The last variation covers a simple pub/sub mechanism. When continuations are persistent (i.e. not removed on matching data production), this is a simple subscription mechanism. When data is persisted this is storage. When it is not, this is message-passing. When key-matching has a certain level of sophistication this arrangement supports basic broadcast capability. If you look at the code sample and the traces in the screenshots you will see that we've used regular expressions as a basic matching. In the specialK repo we use unification.
All of these variations can be captured in a single configurable mechanism -- the configuration of which can be treated as policy governing communication between producers and consumers. To my mind this is really the pattern underlying the web. The web, in microcosm, is a parametrically polymorphic key-value db. Let's look at some code, however, before getting too philosophical.
The core of the implementation is in the code below. The full implementation is in the sansBNFC branch of the specialK repo.