In the paper on compact regions (http://ezyang.com/papers/ezyang15-cnf.pdf), we find the following:
However, if we want to apply a functional update to this tree, we may want to specify the already existing compact region so we can reuse any already compacted shared data... appendCompact, like newCompact, fully evaluates a; however, it copies the result into the same compact region as Compact b. Additionally, it short-circuits the evaluation/copying process if a subgraph is already in the target compact region.
However, in the docs for both the compact library and the ghc-compact library (still only on phabricator), this short-circuiting behavior is not mentioned. Did this end up in the final implementation on was it dropped? If it is implemented, I think it's worth mentioning in the docs for `compactAdd`. -Andrew Martin
This will help you avoid copying when the value contains pointers into
Nevermind. The docs for compactAdd say:
the compact region
I had missed that.
On Wed, May 10, 2017 at 9:43 PM, Andrew Martin
In the paper on compact regions (http://ezyang.com/papers/ezyang15-cnf.pdf ), we find the following:
However, if we want to apply a functional update to this tree, we may want to specify the already existing compact region so we can reuse any already compacted shared data... appendCompact, like newCompact, fully evaluates a; however, it copies the result into the same compact region as Compact b. Additionally, it short-circuits the evaluation/copying process if a subgraph is already in the target compact region.
However, in the docs for both the compact library and the ghc-compact library (still only on phabricator), this short-circuiting behavior is not mentioned. Did this end up in the final implementation on was it dropped? If it is implemented, I think it's worth mentioning in the docs for `compactAdd`.
-Andrew Martin
-- -Andrew Thaddeus Martin
participants (1)
-
Andrew Martin