I’m unable to make sense of this explanation. My u...
# compose
m
I’m unable to make sense of this explanation. My understanding of a gap buffer is that 1. It owns a buffer to store
T
elements in, 2. And has a notion of a ‘gap’ slice that’s uninitialised to be written to A naive minimal implementation can be given by a
struct { buffer, gap_range }
. I don’t understand how an array of (what I presume are) inlined serialisations of groups, and a ‘`slots` array’ implement a gap buffer. Moreover, what’s a slot?
They’re both gap buffers, and groups just correspond to ranges of slots?
Just the
slots
array is a gap buffer?
s
Slot corresponds to a single `remember`'ed value. Gap buffer is really irrelevant here, composition is just a tree that was represented as a flat array (think how
PriorityHeap
works). Gap buffer was there for faster updates, and is no longer there in the new
LinkTable
impl.
m
@shikasd This explanation seems, to me, to contradict what’s suggested by diagrams such as this. > Slot corresponds to a single `remember`'ed value I’ve been led to believe that a ‘group’ is a handle on, and corresponds to, a slice of ‘slots’ which are populated by serialised tree data. Are you saying that it’s just stuff cached by
remember
?
s
Here's a slide I used when talking about these things before, it is more correct if you detach from implementation details
Are you saying that it’s just stuff cached by
remember
?
Yeap, that and
composer.changed
, which is effectively internal
remember
Group is technically a slice of slots, but each slot is effectively a remembered value
The whole concept of group is to make sure that slots are added and removed correctly for positional memoization
m
@shikasd So to summarise, Q: …I’ve been led to believe that a ‘group’ is a handle on, and corresponds to, a slice of ‘slots’… A: Group is technically a slice of slots… Q: …[each slot is] just stuff cached by
remember
? A: effectively a remembered value Got it, thanks!