Quoting Kenton Varda (2019-06-07 09:45:37) > On Thu, Jun 6, 2019 at 7:41 PM Prasanth Somasundar > <[1][email protected]> wrote: > > Hey guys, > I've updated [2]the doc with a new write API suggestion. The gist is > that writes never happen to the byte array. Instead, we build a virtual > proto on top of the byte array that's accessed first for any > modifications. It's built using `Maybe` all the way down. `Nothing` > implies that there are no changes from the byte array. When you > transmit/convert it into bytes, the framework performs a "merge" > operation before sending over the wire. We will also provide this merge > operation to advanced users who wish to manually do this compaction at > some points. >
> This sounds like almost a standard design pattern in pure-functional > languages -- amortize modifications by storing them to a side structure > with periodic merges. I feel like I read about this kind of approach in > Osaki's "Purely Functional Data Structures" (though it's been a > while...). > Which is to say, it seems like a pretty reasonable approach. :) > -Kenton You can't really do the amortization tricks from Okasaki's work in Elm, since they rely critically on being able to do lazy evaluation -- which the Elm runtime doesn't provide. So amortization in Elm can only work if you use the data structure in a "single-threaded" way. I think you may be on to something, but it needs fleshing out -- it's still not clear to me how it would actually work. -Ian -- You received this message because you are subscribed to the Google Groups "Cap'n Proto" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. Visit this group at https://groups.google.com/group/capnproto. To view this discussion on the web visit https://groups.google.com/d/msgid/capnproto/155992703316.22693.11237841619064919888%40localhost.localdomain.
