+ Extend the parser to recognize the multiline f-strings, which the
documentation already implies will work.
The syntax is like:
```
x = 'hello'
y = 'world'
msg = f'''This is a multiline string.
Sending a message: '@x@ @y@'
'''
```
which produces:
```
This is a multiline string.
Sending a message: 'hello world'
```
+ Added some f-string tests cases to "62 string arithmetic" to exercise
the new behavior.
"Stored by value" is more correct way to explain that example.
Mutable vs immutable means that you cannot mutate the value (e.g. list vs tuple in Python), and the example shows that `var2` is actually mutable.
Copying/storing a reference vs value is what what matters in the assignment, in Python `a=b` means `a` and `b` are references to the same list, while in meson `a=b` copies the value of `b` into `a`.
* WIP: Document formal Meson grammar
* Various little fixes [skip ci]
1) Add missing logical_not_expr
2) 'in' and 'not in' are valid relational operators at least for dicts
3) dictionary keys can be expressions, but kwarg names cannot
4) typo logical_end_expression -> logical_and_expression
5) Make jump statements only allowed inside an iteration statement
* Rework EBNF style [skip ci]
As there is no good order for the productions, just go alphabetically.
The EBNF style was changed to match the one the Python lark project
uses, that is colons for productions and terminals enclosed in double
quotes.
* Add missing production for unary operators [skip ci]
* Add production for multiline strings [skip ci]
* Properly define terminal symbols [skip ci]
Depending on the EBNF flavor, regex can be used to describe the terminal
symbols. Lark allows this, and as it was mentioned as a possible user of
this grammar, let's follow its flavor here. Most regexes used are easily
human-readable, and we can always add comments to more complicated ones.
* Small changes to which expressions can be used where [skip ci]
Let the grammar be very general. The type system then has to check, that
the used expression really evaluates to the correct type. Even if we
know today that assignment expressions always evaluate to None (and can
therefore only be used as a toplevel expression in an expression
statement), this needn't be the case forever. So this way, the grammar
stays stable even if such changes were made.
* Rework function argument list production [skip ci]
* Be more verbose for production names [skip ci]
Rename expr -> expression, stmt -> statement, op -> operator, program ->
build_definition. Also adjust some list productions.
* Add paragraph about syntax stability promises [skip ci]
* docs: document unrecognized escape sequence behaviour [skip ci]
Document that unrecognized escape sequence behaviour is like python, not
C.
* Don't try to decode invalid hex escape sequences
Don't try to decode escape sequences which should contain a sequence of
hex digits, but don't, throwing a python exception. These will treated
literally instead.
* Extend test case to cover invalid escape sequences
This comes up now and again when people try do do something like:
meson.build:
```meson
my_sources = ['foo.c']
subdir('subdir')
executable('foo', my_sources)
```
subdir/meson.build:
```meson
my_sources += ['bar.c']
```
The "if" statement only covers a small set of the possible ways in
which conditionals can be written, since it leaves the use of
"and", "or" and "not" to the "Logical Operations" section. However,
this is likely to be of interest to those reading about "if" statments,
so move the "logical operations" section up to immediately follow it.
This change also puts in the use of the "!=" operator in the example
to widen the variety of combinations shown.
In CommonMark, there are no backslash escapes in code spans, so only two backslashes in the source document are necessary to produce two backslashes in the output document.
Peter Lesslie