Delayed subtrees #47
Merged
Delayed subtrees #47
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
added 5 commits
November 10, 2013 13:45
Delayed subtrees consist of a continuation which generate a QDiagram when given the accumulated d-annotation at that point in the tree. Useful for things which need to know the final transformation applied to them before deciding what diagram to generate. The prototypical use case is arrows: see diagrams/diagrams-lib#112 . However, I hope this may be useful for other things as well: for example, diagrams which scale normally until hitting some maximum or minimum size, at which point they refuse to scale any further (or more generally diagrams which scale as some non-linear function of the transformation applied to them). The only downside is that the u-annotation must be fixed ahead of time---doing otherwise requires a more general solution for constraint solving.
…more general mkQD'
The idea is that the function in a DelayedLeaf should produce a diagram which already takes the non-frozen transformation into account, so we must drop them when we reach a DDelay node (otherwise we end up applying them twice).
|
I have a bit more work to do on the corresponding |
This was referenced Nov 13, 2013
|
Still building diagrams-doc to do final validation. Will report on the outcome here. |
|
Looks good to me. |
|
Looks good to me as well |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This pull request contains some extra machinery, the original motivation for which was to fix diagrams/diagrams-lib#112, but which I hope may turn out to be more generally useful.
The basic idea is that in addition to having
Prims at the leaves of aQDiagram, we can now also have a function of typeDownAnnots v -> QDiagram b v m. That is, a leaf which expands to aQDiagramonce it knows the final context (including transformations and style) in which it is to be rendered. The prototypical example is an arrow with scale-invariant head and tail, which needs to know the final transformation applied to it before it can figure out exactly how to draw the shaft. (Other possibilities for the future include things like diagrams which do not scale linearly, e.g. they scale only up to a certain maximum size and then stop getting bigger.)The tradeoff is that, as with scale-invariant wrappers, we must come up with an envelope and trace up front---there is no way to delay their generation too (short of a more general solution for constraint solving), since we need them to construct the rest of the
QDiagram.There is a bit of trickiness with making sure transformations do not get applied twice. When compiling a
QDiagramto a rawDTree(which now includes expansion of delayed leaves), we mark any expansion points with a special node. Later, when crunching theDTreedown to anRTree, we drop any accumulated transformations upon encountering one of those special nodes. The idea is that the tree underneath that special node, being the expansion of a delayed leaf, must have already taken those transformations into account, so we do not want to apply them again.