Stream: ideas

Topic: `[..foo]` spread operator for list creation

Sam Mohr (Aug 24 2024 at 16:10):

As part of the new .. syntax proposal, one of the supported features is allowing for Javascript-style spreads of other lists to create a new list. We have a couple syntax options:

-- This would run `quickSort lessEq` and concatenate the resulting list
-- to a single element called `pivot` and then concatenate that to the
-- list resulting from `quickSort greater`
newList = [..quickSort lessEq, pivot, ..quickSort greater]
-- This would do the same thing, but avoid visual ambiguity on whether
-- `..quickSort lessEq` is spreading the `quickSort` function itself, or
-- `quickSort lessEq` as a result of a function call
newList = [..(quickSort lessEq), pivot, ..(quickSort greater)]

Does anyone have preference between these two syntaxes, or any alternative ideas on how this should look? Do you think it's a bad idea in the first place? Comments below!

Brendan Hansknecht (Aug 24 2024 at 16:20):

I think it is a great idea. I definitely prefer requiring parens for function calls. Reserving raw ..value for actual lists.

Sam Mohr (Aug 24 2024 at 16:26):

You're calling parents "explicit AST parents", a.k.a requiring parentheses?

Brendan Hansknecht (Aug 24 2024 at 17:03):

If calling a function that returns a list and then apply .. to it, I think it should be required to be wrapped in parens. so this would be valid:
[..(quicksort left), ..someList, pivot]

Brendan Hansknecht (Aug 24 2024 at 17:04):

This would not be valid:
[..quicksort left, ..someList, pivot]

Sam Mohr (Aug 24 2024 at 17:11):

I think with these shorter examples I'm okay with or without parentheses, but as soon as we have a few pipelines of data, I think we need the parentheses yes

Sam Mohr (Aug 24 2024 at 17:13):

Unless we do a spread shorthand you could pipe to, like |> &.., but that seems like Haskell level of operators, so let's not

Brendan Hansknecht (Aug 24 2024 at 17:14):

Yeah, I think always enforcing the parens is a simple and consistent rule and it will be wanted any time an expression gets complex. But we definitely could allow both and then bias the results with the formatter.

Richard Feldman (Aug 24 2024 at 17:57):

I like the idea of requiring parens and seeing if there's demand for making them optional

Richard Feldman (Aug 24 2024 at 17:57):

bc that's a nonbreaking change to introduce

Last updated: Jun 16 2026 at 16:19 UTC