Anton Trunov

OK, since this chapter discusses the crowdfunding contract: > Sending a message is done using the ``send`` instruction, which takes a list of messages as a parameter. Since we will...

There is an example of a multi-message `send` in ZRC-2 (https://github.com/Zilliqa/ZRC/blob/master/reference/FungibleToken.scilla#L240). We might want to reuse it.

> I also think it'll be good to have these implementations in our standard library This is a great suggestion! 👍

> Not sure here, as this will also influence fields (persistent state variables) in contracts and traits — they use semicolons in their declarations as of now It's fine, though....

Added a couple more bullet points: - Writing to storage variables should look differently compared to analogous operations on temporary (stack) variables, e.g. `storage_var

- More concise syntax for map expressions and operations: map literals (`{1: "foo", 2: "bar"}`), map access (`map[key]`), map updates (`map[key] = val` and `map[key] += inc`, etc.)

- Syntactic support for sending messages, e.g. instead of `send(SendParameters{value: amount, to: self.owner, mode: mode})` we can have something like `send {value: amount, to: self.owner, mode: mode}`;

- Disallow initializing maps with `emptyMap` by default, in other words `m: map;` without the corresponding entry in `init` should produce a compilation error;

@novusnota I was thinking we can have a tool that combines Tact v1 parser and Tact v2 code formatter: this way we can migrate contracts if we only have _local_...

- Do not allow using `struct`, `message`, `contract`, `init`, `bounced`, `external`, `primitive`, `map`, and `receive`, `get` (or whatever we change those to) as identifiers and make those keywords, e.g. `let...