This is to match the recent introduction of the `@program` annotation for
external functions (i.e. functions that may be called externally, passing to
them inputs through the input files).
This PR adds not just that annotation, but a more general notion of annotation
as a new kind of token of the form `@<identifier>`, and with the ability to
precede each function declaration with zero or more such annotations.
The fact that it has been added as a token to the lexical grammar, means that
there cannot be any whitespace or comments between the `@` and the identifier.
If that is undesired, we can add it to the syntactic grammar instead, defining
an annotation as consisting of the (new) symbol token `@` followed by an
identifier token.
We can of course extend annotations with arguments at some point, if needed.
This adds tuple types, tuple expressions (which build tuples from components),
and tuple component expressions (which access tuple components).
Based on previous discussions on this topic, 1-tuples are excluded. This
exclusion is done at the grammar level, since it is the kind of requirement that
is easily captured in a context-free grammar.
Based on a recent discussion on Slack, and on some related slight terminological
changes in the documentation of the Aleo instructions, this commit similarly
improves the Leo nomenclature for expressions involving the logical operators.
The attribute 'bitwise' for `&` and `|` and `^` has been dropped, since the
operations also operate on booleans besides integers.
Given that the operation and method names `or` and `xor` for inclusive and
exclusive disjunctions (as opposed to `ior` and `xor`), the unqualified
'disjunction' now refers to the inclusive one.
The non-strict `&&` and `||` are now called 'conditional' (as done in other
languages), and thus the ternary one has been expanded to 'conditional ternary'.
This does not change the Leo language; it just improves the nomenclature derived
from the grammar.
Based on a recent discussion on Slack, and on some related slight terminological
changes in the documentation of the Aleo instructions, this commit similarly
improves the Leo nomenclature for expressions involving the logical operators.
The attribute 'bitwise' for `&` and `|` and `^` has been dropped, since the
operations also operate on booleans besides integers.
Given that the operation and method names `or` and `xor` for inclusive and
exclusive disjunctions (as opposed to `ior` and `xor`), the unqualified
'disjunction' now refers to the inclusive one.
The non-strict `&&` and `||` are now called 'conditional' (as done in other
languages), and thus the ternary one has been expanded to 'conditional ternary'.
This does not change the Leo language; it just improves the nomenclature derived
from the grammar.
These are for the recently added shift and bitwise logical operators. They
should have been also included in the rule `symbol` for symbol tokens. This
commit remedies that.
These would flatten to nothing, component-wise.
This requirement actually slighly simplifies the grammar, avoiding the `[ ... ]`
around the circuit component declarations (in a circuit declaration) or the
circuit component initializers (in a circuit expression).
Also renames pre-existing (generic) function calls to 'free function calls', now
that we are effectively introducing a new kind of functions, namely (associated)
static functions, distinguished from free (i.e. non-associated) functions.
Also introduces notion of named type, as a type that has a name, which may be
either a keyword (e.g. `u8`, `address`) or an identifier (e.g. `Pedersen64`).
Introduce the notion of postfix expression in the grammar, which will also go
well with some expected upcoming extensions to Leo.
This does not change the Leo language. It does not necessarily involve modifying
the parser. It merely reorganizes some rules slightly.
This adds shift (`<<` `>>`) and bitwise logical (`&` `|` `^`) operators.
Their precedence is between the additive and ordering operations, in this order
(higher to lower):
- ... others, to additive
- `<<` and `>>`
- `&`
- `|`
- `^`
- ... others, from ordering
This is consistent with Rust, but not with C and Java, both of which make the
bitwise logical operators lower-precedence than equalities.
The previous ABNF rule names for `conjunctive-expression` and
`disjunctive-expression` have been renamed to be more consistent with the newly
added ones. Also, the rule names "abbreviate" 'conjunctive' and 'disjunctive'
with 'and' and 'or', otherwise the names were a bit too long.
Since these are a method-like syntax for unary and binary operators (as in fact
these are represented as operators in the AST), the nomenclature 'operator call'
seems appropriate, at least for now. There is no need yet to introduce notions
of associated functions (and constants).
The rules explicitly distinguish between unary and binary ones, corresponding to
unary and binary operators. This lets us exclude right away calls with too many
arguments, and gives us a way to distinguish the two kinds.
A trailing comma is allowed at the end of the one argument of binary operator
calls, if one is really inclined to use it, just for syntactic consistency with
other calls (namely, function calls).
Prohibit line terminators inside string literals. (This does not prohibit
escapes for line feed and/or carriage return; it prohibits actual line feeds and
carriage returns, which would break the string literal across lines.)
Explicate line terminators in block comments, so that an accurate line count can
be obtained more readily from the CSTs. (This is more relevant to the ACL2
formal development than to the Rust implementation, which does not have explicit
CSTs.)
Also reorder slightly some rules within the file.
In input and output files, literals are actually insufficient to represent the
most negative values of the signed integer types.
Given that we are likely to need richer forms of input and output expressions
anyways, at this point it seems best to allow any expression at the grammatical
level, and add static semantic requirements on the allowed expressions. As done
with all the other requirements, these will be stated in the Leo Reference,
formalized in ACL2, and enforced in the Leo compiler.
