Support comma after last element of a tuple

[dcz-self]

This is purely a quality-of-life improvement. In the course of one evening learning and commenting out function arguments, I hit this at least a dozen times, with a somewhat unhelpful message:

Unexpected token: ')'
Expected one of the following: id constructor natlit intlit i8lit i16lit i32lit i64lit u8lit u16lit u32lit u64lit floatlit f16lit f32lit f64lit charlit '-' '(' '{' '#[' '_' true false

Coming from Rust, it's relevant in day-to-day manual coding, and not just parsing generated code.

[athas]

I have considered this. The downside is that the syntax conflicts with tuple sections, which we don't currently have, but might in the future. We must decide: is allowing trailing commas more important than tuple sections?

If we support trailing commas for tuples, we should also support them for arrays and records.

[nhey]

I'd like to see this feature solely because it's ergonomic for editing (easy yank-paste, lines have a consistent structure when using multiple cursors, and the likes). But I was unfamiliar with tuple sections, so I'm not aware of any subtle benefits to weigh against this.

[dcz-self]

Adding trailing commas does not prevent tuple sections from ever happening, but it does prevent using the same syntax space. Sacrificing a little consistency, I can envision having a special syntax for tuple sections like starting with a special marker, e.g. #(a, b, , d).

[athas]

We could also support something more general, like record sections, which would have a syntax like {x=}. Since tuples are records, it would be possible to write {0=a,1=b,2=,3=d}. Not the most delicious syntax, but good enough.

Taking a more general view, I very rarely miss tuple sections in Futhark, the way I would miss them in Haskell, perhaps because Futhark encourages a different style of programming.

If we add trailing commas for tuples, it makes sense to add them whenever we use comma separation: tuples, records, and array literals. And then it really does start to outweigh the potential advantage of tuple sections.

[Munksgaard]

If we add trailing commas for tuples, it makes sense to add them whenever we use comma separation: tuples, records, and array literals.

I agree.

[athas]

Apart from expressions, should trailing commas also be allowed for tuple types, patterns, and whereever else they can appear?

[Munksgaard]

Are there any downsides? If not, I would be for it. Consistency is nice.

[nhey]

In my mind, the argument for allowing trailing commas applies to any kind of comma-separated listing---even if they are not on adjacent lines. Unless there are other downsides as Philip points out.

[athas]

Also indexing? Is a[i,j,] something we wish to allow?

[nhey]

That one is less clear to me. I could see that being mistaken for a 3d-array indexed by a[i,j,:].

[athas]

Well, a[i,j,] and a[i,j,:] would do the same thing (assuming a is at least three dimensional), so it's not really a mistake to read it that way.

[nhey]

Right, the potential confusion is when a is 2d. For me, the benefit of trailing commas is mostly when the listing spans multiple lines. I rarely put indices on separate lines. But I don't see anything inherently wrong with a[i,j,].

[athas]

I have a prospective implementation in #2076. Feedback welcome.

[nhey]

Nice. I look forward to rebuilding. Apparently a[i,j,] is also allowed in numpy.