Consider several elements per line in long lists of small elements #302

New Issue

2020-05-02T17:45:01+02:00

expipiplus1 commented

2020-05-02 17:45:01 +02:00

(Migrated from github.com)

It might be hard to come up with a consistent rule for this. Nevertheless I think the former is much easier to read (and doesn't eat a whole page in my editor)

foo =
  [ 0.0, -0.5, 1.0, 1.0, 1.0
  , 0.5, 0.5, 0.0, 1.0, 0.0
  , -0.5, 0.5, 0.0, 0.0, 1.0
  , 1.0, 0.0, 0.0, 0.0, 0.0
  ]

foo =
  [ 0.0
  , -0.5
  , 1.0
  , 1.0
  , 1.0
  , 0.5
  , 0.5
  , 0.0
  , 1.0
  , 0.0
  , -0.5
  , 0.5
  , 0.0
  , 0.0
  , 1.0
  , 1.0
  , 0.0
  , 0.0
  , 0.0
  , 0.0
  ]

It might be hard to come up with a consistent rule for this. Nevertheless I think the former is much easier to read (and doesn't eat a whole page in my editor) ```haskell foo = [ 0.0, -0.5, 1.0, 1.0, 1.0 , 0.5, 0.5, 0.0, 1.0, 0.0 , -0.5, 0.5, 0.0, 0.0, 1.0 , 1.0, 0.0, 0.0, 0.0, 0.0 ] foo = [ 0.0 , -0.5 , 1.0 , 1.0 , 1.0 , 0.5 , 0.5 , 0.0 , 1.0 , 0.0 , -0.5 , 0.5 , 0.0 , 0.0 , 1.0 , 1.0 , 0.0 , 0.0 , 0.0 , 0.0 ] ```

👍 1

tfausak commented

2020-07-21 14:19:01 +02:00

(Migrated from github.com)

It's tough to say when a list should be formatted with one line per element versus many elements per line. One (kind of clunky) way around this is to concatenate a bunch of sub-lists. For example:

foo = mconcat
  [ [0.0, -0.5, 1.0, 1.0, 1.0]
  , [0.5, 0.5, 0.0, 1.0, 0.0]
  , [-0.5, 0.5, 0.0, 0.0, 1.0]
  , [1.0, 0.0, 0.0, 0.0, 0.0]
  ]

It's tough to say when a list should be formatted with one line per element versus many elements per line. One (kind of clunky) way around this is to concatenate a bunch of sub-lists. For example: ``` hs foo = mconcat [ [0.0, -0.5, 1.0, 1.0, 1.0] , [0.5, 0.5, 0.0, 1.0, 0.0] , [-0.5, 0.5, 0.0, 0.0, 1.0] , [1.0, 0.0, 0.0, 0.0, 0.0] ] ```

👍 1

expipiplus1 commented

2020-07-22 03:53:09 +02:00

(Migrated from github.com)

Yeah, that is quite clunky and not necessarily without runtime overhead or a clarity cost.

Perhaps a neat way of allowing the user to signal the wrapping would be to break after the first empty comment in the list and at multiples of that index, for example:

foo =
  [ 0.0, -0.5, 1.0, 1.0, 1.0 --
  , 0.5, 0.5, 0.0, 1.0, 0.0
  , -0.5, 0.5, 0.0, 0.0, 1.0
  , 1.0, 0.0, 0.0, 0.0, 0.0
  ]

or

foo =
  [ 0.0, -0.5, 1.0, 1.0, 1.0, 0.5 --
  , 0.5, 0.0, 1.0, 0.0, -0.5, 0.5 
  , 0.0, 0.0, 1.0, 1.0, 0.0, 0.0
  , 0.0, 0.0
  ]

This would allow the user to select the wrapping in a low visual overhead way. I think that clang format has some similar behaviour, at the very least I remember using empty comments to force wrapping of lists when they'd usually be put on one line.

Not quite sure how discoverable this is, but perhaps that ok as this is probably a niche issue anyway.

If it had to be done without hints from the programmer I'd say that lists should be:

On one line if possible.
One line per element if any element is itself "long" (for some threshold to bikeshed, perhaps as small as 4 or 5 characters).
As square as possible with as few elements as possible on the last line.

Yeah, that is quite clunky and not necessarily without runtime overhead or a clarity cost. Perhaps a neat way of allowing the user to signal the wrapping would be to break after the first empty comment in the list and at multiples of that index, for example: ```haskell foo = [ 0.0, -0.5, 1.0, 1.0, 1.0 -- , 0.5, 0.5, 0.0, 1.0, 0.0 , -0.5, 0.5, 0.0, 0.0, 1.0 , 1.0, 0.0, 0.0, 0.0, 0.0 ] ``` or ```haskell foo = [ 0.0, -0.5, 1.0, 1.0, 1.0, 0.5 -- , 0.5, 0.0, 1.0, 0.0, -0.5, 0.5 , 0.0, 0.0, 1.0, 1.0, 0.0, 0.0 , 0.0, 0.0 ] ``` This would allow the user to select the wrapping in a low visual overhead way. I *think* that clang format has some similar behaviour, at the very least I remember using empty comments to force wrapping of lists when they'd usually be put on one line. Not quite sure how discoverable this is, but perhaps that ok as this is probably a niche issue anyway. If it had to be done without hints from the programmer I'd say that lists should be: - On one line if possible. - One line per element if any element is itself "long" (for some threshold to bikeshed, perhaps as small as 4 or 5 characters). - As square as possible with as few elements as possible on the last line.

Sign in to join this conversation.

No Milestone

No project

No Assignees

1 Participants

Notifications

Due Date

The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: hexagoxel/brittany#302