Optional trailing comma for list entities

[beutlich]

Proposal: Allow optional trailing comma in lists

It could be beneficial to allow an optional trailing comma in array, vector, matrix, enumeration, and other list-like constructs in Modelica, similar to features in Python and Julia. This improves readability, diff-friendliness, and consistency in multi-line definitions.

Proposed Grammar Updates

enum-list :
  enumeration-literal { "," enumeration-literal } [ "," ]

import-list :
  IDENT { "," IDENT } [ "," ]

argument-list :
  argument { "," argument } [ "," ]

component-list :
  component-declaration { "," component-declaration } [ "," ]

expression-list :
  expression { "," expression } [ "," ]

Note: output-expression-list remains unchanged:

output-expression-list :
  [ expression ] { "," [ expression ] } 

Benefits

1. Diff-friendly: Adding or removing elements in multi-line lists no longer requires editing the previous line, reducing unnecessary version control noise.

type Color = enumeration(
  Red,
  Green,
  Blue,  // optional trailing comma
);

2. Consistency: Aligns with common practices in modern languages like Python, Julia, and Go.

3. Tooling-friendly: Simplifies code generation and parser implementation by removing the “special case” for the last element.

This enhancement is fully backward-compatible, as all existing code without trailing commas continues to parse correctly.

[henrikt-ma]

This is a good proposal, but from where I come an optional leading comma could be considered even more desirable. When written like this,

type Color = enumeration(
, Red // optional leading comma
, Green
, Blue
);

all the comma boilerplate is nicely aligned and does not add clutter to the actual entries.

Fortunately, I think it should be possible to allow both an optional leading and an optional trailing comma at the same time.

[beutlich]

I have to admit I never typed an optopnal leading comma so far, but use optional trailing comma whenever allowed, e. g. in C++ enumerations or in Python wich also has a linter to enforce it.

[HansOlsson]

I have to admit I never typed an optopnal leading comma so far, but use optional trailing comma whenever allowed, e. g. in C++ enumerations or in Python wich also has a linter to enforce it.

Same.

However, I realized that we could generalize it for matrices as well.

The obvious would be to generalize to semi-colon, which seems useful for the same reasons:

X=[ 
      A , B;
      C,  D;
     ]

and comma also make sense in simple cases:

X=[ 
       A , 
       B, 
       C, 
     ]

but I'm not sure the combination will be useful:

X=[ 
       A, B, C, ;
       D, E, F, ;
     ]

Note: In generally don't put opening brackets on their own line, but the formatting is a bit off here.

[HansOlsson]

following this separator vs terminator discussion.

Note that output-expression-list is syntactically unchanged, but semantically it would be a backwards compatible change.

Currently (,b,)=foo(); indicates that you use the second argument and ignore the first and third output argument, which requires that foo has at least three output arguments. If we allow trailing commas it should be legal even if foo only has two output arguments.

This also indicates that the output-expression-list would cause semantic issues with a leading comma; and to me that would make leading comma confusing.

[henrikt-ma]

I don't agree that there would be a semantical difference to output-expression-list. It is not (despite nomenclature) a list-like construct, and therefore I don't think there is any serious risk of confusion that it would have its own semantics for optional commas.

[HansOlsson]

Same rule for ; in matrices as for , - and handle enumeration, and array constructions.

Hans: a bit confusing for the following - normally used for assumed zero-matrix:

[A, B;
 C,   ];

However, optional semi-colon seems to work fine for matrices.

Three options:

• No change
• Trailing
• Leading or trailing

Which constructs: enumerations, array construct and semi-colon for matrix. Function arguments? Import-list? Modifications? (Annotations should be included either as function argument or modifications.)
If done before test-implementations we should be ready to revisit if test-implementations reveal something.

No issue for partial function application, right?

[henrikt-ma]

We also have this problem with the production rules in the grammar, where there is a lack of symmetry between alternatives:

modification :
   class-modification [ "=" modification-expression ]
   | "=" modification-expression

In OCaml this is solved using an optional leading |, which applied to the production rule above would make it look like this:

modification :
   | class-modification [ "=" modification-expression ]
   | "=" modification-expression

So: I think the production rules in the grammar also belong to this discussion, and they are a nice example of when an optional leading separator can be very useful.

[HansOlsson]

We also have this problem with the production rules in the grammar, where there is a lack of symmetry between alternatives:

modification :
   class-modification [ "=" modification-expression ]
   | "=" modification-expression

In OCaml this is solved using an optional leading |, which applied to the production rule above would make it look like this:

modification :
   | class-modification [ "=" modification-expression ]
   | "=" modification-expression

So: I think the production rules in the grammar also belong to this discussion, and they are a nice example of when an optional leading separator can be very useful.

The natural interpretation of that (both for leading and trailing | ) would be that modification could match the empty production.
If we look at the grammar for modification (and mostly for class-modification) we see that it is currently handled in another way, so currently we have:

declaration :
   IDENT [ array-subscripts ] [ modification ]

element-modification :
   name [ modification ] description-string

modification :
   class-modification [ "=" modification-expression ]
   | "=" modification-expression

We could have allowed empty modifications instead of optional non-empty modifications leading to:

declaration :
   IDENT [ array-subscripts ] modification

element-modification :
   name modification description-string

modification :
   | class-modification [ "=" modification-expression ]
   | "=" modification-expression

I'm aware that ϵ in grammars can be a complication, so I'm not proposing this change - just stating that it would be a natural interpretation, especially when nested like inside some-equation

Note that we could even simplify it to:

modification :  [ class-modification ] [ "=" modification-expression ]

which would be more symmetric than the current one, but the cost of allowing ϵ.

(BTW - I'm not overly satisfied with the indentation of the grammar products, but I think we can solve that separately.)

[henrikt-ma]

I'm aware that ϵ in grammars can be a complication, so I'm not proposing this change - just stating that it would be a natural interpretation, especially when nested like inside some-equation

Yes, of course we'd have to explain the convention in or next to the table near the top of https://specification.modelica.org/master/modelica-concrete-syntax.html#lexical-conventions.