Skip to content
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

Open
wants to merge 9 commits into
base: master
Choose a base branch
from
18 changes: 18 additions & 0 deletions prettyprinter/src/Prettyprinter/Internal.hs
Original file line number Diff line number Diff line change
Expand Up @@ -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]
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
-- Note [Group: Optimial placement of Union and loss of information]
-- Note [Group: Optimal placement of Union and loss of information]

Copy link
Collaborator

Choose a reason for hiding this comment

The 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?

--
-- 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
Copy link
Collaborator

Choose a reason for hiding this comment

The 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 Doc that we need to rebuild on top of the new Union?!

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah, I forget the cost of recreating the Doc, that whole line is guesswork anyway and should probably be removed. I was only thinking in traversal depth.

-- 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.
Copy link
Collaborator

Choose a reason for hiding this comment

The 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 Union Fail (or a new dedicated marker) on top of the result of group?

Copy link
Contributor Author

@1Jajen1 1Jajen1 Mar 26, 2021

Choose a reason for hiding this comment

The 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.
Expand Down