Unbounded layout of `group`ed Line fails

[sjakobi]

> layoutUnbounded = layoutPretty defaultLayoutOptions { layoutPageWidth = Unbounded }
> layoutUnbounded $ group Line
SFail

[sjakobi]

The possibility of Fail is introduced by group via changesUponFlattening:

> group Line
Union Fail Line

https://github.com/quchen/prettyprinter/blob/4d51362d7ea8bca0fe9e7ffec2ccd8fcd0065c0d/prettyprinter/src/Data/Text/Prettyprint/Doc/Internal.hs#L552-L555

The Unbounded layout causes the maximum width for the fitting predicates to be set to Nothing:

https://github.com/quchen/prettyprinter/blob/4d51362d7ea8bca0fe9e7ffec2ccd8fcd0065c0d/prettyprinter/src/Data/Text/Prettyprint/Doc/Internal.hs#L1789-L1803

selectNicer then selects Fail because the fitting predicates always choose the first option when the maximum width is Nothing:

https://github.com/quchen/prettyprinter/blob/4d51362d7ea8bca0fe9e7ffec2ccd8fcd0065c0d/prettyprinter/src/Data/Text/Prettyprint/Doc/Internal.hs#L1644-L1647

https://github.com/quchen/prettyprinter/blob/4d51362d7ea8bca0fe9e7ffec2ccd8fcd0065c0d/prettyprinter/src/Data/Text/Prettyprint/Doc/Internal.hs#L1710-L1713

[sjakobi]

I assume there are good reasons for group to introduce the possibility of Fail. So I think a reasonable fix would be to let selectNicer choose y when x is Fail.

[Gabriella439]

@sjakobi: My understanding is that this behavior is intentional for group Line to fail because it needs to contract the string to a newline-free version. See the documentation for group:

(group x) tries laying out x into a single line by removing the contained line breaks;

In other words, you need to protect all occurrences of Line (or hardline, which is equivalent) with flatAlt to provide a newline-free alternative that group can fall back to. The alternative cannot itself contain obligatory newlines.

dhall had a similar issue in the past due to misusing group in this way:

dhall-lang/dhall-haskell#272

[sjakobi]

Interesting!

Note that bounded layouts don't fail though:

> layoutPretty defaultLayoutOptions $ group Line
SLine 0 SEmpty
> layoutSmart defaultLayoutOptions $ group Line
SLine 0 SEmpty

And I don't really see why the layout ought to fail, when the failure of the first alternative can be detected and the second alternative can be returned instead.

[sjakobi]

Also, the documentation of hardline shows an example where the line break is not protected via flatAlt:

https://github.com/quchen/prettyprinter/blob/4d51362d7ea8bca0fe9e7ffec2ccd8fcd0065c0d/prettyprinter/src/Data/Text/Prettyprint/Doc/Internal.hs#L504-L517

[Gabriella439]

@sjakobi: I think it is because prettyprinter is interpreting "unbounded" layout as "render on one line at all costs because there is no right margin", and then fails if there is an obligatory newline in the document

[sjakobi]

Hmm. I still find this interpretation very hard to believe, not least because I don't see any documentation supporting it.

For example this documentation for Unbounded seems to indicate that users may introduce hard line breaks, while e.g. softline will always be layouted not to introduce a line break.

https://github.com/quchen/prettyprinter/blob/4d51362d7ea8bca0fe9e7ffec2ccd8fcd0065c0d/prettyprinter/src/Data/Text/Prettyprint/Doc/Internal.hs#L1610-L1611

Seems like the documentation needs more clarification though!

[Gabriella439]

@sjakobi: I agree that the documentation and/or the Unbounded name are perhaps misleading, but it's actually a reasonable behavior if you ask me. Otherwise there would be no way for the user to specify that they want to force a single-line representation.

[sjakobi]

Here's another bit that IMO indicates that the current behaviour is not intended:

https://github.com/quchen/prettyprinter/blob/4d51362d7ea8bca0fe9e7ffec2ccd8fcd0065c0d/prettyprinter/src/Data/Text/Prettyprint/Doc/Internal.hs#L84-L88

---

Even if it were intended, I'd like to argue that the behaviour should be changed so

render* . layout{Pretty,Smart} (LayoutOptions Unbounded) . group

is a total function as long as the input Doc doesn't contain Fail:

In some situations like dhall-lang/dhall-haskell#1508 you want a Doc that is unconditionally rendered with a line break.

As long as layouting and rendering that document can result in an error, it seems that it would be the responsibility of the author of that Doc to warn users of this possibility. That would IMHO be a disincentive to rely on prettyprinter at all.