New syntax for initializer lists

[oowekyala]

Currently initializers are written like this state name: type(...), where what's inside the parentheses may be in the general case a (non-empty) list of expressions.
If the variable has a non-array type, then only a single expression is allowed. Then, the variable is assigned to this expression: eg state name: type (expr) translates to eg type name = expr in C.

But for variables with array types, the initialization syntax is very inconsistent across targets, and pretty irregular if you ask me, as we have to fall back on using {= =} in some cases.

For instance in C:

1. if there are several expressions, each of them is a component of the array: state arr: int[](1, 2) translates to int name[] = { 1, 2 };
2. if there is a single expression, then it is taken to be the whole array: state arr: int[](1) translates to int name[] = 1; which is invalid C code.
3. the only way to initialize an array with a single or zero components is with eg {= { 0 } =}.

The same kind of rules apply to (at least) Python.

I think this design lacks ergonomy for an end-user, because in any language, adding or removing an element from a list is usually done just by deleting/adding a comma and the element. This is an O(1), simple operation which does the same thing regardless of the final size of the list. In LF, there's a sharp edge when you remove an element and the list ends up being of size 1. If you don't wrap your remaining element in eg {= [ ... ] =} you may end up with a runtime type error: eg in Python, your state var will not be a list anymore. Similarly, when adding an element, why would one turn ({= {0} =}) into (0, 1) instead of ({= {0, 1} =}) if it's unclear why there are two different syntaxes...

Moreover, the implementation of code generators is more complicated as it is, as it would be with a consistent syntax to represent array values.

I think we should consider adding LF syntax for a "list literal", and changing the syntax of initializers in the following way:

list_lit    ::= '[' expr (',' expr)?  ']' | '[' ']'
expr        ::= literal | ... | list_lit
initializer ::= '(' expr ')' 

So an initializer would always be exactly one expression, which would simplify code generators. The expression may be a list literal, like [1, 2] or [1 msec, 2 msec] or [], which is translated to language-specific syntax, eg [1, 2] or std::vector<int> { 1, 2 }.

See also the very relevant discussion in #399

---

Edit: so using this syntax would look like so: state arr: int[] ([1, 2]). Eg in Python or C, this clarifies the difference between state arr([1 msec]) (which creates a python list/ C array) and state arr(1 msec) (which creates a target-specific time value).

[cmnrd]

I think this is an important discussion! But I don't quite understand how your proposed syntax would work. First, I think it is important to note that our syntax is not limited to one expression per initializer. At least in C++, we can write state foo: SomeClass(42, "bar"), which initializes foo by calling the constructor of SomeClass passing 42 and "bar". How would this work with your syntax? And how would I initialize an array with your syntax?

Probably it would also help to describe the concrete problems you currently have with the existing syntax in the Rust target.

[oowekyala]

At least in C++, we can write state foo: SomeClass(42, "bar"), which initializes foo by calling the constructor of SomeClass passing 42 and "bar". How would this work with your syntax? And how would I initialize an array with your syntax?

Thanks for pointing out that C++ needs a syntax for constructor calls.
With the syntax I'm proposing, in any target other than C++, you'd initialize an array variable like so: state arr: int[] ([1, 2]). Eg in Python or C, this clarifies the difference between state arr([1 msec]) (which creates a python list/ C array) and state arr(1 msec) (which creates a target-specific time value).

It's unclear to me how this would interplay with the C++ constructor syntax. In C++ when you want to declare a variable you write SomeClass foo(42, "bar");, right? Then I suppose this should still be expressed by state foo: SomeClass(42, "bar") in LF, as it's so similar it would be confusing otherwise. So, I guess the translation strategy would look like this:

state foo: int[] (1, 2)        -> std::vector<int>(1, 2)
state foo: int[] { 1, 2 }      -> std::vector<int> { 1, 2 }
state foo: int[] ([1, 2])      -> std::vector<int> { 1, 2 }

I guess C++ would still need the { } syntax because it may be used with any class that has a proper constructor

Something we could consider is to replace initializer parentheses with an = sign. This would require wide changes in our tests and doc, but it doesn't alias with the C++ constructor call syntax, and is more mainstream (eg all of our current target languages use = for variable initialization). It would look like state foo: int = 2, or state foo: int[] = [1, 2]. Then the syntax foo: SomeClass(1, 2) would be reserved to C++, or maybe to OO target languages as shorthand for a constructor call.

[oowekyala]

Probably it would also help to describe the concrete problems you currently have with the existing syntax in the Rust target.

So Rust has convenient syntax for array initializers which looks like so: [ item ; count ], which initializes an array with count copies of the item. It could be nice for this to be supported by LF too, although we could use it with {= =} anyway in Rust.

Currently the Rust target uses a different implementation strategy which causes more problems than this (this is what we talked about last time with Marten Christian). But since it's WIP anyway and worse than the C/Python strategy described above I'm not sure it's worth describing here

[lhstrh]

Based on our discussion on Tuesday, it seems that having list expressions as first order citizens in LF as proposed by @oowekyala is likely to cause more issues than they would solve. For the time being, we can just escape lists in Rust initializers with {==}. In the long run, however, we should support lists (and also Python's dicts) directly in our syntax and treat them as lliterals. It is likely that all we'd need to do (in the grammar) is change the definition of Value