Stream: ideas

Topic: Don't require comma when doing multiline lists?

Jared Cone (Mar 25 2022 at 19:19):

I was wondering if it would be doable to not require commas between items when doing multiline imports, exports, lists, and records. Like:

imports [
  pf.Task
  pf.Stdout
]

Record : {
  count : I32
  sum : I32
}

jan kili (Mar 26 2022 at 00:42):

I'm in for this

Richard Feldman (Mar 26 2022 at 01:23):

what happens if the record field definition has a super long type, and needs to be multiline?

Jared Cone (Mar 26 2022 at 01:25):

Backslash for line continuation?

Jared Cone (Mar 26 2022 at 01:27):

Just assuming definitions that long are rare.

Jared Cone (Mar 26 2022 at 01:28):

Or assume if 2nd line is indented further then it's a continuation of 1st line?

Richard Feldman (Mar 26 2022 at 01:40):

Jared Cone said:

Or assume if 2nd line is indented further then it's a continuation of 1st line?

CoffeeScript does this. It worked well as I recall, but there was definitely a backlash about how much indentation mattered in that language.

Richard Feldman (Mar 26 2022 at 01:40):

in Roc indentation currently only matters in two places: defs and where branches

Richard Feldman (Mar 26 2022 at 01:41):

https://coffeescript.org/#objects-and-arrays

Jared Cone (Mar 26 2022 at 02:51):

Admittedly Ive never done significant work in a whitespace significant language, but I've always thought leveraging whitespace in the language syntax would be a benefit, since we tend to require for human readability anyways

Kevin Gillette (Mar 26 2022 at 04:29):

If defs and where branches didn't have extra indentation, would that make the syntax ambiguous? (is the extra indentation just conventional, or truly significant)? If truly significant, is it desirable for the language as a whole to have significant indentation just due to those two places? Would something like .. as an "indentation token" serve well to disambiguate?

Richard Feldman (Mar 26 2022 at 04:31):

personally I think it's worth it, yes - but feel free to propose alternative ideas!

Kesanov (Mar 26 2022 at 07:25):

I never really understood the arguments against significant indentation.
You can make the compiler accept only multiples of 3 spaces as valid indentation.
Then you won't encounter any copy-paste bugs or tab problems.
It also makes the code correctly formatted, diminishing the need for an external formatter.
I also have a suspicion that it was part of the reason why Python took off.

In the end it always boils down to personal bias. Which makes any discussion on this topic very tiring.
My personal rule of thumb is: Good code* should be easier to write by default.
(*Hopefully the code that is written the most often.)

This applies to immutability over mutability. And it also applies to multiline statements.

fibonacci n =
  a = fibonacci (n-1)
  b = fibonacci (n-2)
  a + b

-- The above should be easier to write than

fibonacci n =
  a = fibonacci (n-1); b = fibonacci (n-2)
  a + b

It seems to apply to lists too

list = [
  123
  2
  3
]

-- The above should be easier to write than

list = [
  123
  2,3
]

Those are my 2c

Last updated: Jun 16 2026 at 16:19 UTC