No mco

[jeffreyrosenbluth]

Successfully removed monoid coproduct.
Should be OK to merge
Companion branch in -lib

[byorgey]

I'm not sure I believe this. Where do transformations get applied to styles now?

What happens with the following code:

square 1 # clipBy (square 1 # rotateBy (1/20)) # scale 2 # clipBy (square 2 # rotateBy (1/10)) # scale 2

?

[jeffreyrosenbluth]

good question. what should happen?

[jeffreyrosenbluth]

I think it happens in fromDTree.

[byorgey]

Here is what I get currently, which is what I would expect:

Does the no-mco branch yield the same results?

[jeffreyrosenbluth]

Unfortunately not. I'll have to look into it.

[byorgey]

oops, didn't mean to close.

[byorgey]

The problem is that transformations and styles are just accumulated in parallel, and transformations never have a chance to act on the styles. When converting to DTree you then take the accumulated transformation and put them in a node above the accumulated styles, but that does not respect the order in which the transformations and styles were applied in the first place.

I think the solution would be that transform needs to not just inject the transformation into the DownAnnots, but also apply the transformation to the style contained there. Then in converting to a DTree the style should be put above the transformation (since the transformations have already acted on the styles). However, I do not think that is possible given our current interface; the only way you can affect the d-annots on a DUALTree is by combining monoidally with another one.

So it looks like it really is more complicated than we thought. Probably at this point we should just abandon the idea for now.

[jeffreyrosenbluth]

Ah, I see. It was a good experiment though.
I just want to think a bit more if there is another possible solution.
Then we can close this, and rejoice in the fact that losing mco is a bonafied benefit of fixpoint :)

[byorgey]

=) Sounds good.

[jeffreyrosenbluth]

What if we rewrote the Transformable instance for QDiagram b v m so that the transform function still used applyD to transform the UpAnnots at the root of the tree, but then instead of injecting the the Transformation into the monoid coproduct, it was pushed down the tree and applied to all styles and prims?

[byorgey]

That would work (I think), but I don't like it, because it nullifies any efficiency benefit we get from accumulating transformations and then doing only a single accumulating pass down the tree. Imagine a large tree to which we apply repeated transformations (it's not that hard to construct a plausible scenario where this happens). Under your scheme we would have to traverse the entire tree for each transformation being applied, whereas currently applying each transformation is O(1) and we only have to traverse the tree once at the very end, accumulating transformations as we go down.

[jeffreyrosenbluth]

Fair enough. I'll close the this pull request. The only other solutions i can think of are isomorphic to mco or worse.

[byorgey]

OK. Incidentally, the reason the fixed-point formulation of diagrams can get away without monoid coproducts but also would not suffer from the performance penalty I described above, is that we essentially re-imagine the semantics of diagrams as a fold over a deep embedding. That is, imagine if diagrams were constructed as something like a DTree in the first place. Then there would be separate nodes for transformations and styles, and the order in which they were applied would be preserved simply by the structure of the tree, with no need for monoid coproducts. DUALTree forces us into a particular mold of having a single monoid that combines all the downwards-accumulating annotations. This works well if you just want to combine a bunch of monoids in parallel that don't interact at all. But that is not the case for transformations and styles, so we are forced to use a monoid coproduct to record their interleaving and shoehorn it into a single monoid. The way we are envisioning the fixedpoint semantics, however, gives us a somewhat freer hand, and we need not shoehorn transformations and styles into some particular intermediate representation; they just exist in a tree and we deal with them appropriately as we descend.

[jeffreyrosenbluth]

Thanks for explaining. That makes it very clear.

On Wed, Apr 9, 2014 at 3:35 PM, Brent Yorgey notifications@github.comwrote:

OK. Incidentally, the reason the fixed-point formulation of diagrams can
get away without monoid coproducts but also would not suffer from the
performance penalty I described above, is that we essentially re-imagine
the semantics of diagrams as a fold over a deep embedding. That is, imagine
if diagrams were constructed as something like a DTree in the first
place. Then there would be separate nodes for transformations and styles,
and the order in which they were applied would be preserved simply by the
structure of the tree, with no need for monoid coproducts. DUALTreeforces us into a particular mold of having a
single monoid that combines all the downwards-accumulating
annotations. This works well if you just want to combine a bunch of monoids
in parallel that don't interact at all. But that is not the case for
transformations and styles, so we are forced to use a monoid coproduct to
record their interleaving and shoehorn it into a single monoid. The way we
are envisioning the fixedpoint semantics, however, gives us a somewhat
freer hand, and we need not shoehorn transformations and styles into some
particular intermediate representation; they just exist in a tree and we
deal with them appropriately as we descend.

Reply to this email directly or view it on GitHubhttps://github.com//pull/62#issuecomment-40006930
.