Stream: ideas

Topic: roc format too much line wrapping?

Brian Teague (Jan 19 2024 at 02:01):

Can we avoid line wrapping math and comparison operators when running roc format?

isApproxEq = \value, refValue, { rtol ? 0.00001, atol ? 0.00000001 } -> value
    <= refValue
    && value
    >= refValue
    || Num.absDiff value refValue
    <= atol
    + rtol
    * Num.abs refValue

versus

isApproxEq = \value, refValue, { rtol ? 0.00001, atol ? 0.00000001 } -> value <= refValue
    && value >= refValue
    || Num.absDiff value refValue <= atol + rtol * Num.abs refValue

Luke Boswell (Jan 19 2024 at 02:15):

I don't love the way the formatter currently does this.

Richard Feldman (Jan 19 2024 at 02:35):

I like that idea! :thumbs_up:

Richard Feldman (Jan 19 2024 at 02:36):

so basically special-case || and &&

Brendan Hansknecht (Jan 19 2024 at 02:44):

Probably should be:

isApproxEq = \value, refValue, { rtol ? 0.00001, atol ? 0.00000001 } ->
    value <= refValue
    && value >= refValue
    || Num.absDiff value refValue <= atol + rtol * Num.abs refValue

Maybe allow parens to avoid the line break if you want?

isApproxEq = \value, refValue, { rtol ? 0.00001, atol ? 0.00000001 } ->
    (value <= refValue && value >= refValue)
    || Num.absDiff value refValue <= atol + rtol * Num.abs refValue

Brendan Hansknecht (Jan 19 2024 at 02:45):

Though not sure what you do if someone writes a really long line of just math. Cause really this probably needs smart reflow at a certain length.

Brian Teague (Jan 19 2024 at 03:15):

Agreed, I think a line wrapping a "unit of work / expression" after n characters would help.
That would probably work for the value <= refValue wrapping after ->
(for short one liners, keep the code after ->, otherwise after n characters, wrap the body to the next line)
It would also wrap a math operator for long math expressions.
For the ->, we could wrap if the body is two or more lines or goes past the n character limit?

Brendan Hansknecht (Jan 19 2024 at 03:17):

exactly

Agus Zubiaga (Jan 19 2024 at 19:46):

:100: I have wanted this in elm-format for years

Sky Rose (Jan 20 2024 at 14:30):

Maybe it doesn't need to be a special case for || and &&. Can this be based on precedence instead? || and && have the least precedence of the expression, so they get wrapped first. After that, the lines are short enough so there's no more wrapping, but if not, you could keep wrapping higher precedence operators.

Sky Rose (Jan 20 2024 at 14:34):

Side note: some languages require parens for expressions with both || and &&, because the order of operations isn't clear to many human readers. For us, it could be a compiler warning.

And having parens with very high precedence would help this precedence-based formatting cause line breaks like Brendan mentioned above.

Kevin Gillette (Jan 20 2024 at 15:26):

I agreed with Brendan's tweak to Brian's overall sentiment: I don't like the first sub-expression being on the same line as the -> when more follows on subsequent lines.

Kevin Gillette (Jan 20 2024 at 15:28):

The entire lambda body should always either wholly exist on the same line as the arguments, or wholly occupy subsequent lines.

Joshua Warner (Jan 26 2024 at 02:20):

FWIW I was experimenting recently with the smart reflow, primarily in implementing Philip Wadler's "A Prettier Printer" paper.

These formatting rules should be straight-forward to implement under that system.

I've been playing around with a parser + formatter (+ canonicalizer) rewrite for Roc in the background. Not quite ready to share yet - but this stuff is definitely on my mind.

Last updated: Jun 16 2026 at 16:19 UTC