|
|
|
@ -1,7 +1,7 @@
@@ -1,7 +1,7 @@
|
|
|
|
|
# Efficient, Imperative Dataspaces for Conversational Concurrency |
|
|
|
|
|
|
|
|
|
Tony Garnock-Jones <tonyg@leastfixedpoint.com> |
|
|
|
|
14 October 2018 |
|
|
|
|
20 October 2018 |
|
|
|
|
|
|
|
|
|
<p style="font-size:90%"><strong>Abstract.</strong> The dataspace |
|
|
|
|
model of Conversational Concurrency [is great], but implementing it |
|
|
|
@ -380,7 +380,7 @@ parameterized with different update procedures.
@@ -380,7 +380,7 @@ parameterized with different update procedures.
|
|
|
|
|
(Handler -> [V] -> 1) -> |
|
|
|
|
1 |
|
|
|
|
modify node v m_cont m_leaf m_handler = |
|
|
|
|
walk-node node [dummy(v)] -- TODO: gross |
|
|
|
|
walk-node node [outermost(v)] |
|
|
|
|
where |
|
|
|
|
walk-node :: Node -> [V] -> 1 |
|
|
|
|
walk-node (cont, edges) vs = |
|
|
|
@ -406,6 +406,16 @@ parameterized with different update procedures.
@@ -406,6 +406,16 @@ parameterized with different update procedures.
|
|
|
|
|
let vs = projectMany v captureMap |
|
|
|
|
m_handler handler vs |
|
|
|
|
|
|
|
|
|
The `outermost` constructor applied to `v` at the top of `modify` is |
|
|
|
|
necessary because every path in the trie structure embodied in each |
|
|
|
|
`node` is a sequence of zero or more (move, check) pairs. Each "move" |
|
|
|
|
pops zero or more items from the stack and then pushes a sub-structure |
|
|
|
|
of the topmost stack element onto the stack; the "check" then examines |
|
|
|
|
the class of the new top element, abandoning the search if it does not |
|
|
|
|
match. Without some outermost constructor, there would be no possible |
|
|
|
|
"move", and the trie would have to be expressed as a single optional |
|
|
|
|
check followed by zero or more (move, check) pairs. |
|
|
|
|
|
|
|
|
|
**Definition.** The procedure `adjustAssertion` updates the copy-count |
|
|
|
|
associated with `v` in the given index, invoking callbacks as a |
|
|
|
|
side-effect if this changes the observable contents of the |
|
|
|
@ -499,8 +509,6 @@ interested in the `present` constructor.
@@ -499,8 +509,6 @@ interested in the `present` constructor.
|
|
|
|
|
|
|
|
|
|
- describe the cleanup function associated with a handler in the real implementation |
|
|
|
|
- figure out and describe scoped assertions / visibility-restrictions |
|
|
|
|
- check pop/index logic to ensure no off-by-ones |
|
|
|
|
- rearrange to avoid the `dummy(...)` wrappers |
|
|
|
|
|
|
|
|
|
<!-- |
|
|
|
|
|
|
|
|
|