Simplify dual

[cchalmers]

Don't merge yet. See diagrams/dual-tree#7.

Up annotations have changed because they no longer need Deleteable or MList. There's are now valid traversals over the up annotations of a diagram (before they where invalid lenses) query is now also a traversal.

DNode and RNode have been removed, folding a DUALTree is now done in a single pass using foldDia and foldDia' folding functions.

[cchalmers]

I'm not 100% about the primed versions (foldDia', foldDUAL'), could someone take a look at make sure they make sense?

I think I'll wait on matrix transforms until this is merged.

[bergey]

The docs for foldDia and foldDia' mention a "monadic result", while the types suggest you mean "monoidal". Which is right?

[cchalmers]

Monoidal :) Always mix them up when I type them.

[byorgey]

I think this (and the primed version below) needs a Haddock comment.

[cchalmers]

Sure. I'm still debating whether or not to export them (I'm currently not).

[byorgey]

Getting rid of Deletable and just changing the u annotation at the root makes me nervous. In fact, getting rid of the u annotations interspersed throughout the tree and just having a single u value stored at the root (as in the simplify-dual branch of dual-tree) makes me nervous. I can see that it works, currently, but I worry about painting ourselves into a corner. In particular I am thinking about the ability to edit diagrams --- i.e. to reach down into the tree, modify something, and then rebuild the tree. The idea before was that we would have the cached u values that we could use to rebuild the tree and recompute the proper u value at the root with only a logarithmic amount of work.

[cchalmers]

Yes, this is a potential problem.

I actually (tried to) touch on the problem with rebuilding up annotations a little in #39 but never came up with a solution.

I need to think about this a bit more.

[jeffreyrosenbluth]

What is the status of this branch?

[cchalmers]

It looks like a lot of the simplifying to DUALTree isn't actually a good idea if we want to edit diagrams. We can still do the continuation style diagram building. I'll come back to it in a week or two and see how it looks with cached us.

[cchalmers]

So I've been thinking about this a bit and I can't come up with a solution I'm happy with. It's becoming clear to me that traversals over sub diagrams is not simple. There's a couple of options I can see:

• Keep it like this, with u annotations exclusively at the top level. This is probably the simplest solution, partly because u annotations are not limited to monoid homomorphisms (so we can make valid lenses easily). The drawback is any changes to the u annotations when modifying sub-diagrams won't be carried back up.
• Store u annotations at every branch so they can be used to rebuild the u annotation correctly. The drawback is the u annotations have Deletable wrappers and don't (can't?) make valid lenses. (Currently doing an over envelope id would clone the current envelope and ignore subsequent changes to sub-diagram u annotations (breaking the setter law)).

I just had an idea of adding another option to the dual tree to allow modifying the u annotation:

  | UpModify u (u -> u) (NE d u a l)

which would (I think) let us satisfy setter laws (but not the lens laws) and remove Deletable from u annotations.

I've started another branch with u annotations on everything, I guess I'll try the new UpModify and see how it goes. Any thoughts?