-
Notifications
You must be signed in to change notification settings - Fork 36
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Rework group and remove fail #126
base: master
Are you sure you want to change the base?
Changes from 8 commits
99553dc
714557d
1f89ce8
8811af2
ec330bc
6e47410
fc9d54f
a588c97
4a1a4c7
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -630,6 +630,24 @@ group x = case x of | |
-- See https://github.com/quchen/prettyprinter/issues/22 for the corresponding | ||
-- ticket. | ||
|
||
-- Note [Group: Optimial placement of Union and loss of information] | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Could you add a reference to this note next to the other note reference in |
||
-- | ||
-- group will create a 'Union' in place or not at all. A 'Union' for the layout | ||
-- algorithm represents a branch, and if that branch ends up failing, it would | ||
-- be beneficial to keep it as short as possible. Thus group could make an extra | ||
-- effort to push the resulting 'Union' further down or eliminate the branch | ||
-- altogether. The result would be a fewer and smaller branches and thus cheaper | ||
-- failure for the layout algorithm. | ||
-- This approach would not increase the cost of a call to group at all as | ||
-- changesUponFlattening already traverses deep enough already, however, due to | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This isn't very obvious. Wouldn't the new approach increase the "length" of the There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Ah, I forget the cost of recreating the |
||
-- an unrelated property of group, placing the resulting 'Union' further down or | ||
-- not at all will harm subsequent calls to group. Currently when calling group | ||
-- with a document that cannot be flattened or an already flat document the Doc | ||
-- will not change at all. This looses information as subsequent calls to group | ||
-- have to come to the same conclusion again and thus retraverse. If we now | ||
-- place the Union (the only evidence that we have done some work) deeper in the | ||
-- tree, subsequent calls will have to retraverse even more nodes. | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Couldn't this extra work / loss of information be avoided by adding another There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. That's what I was thinking as well. Even right now, without placing Unions deeper) doing so would avoid re-traversing failing or already flat documents. This + placing unions at the optimal depth could be interesting to play around with. |
||
|
||
data FlattenResult a | ||
= Flattened a | ||
-- ^ @a@ is likely flatter than the input. | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.