In the currently restricted version of Leo, this is necessary for the numerals
in affine group literals to be tokens.
No change necessary to the lexer/parser, which already handle this properly.
Expression statements were removed from the rule for statements, but the rule
for expression statements itself had not been removed. This commit fixes that.
Since we do not have tuple in this version of Leo, we cannot have expression
statements, because normally expressions used as statements would have to return
the empty tuple, since we disallow throwing away values in Leo.
Since this pre-testnet3 version of Leo does not support tuple types, and since a
missing function type is meant to be interpreted as the empty tuple type `()` in
future versions of Leo, it seems appropriate to require a function output type
in this version of Leo. We could instead default to a different type
(e.g. bool), but it seems cleaner to require it for now, and make it optional
later.
This mirrors, in pre-testnet3, the change in PR #1699 in testnet3.
Since in pre-testnet3 we have fewer kinds expressions, the category of postfix
expressions disappears altogether with this re-classification.
This does not change the language. It only renames two related rule names:
function-input => named-parameter
function-inputs => named-parameters
According to the new nomenclature, there are function parameters, which are self
parameters and named parameters: the nomenclature is clear and "symmetric".
The problem with the previous nomenclature is that both self and named
parameters are inputs, not just the named ones.
These are needed to make parsing unambiguous. They require the test of a
conditional statement and the ending bound of a loop statement to not be or
start with a circuit expression.
This is obtained by removing features from the grammar currently in the testnet3
branch.
The documentation comments have been removed to keep the file smaller and
simpler to read, as readers of this file should be already familiar with Leo.
Furthermore, that documentation material is being moved to the Leo Language
Reference.
This commit also folds the format string grammar (for console print strings)
into (a separate section of) the same file, again for simplicity. The previous
separate small file (and generated markdown) for format strings has thus been
removed.
Given that arithmetic literals are now all typed in the grammar, we need
numerals to be listed as tokens. Otherwise, array dimensions and tuple indices
would not be tokens, but they must be.
This applies both to the rule name and to the terminology used for that, namely
for a non-empty sequence of decimal digits.
While 'natural' was meant to describe a natural number (i.e. a non-negative
integer: 0, 1, 2, ...), it is perhaps not a familiar term to many users.
On the other hand, 'integer', while often used in programming languages for this
kind of thing, is not ideal as integers may be negative.
Also, assuming type inference, a lone numeral like `17` may actually not denote
an integer number at all, because it may actually denote a group element if type
inference turns it into `17group`, and group elements are not integers.
All in all, 'numeral' seems like a good term, also according to its dictionary
definition. It is used in the Java grammar to denote this kind of thing, for
instance.
If, in the future, we want to allow hexadecimal, octal, or binary notation, we
could rename this to `decimal-numeral`, introduce `hexadecimal-numeral`,
`octal-numeral`, and `binary-numeral`, and `numeral` as the union of these.
This does not change the grammar. It merely updates some text in the comments,
which shows a rule that was changed at some point but its copy in the comments
was not properly updated.
Thanks to @bendyarm for noticing this.
This removes the rule for `integer` and uses `natural` for all numeric literals.
Otherwise, lexing would be context-dependent for no good reason.
This is consistent with the lexer and parser of the Leo compiler.
Note that, for instance, `-1field` is not a literal, but rather a unary
expression where `-` is applied to the literal `1field`. This is consistent with
other languages too.
Types are now required in variable and constant declarations (including for loop
variables), and for literals (i.e. there are no longer untyped literals).
This "merges" the two previous slightly different notions of array type
dimensions and array expression dimension(s) into one notion of array
dimensions, in which the dimensions have to be natural numbers. (Previously,
array type dimensions were allowed to be unspecified (via underscores), while
array expression dimensions had to be specified.)
The purpose of this RFC is to:
- Provide user documentation for this feature in a more accessible way than
in the text for https://github.com/AleoHQ/leo/pull/1410, particularly after
that PR is closed.
- Record the discussion in a recent meeting about broadening the notion of const
function to map const arguments to const results rather than requiring const
arguments, as a possible future extension.
This was referring to a previous version of the rule, and presumably it is the
reason why 'true' and 'false' were accidentally re-added to the keyword rule.
Add an alternative in which we go to methods directly. This seems more likely at
this point, given that we seem to have a fairly simple and quick way to support
methods on scalar types that does not involve turning scalar types into circuit
types.
Explicate how the initially proposed design is consistent with Java, and how the
native implementations live in separate files in that design. This better paves
the way to the more recent variant of this proposal, currently discussed under
alternatives but that may be eventually "swapped" if that's also the rest of the
team's consensus.
Based on consensus within the Leo team, now the RFC prescribes the
value-preserving semantics. The discussion on value-changing semantics has been
moved to the 'Alternatives' section. Other text has been adapted and improved to
reflect the chosen approach (before, value-preserving and value-changing were
presented as two possible candidates for type casts).
