a note about this:
Richard Feldman said:
actually https://github.com/roc-lang/roc/blob/98df325d76b6b743c6b01f399bbbeaaf0d8108fa/www/wip_new_website/main.roc#L107 is a better example of the downside, would need to have parens across multiple lines if
homeLinkwas moved ahead one spot:nav [ariaLabel "primary"], [ (div [id "top-bar-links"], [ (a [href "/wip/tutorial"], [text "tutorial"]), (a [href "/wip/install"], [text "install"]), (a [href "/wip/community"], [text "community"]), (a [href "/wip/docs"], [text "docs"]), (a [href "/wip/donate"], [text "donate"]), ]), homeLink, ],so in general DSLs that wanted to use function calls to make the elements would get a lot more parens!
now that we have more whitespace sensitivity because of !, we have an option here that's at least worth discussing: we could make the following Just Work
nav [ariaLabel "primary"], [
div [id "top-bar-links"], [
a [href "/wip/tutorial"], [text "tutorial"]
a [href "/wip/install"], [text "install"]
a [href "/wip/community"], [text "community"]
a [href "/wip/docs"], [text "docs"]
a [href "/wip/donate"], [text "donate"]
]
homeLink
]
the way it would work is that if you go down a line without indenting, that's treated as a standalone list element
so basically instead of trailing commas, you have no commas at the end of lines in a list
(could work the same way for records)
CoffeeScript had something like this as I recall
so this would mean we could do comma-separated function arguments, which has been a consistent recurring request from beginners that seems totally reasonable except for this DSL downside
F# lists work like that also. Except it uses semicolons for the single line variant.
Overall, I think I prefer the status quo, but I get the consistency argument
yeah I can anticipate beginners being confused by this design too :sweat_smile:
what if, the status quo stayed as the correct syntax, but in some cases when it's unambiguous, it still compiled with a warning, and the formatter fixed the commas. If it is ambiguous, it'd be a compile error. That could cut down on chasing syntax errors.
is [text "..."] a sibling element to a [...] in the above example?
Last updated: Jun 16 2026 at 16:19 UTC