AleoHQ/leo
1
1
Fork 0
mirror of https://github.com/AleoHQ/leo.git synced 2024-12-18 23:02:35 +03:00
Code Issues Packages Projects Releases Wiki Activity

Merge pull request #1693 from AleoHQ/abnf-circ-vs-block

Browse Source 
[ABNF] Add two extra-grammatical requirements.
This commit is contained in:
Collin Chin 2022-03-19 15:25:05 -07:00 committed by GitHub
commit cf06671b12
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
2 changed files with 52 additions and 8 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

30
docs/grammar/README.md
View File

@ -622,10 +622,9 @@ Go to: _[decimal-digit](#user-content-decimal-digit)_;
An identifier is a non-empty sequence of
letters, (decimal) digits, and underscores,
starting with a letter.
It must not be a keyword: this is an extra-grammatical requirement.
It must also not be or start with `aleo1`,
because that is used for address literals:
this is another extra-grammatical requirement.
It must not be a keyword or a boolean literal,
and it must not be or start with `aleo1`;
these are extra-grammatical requirements, indicated in the comment.
<a name="identifier"></a>
```abnf
@ -1515,9 +1514,20 @@ It may stop there, or it may continue with an alternative block,
or possibly with another conditional statement, forming a chain.
Note that blocks are required in all branches, not merely statements.
The test expression must not be, or start with, a circuit construction.
This is an extra-grammatical requirement, indicated in the comment.
Without this restriction, for example `if c {} {}` would be ambiguous:
it could be either a single conditional statement with test `c {}`,
or a conditional statement with test `c`
followed by an empty block statement.
(Type analysis can disambiguate this,
but it happens after parsing,
and we want unambiguous parsing.)
<a name="branch"></a>
```abnf
branch = %s"if" expression block
; but expression is not circuit-construction...
```
Go to: _[block](#user-content-block), [expression](#user-content-expression)_;
@ -1537,11 +1547,23 @@ A loop statement implicitly defines a loop variable
that goes from a starting value (inclusive) to an ending value (exclusive).
The body is a block.
The second expression must not be, or start with, a circuit construction.
This is an extra-grammatical requirement, indicated in the comment.
Without this restriction,
for example `for i in 0 .. c {} {}` would be ambiguous:
it could be either a single loop statement with ending bound is `c {}`,
or a loop statement with ending bound `c`
followed by an empty block statement.
(Type analysis can disambiguate this,
but it happens after parsing,
and we want unambiguous parsing.)
<a name="loop-statement"></a>
```abnf
loop-statement = %s"for" identifier ":" type
%s"in" expression ".." [ "=" ] expression
block
; but second expression is not circuit-construction...
```
Go to: _[block](#user-content-block), [expression](#user-content-expression), [identifier](#user-content-identifier), [type](#user-content-type)_;

30
docs/grammar/abnf-grammar.txt
View File

@ -444,10 +444,9 @@ hexadecimal-digit = decimal-digit / "a" / "b" / "c" / "d" / "e" / "f"
; An identifier is a non-empty sequence of
; letters, (decimal) digits, and underscores,
; starting with a letter.
; It must not be a keyword: this is an extra-grammatical requirement.
; It must also not be or start with `aleo1`,
; because that is used for address literals:
; this is another extra-grammatical requirement.
; It must not be a keyword or a boolean literal,
; and it must not be or start with `aleo1`;
; these are extra-grammatical requirements, indicated in the comment.
identifier = letter *( letter / decimal-digit / "_" )
; but not a keyword or a boolean literal or aleo1...
@ -924,7 +923,18 @@ identifier-or-identifiers = identifier
; or possibly with another conditional statement, forming a chain.
; Note that blocks are required in all branches, not merely statements.
; The test expression must not be, or start with, a circuit construction.
; This is an extra-grammatical requirement, indicated in the comment.
; Without this restriction, for example `if c {} {}` would be ambiguous:
; it could be either a single conditional statement with test `c {}`,
; or a conditional statement with test `c`
; followed by an empty block statement.
; (Type analysis can disambiguate this,
; but it happens after parsing,
; and we want unambiguous parsing.)
branch = %s"if" expression block
; but expression is not circuit-construction...
conditional-statement = branch
/ branch %s"else" block
@ -934,9 +944,21 @@ conditional-statement = branch
; that goes from a starting value (inclusive) to an ending value (exclusive).
; The body is a block.
; The second expression must not be, or start with, a circuit construction.
; This is an extra-grammatical requirement, indicated in the comment.
; Without this restriction,
; for example `for i in 0 .. c {} {}` would be ambiguous:
; it could be either a single loop statement with ending bound is `c {}`,
; or a loop statement with ending bound `c`
; followed by an empty block statement.
; (Type analysis can disambiguate this,
; but it happens after parsing,
; and we want unambiguous parsing.)
loop-statement = %s"for" identifier ":" type
%s"in" expression ".." [ "=" ] expression
block
; but second expression is not circuit-construction...
; An assignment statement is straightforward.
; Based on the operator, the assignment may be simple (i.e. `=`)