Update to explain the "dummy" outermost wrapper constructor

This commit is contained in:
Tony Garnock-Jones 2018-10-20 21:54:58 +01:00
parent 035eb06a9d
commit a178ec5ddf
1 changed files with 12 additions and 4 deletions

View File

@ -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.
(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.
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.
- 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
<!--