Ininitializer and Expression Syntax

[oowekyala]

This is a spec draft to rationalize the changes in #544. Please comment if you disagree, need more details, or agree. With consensus on this spec it will be easier to finish #544.

Motivation

Our current syntax for expressions and variable initialization is rather limited. Currently, expressions can only be values, which means literals, time values, target code, or parameter reverences. This is the corresponding grammar rule:

Value:
    (parameter=[Parameter] | time=Time | literal=Literal | code=Code);

This neglects the fact that expressions in our target languages can be much more complex. For instance, in Python and Rust [1, 2, 3] is a valid expression denoting a list of integers. While technically all target language expressions are supported within the target code delimiters {=...=}, we should make an effort to support the most common expressions natively.

With a more powerful expression syntax, we also need to revise our syntax for variable initialization. Currently, state variables and parameters are initialized like follows:

   state <name>: <type>(<init>)

Where <init> can be a Value or a comma separated sequence of Values.

This syntax has various problems:

1. It neglects the fact that in most languages assignment with = is used for initialization.
2. With a more powerful expression syntax initialization can become ambiguous. For instance, to initialize a state variable as a Python tuple (1, 2, 3) one would need to write state foo((1, 2, 3)). It would be much clearer to write instead state foo = (1, 2, 3).
3. It is not clearly defined what initialization with a list of multiple comma separated values means (e.g. state foo(1, 2, 3)) and our targets make different interpretation. In C and Python, the incentive appears to be to interpret the sequence as a list of values. However, it is entirely unclear what a list of values is in the target language (e.g. tuple vs. list in Python). An extended expression syntax would empower the programmers to specify the precise list type they need. In C++, the sequence of Values is interpreted very differently. It is used as an argument list and each given value is passed to the constructor of the variable type.

Specification

Initializer Syntax

The grammar for both parameters and state variables should support the following initialization syntaxes:

• name: <type> () or name: <type> (<expr>) or name: <type> (<expr>, <expr>, ...)
• name: <type> {} or name: <type> {<expr>} or name: <type> {<expr>, <expr>, ...}
• name: <type> = <expr>

Depending on the target, the validator imposes various restrictions:

• C, Python, Rust and TypeScript only allow initialization with the assignment operator.
• C++ supports all three syntaxes for initialization and multiple expressions are interpreted as multiple constructor arguments. The different variants would be code generated likes this:
  • foo: int(42) -> int foo(42);
  • foo: int{42} -> int foo{42};
  • foo: int = 42 -> int foo = 42;
    This distinction is very important in C++, as each variant has a slightly different meaning. The last variant is currently not supported, but is particularly important as the assignment operator can be overloaded.
• Optional: Rust could use the parenthesis and brace based initializer syntax as a shortcut for tuple and struct initialization.

Expression Syntax

These are possible syntax extensions for what stands for an <expr> in the above.

C/C++:

• Initializer lists: {} or {<expr>} or {<expr>, <expr>, ...}
• designator expressions: .name = <expr>

Python:

• tuples: (<expr>,) or (<expr>, <expr>, ...).
• lists: [], or [<expr>] or [<expr>, <expr>, ...]
• dicts: {}, or {<key>: <expr>} or {<key>: <expr>, <key>: <expr>, ...}

Rust:

• tuples and lists as in Python
• record initializers: Name{<key>: <expr>, <key>: <expr>, ...}

Typescript:

• like Python???

All languages:

• array access: name[<expr>]
• function or constructor calls: name() or name(<expr>) or name(<expr>, <expr>, ...)

Note that this list is not complete. There is much more we could support, but we should probably take it step by step.

The grammar rules should be designed such that they allow all these different expression styles without making assumptions about their nature in the target language. We need validator rules to reject styles that are not supported by a given target language. Further, we will need a class in the code generator that takes care of interpreting expressions and that can be overloaded for the various targets.

[cmnrd]

I updated Clément's post providing more details on why the change is needed and what exactly we envision for the different targets.