AleoHQ/leo
1
1
Fork 0
mirror of https://github.com/AleoHQ/leo.git synced 2024-11-15 03:14:05 +03:00
Code Issues Packages Projects Releases Wiki Activity
93e9686972
leo/docs/grammar/abnf-grammar.txt

452 lines
13 KiB
Plaintext
Raw Normal View History

mirate grammar from staging
2022-02-02 21:07:27 +03:00
; Copyright (C) 2019-2022 Aleo Systems Inc.
[ABNF] Add full copyright/licensing notice. Make the change to the .txt file.
2021-04-21 01:52:08 +03:00
; This file is part of the Leo library.
consistent keyword order and names
2021-03-23 19:11:42 +03:00
[ABNF] Add full copyright/licensing notice. Make the change to the .txt file.
2021-04-21 01:52:08 +03:00
; The Leo library is free software: you can redistribute it and/or modify
; it under the terms of the GNU General Public License as published by
; the Free Software Foundation, either version 3 of the License, or
; (at your option) any later version.
consistent keyword order and names
2021-03-23 19:11:42 +03:00
[ABNF] Add full copyright/licensing notice. Make the change to the .txt file.
2021-04-21 01:52:08 +03:00
; The Leo library is distributed in the hope that it will be useful,
; but WITHOUT ANY WARRANTY; without even the implied warranty of
; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
; GNU General Public License for more details.
consistent keyword order and names
2021-03-23 19:11:42 +03:00
[ABNF] Add full copyright/licensing notice. Make the change to the .txt file.
2021-04-21 01:52:08 +03:00
; You should have received a copy of the GNU General Public License
; along with the Leo library. If not, see <https://www.gnu.org/licenses/>.
consistent keyword order and names
2021-03-23 19:11:42 +03:00
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
; Lexical Grammar
; ---------------
[ABNF] disallow bidi override codepoints
2022-04-14 12:04:20 +03:00
ascii = %x0-7F
safe-nonascii = %x80-2029 / %x202F-2065 / %x2070-D7FF / %xE000-10FFFF
[ABNF] Improve doc comment about bidi exclusions. This mentions embeddings and isolates besides overrides, in accordance with the official terminology at https://www.unicode.org/reports/tr9/. This update was discussed and agreed with @bendyarm. Note: The Leo Reference includes text explaining these exclusions, with links to the document above as well to the web site and paper about Trojan source exploits.
2022-04-22 06:02:25 +03:00
; excludes bidi embeddings/overrides/isolates
; and excludes high/low surrogates
[ABNF] disallow bidi override codepoints
2022-04-14 12:04:20 +03:00
character = ascii / safe-nonascii
consistent keyword order and names
2021-03-23 19:11:42 +03:00
[ABNF] Add some documentation. For both uniformity and clarity of reference from other documentation comments, add some documentation comments next to every single character definition. No change to the grammar itself.
2021-04-22 07:56:27 +03:00
horizontal-tab = %x9 ; <HT>
consistent keyword order and names
2021-03-23 19:11:42 +03:00
[ABNF] Add some documentation. For both uniformity and clarity of reference from other documentation comments, add some documentation comments next to every single character definition. No change to the grammar itself.
2021-04-22 07:56:27 +03:00
line-feed = %xA ; <LF>
consistent keyword order and names
2021-03-23 19:11:42 +03:00
[ABNF] Add some documentation. For both uniformity and clarity of reference from other documentation comments, add some documentation comments next to every single character definition. No change to the grammar itself.
2021-04-22 07:56:27 +03:00
carriage-return = %xD ; <CR>
consistent keyword order and names
2021-03-23 19:11:42 +03:00
[ABNF] Add some documentation. For both uniformity and clarity of reference from other documentation comments, add some documentation comments next to every single character definition. No change to the grammar itself.
2021-04-22 07:56:27 +03:00
space = %x20 ; <SP>
consistent keyword order and names
2021-03-23 19:11:42 +03:00
[ABNF] Add some documentation. For both uniformity and clarity of reference from other documentation comments, add some documentation comments next to every single character definition. No change to the grammar itself.
2021-04-22 07:56:27 +03:00
double-quote = %x22 ; "
consistent keyword order and names
2021-03-23 19:11:42 +03:00
[ABNF] Add character literals. These are a new kind of literals that denote char values.
2021-05-13 04:41:58 +03:00
single-quote = %x27 ; '
[ABNF] Fix/improve handling of line terminators. 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.
2022-06-12 01:56:49 +03:00
line-terminator = line-feed / carriage-return / carriage-return line-feed
consistent keyword order and names
2021-03-23 19:11:42 +03:00
[ABNF] Fix/improve handling of line terminators. 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.
2022-06-12 01:56:49 +03:00
whitespace = space / horizontal-tab / line-terminator
[ABNF] Move a rule a bit within the file. No changes to rules. Just putting two rules close that are somewhat related (as they are used to define comments).
2021-05-13 05:11:31 +03:00
[ABNF] Fix/improve handling of line terminators. 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.
2022-06-12 01:56:49 +03:00
not-line-feed-or-carriage-return =
%x0-9 / %xB-C / %xE-7F / safe-nonascii
; anything but <LF> or <CR>
consistent keyword order and names
2021-03-23 19:11:42 +03:00
[ABNF] Fix/improve handling of line terminators. 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.
2022-06-12 01:56:49 +03:00
not-star-or-line-feed-or-carriage-return =
%x0-9/ %xB-C / %xD-29 / %x2B-7F / safe-nonascii
; anything but * or <LF> or <CR>
[ABNF] Add string literals. These are a new kind of literals that denote arrays of characters, which is how we initially represent strings in Leo.
2021-05-13 05:04:11 +03:00
[ABNF] Fix/improve handling of line terminators. 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.
2022-06-12 01:56:49 +03:00
not-star-or-slash-or-line-feed-or-carriage-return =
%x0-9 / %xB-C / %xD-29 / %x2B-2E / %x30-7F / safe-nonascii
; anything but * or / or <LF> or <CR>
consistent keyword order and names
2021-03-23 19:11:42 +03:00
[ABNF] Fix/improve handling of line terminators. 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.
2022-06-12 01:56:49 +03:00
not-double-quote-or-backslash-or-line-feed-or-carriage-return =
%x0-9 / %xB-C / %xD-21 / %x23-5B / %x5D-7F / safe-nonascii
; anything but " or \ or <LF> or <CR>
consistent keyword order and names
2021-03-23 19:11:42 +03:00
comment = block-comment / end-of-line-comment
block-comment = "/*" rest-of-block-comment
[ABNF] Fix/improve handling of line terminators. 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.
2022-06-12 01:56:49 +03:00
rest-of-block-comment =
"*" rest-of-block-comment-after-star
/ not-star-or-line-feed-or-carriage-return rest-of-block-comment
/ line-terminator rest-of-block-comment
consistent keyword order and names
2021-03-23 19:11:42 +03:00
[ABNF] Fix/improve handling of line terminators. 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.
2022-06-12 01:56:49 +03:00
rest-of-block-comment-after-star =
"/"
/ "*" rest-of-block-comment-after-star
/ not-star-or-slash-or-line-feed-or-carriage-return rest-of-block-comment
/ line-terminator rest-of-block-comment
consistent keyword order and names
2021-03-23 19:11:42 +03:00
mirate grammar from staging
2022-02-02 21:07:27 +03:00
end-of-line-comment = "//" *not-line-feed-or-carriage-return
consistent keyword order and names
2021-03-23 19:11:42 +03:00
keyword = %s"address"
/ %s"bool"
[ABNF] Add circuits and add associated constants.
2022-06-24 01:06:39 +03:00
/ %s"circuit"
consistent keyword order and names
2021-03-23 19:11:42 +03:00
/ %s"console"
/ %s"const"
add constant keyword to grammar, change parameter grammar
2022-04-11 20:01:54 +03:00
/ %s"constant"
consistent keyword order and names
2021-03-23 19:11:42 +03:00
/ %s"else"
/ %s"field"
/ %s"for"
/ %s"function"
/ %s"group"
/ %s"i8"
/ %s"i16"
/ %s"i32"
/ %s"i64"
/ %s"i128"
/ %s"if"
/ %s"in"
/ %s"let"
[ABNF] Add `public` to keywords.
2022-04-07 23:07:37 +03:00
/ %s"public"
consistent keyword order and names
2021-03-23 19:11:42 +03:00
/ %s"return"
[ABNF] Add scalar type.
2022-05-14 07:32:56 +03:00
/ %s"scalar"
fixed some bugs
2022-06-08 16:46:54 +03:00
/ %s"string"
consistent keyword order and names
2021-03-23 19:11:42 +03:00
/ %s"u8"
/ %s"u16"
/ %s"u32"
/ %s"u64"
/ %s"u128"
uppercase-letter = %x41-5A ; A-Z
lowercase-letter = %x61-7A ; a-z
letter = uppercase-letter / lowercase-letter
[ABNF] Rename digit => decimal-digit. Since, with the introduction of (ASCII and Unicode escapes for) characters, we now have digits in base 10, 8, and 16, it seems worth being more explicit in the naming of decimal digits in the grammar. Just a nonterminal name change, not a structural change to the grammar.
2021-08-03 03:59:13 +03:00
decimal-digit = %x30-39 ; 0-9
[ABNF] Move a rule and update some comments. Move the rule for 'digit' just before the ones for 'octal-digit' and 'hexadecimal-digit'. Update the comments accordingly. No real change to the grammar here.
2021-08-03 03:56:47 +03:00
[ABNF] Add character literals. These are a new kind of literals that denote char values.
2021-05-13 04:41:58 +03:00
octal-digit = %x30-37 ; 0-7
[ABNF] Rename digit => decimal-digit. Since, with the introduction of (ASCII and Unicode escapes for) characters, we now have digits in base 10, 8, and 16, it seems worth being more explicit in the naming of decimal digits in the grammar. Just a nonterminal name change, not a structural change to the grammar.
2021-08-03 03:59:13 +03:00
hexadecimal-digit = decimal-digit / "a" / "b" / "c" / "d" / "e" / "f"
[ABNF] Add character literals. These are a new kind of literals that denote char values.
2021-05-13 04:41:58 +03:00
[ABNF] Rename digit => decimal-digit. Since, with the introduction of (ASCII and Unicode escapes for) characters, we now have digits in base 10, 8, and 16, it seems worth being more explicit in the naming of decimal digits in the grammar. Just a nonterminal name change, not a structural change to the grammar.
2021-08-03 03:59:13 +03:00
identifier = letter *( letter / decimal-digit / "_" )
[ABNF] Make the lexical grammar slightly less ambiguous. Before this commit, 'true' and 'false' were both keywords and boolean literals, making the grammar slightly more ambiguous than it needs to be. This manifests in the formal specification of lexing and parsing, which would need an additional extra-grammatical predicate requiring 'true' and 'false' to be boolean literals and not keywords. By making 'true' and 'false' just boolean literals, we obviate that need. Extend the comment about identifiers and package names not being keywords or aleo1... to also exclude boolean literals. This is similar to the grammar of Java, in which 'true', 'false', and 'null' are not keywords. This does not necessitate any change to the lexer/parser, which already performs its own procedural disambiguation of this and other aspects of the grammar.
2021-07-27 07:12:30 +03:00
; but not a keyword or a boolean literal or aleo1...
consistent keyword order and names
2021-03-23 19:11:42 +03:00
[ABNF] Rename 'natural' to 'numeral'. 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.
2022-03-11 02:23:58 +03:00
numeral = 1*decimal-digit
consistent keyword order and names
2021-03-23 19:11:42 +03:00
[ABNF] Rename 'natural' to 'numeral'. 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.
2022-03-11 02:23:58 +03:00
unsigned-literal = numeral ( %s"u8" / %s"u16" / %s"u32" / %s"u64" / %s"u128" )
consistent keyword order and names
2021-03-23 19:11:42 +03:00
[ABNF] Rename 'natural' to 'numeral'. 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.
2022-03-11 02:23:58 +03:00
signed-literal = numeral ( %s"i8" / %s"i16" / %s"i32" / %s"i64" / %s"i128" )
consistent keyword order and names
2021-03-23 19:11:42 +03:00
[ABNF] Rename 'natural' to 'numeral'. 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.
2022-03-11 02:23:58 +03:00
field-literal = numeral %s"field"
consistent keyword order and names
2021-03-23 19:11:42 +03:00
[ABNF] Rename 'natural' to 'numeral'. 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.
2022-03-11 02:23:58 +03:00
product-group-literal = numeral %s"group"
consistent keyword order and names
2021-03-23 19:11:42 +03:00
[ABNF] Add scalar type.
2022-05-14 07:32:56 +03:00
scalar-literal = numeral %s"scalar"
consistent keyword order and names
2021-03-23 19:11:42 +03:00
boolean-literal = %s"true" / %s"false"
[ABNF] Rename digit => decimal-digit. Since, with the introduction of (ASCII and Unicode escapes for) characters, we now have digits in base 10, 8, and 16, it seems worth being more explicit in the naming of decimal digits in the grammar. Just a nonterminal name change, not a structural change to the grammar.
2021-08-03 03:59:13 +03:00
address-literal = %s"aleo1" 58( lowercase-letter / decimal-digit )
consistent keyword order and names
2021-03-23 19:11:42 +03:00
[ABNF] Add character literals. These are a new kind of literals that denote char values.
2021-05-13 04:41:58 +03:00
single-quote-escape = "\" single-quote ; \'
double-quote-escape = "\" double-quote ; \"
backslash-escape = "\\"
line-feed-escape = %s"\n"
carriage-return-escape = %s"\r"
horizontal-tab-escape = %s"\t"
null-character-escape = "\0"
simple-character-escape = single-quote-escape
/ double-quote-escape
/ backslash-escape
/ line-feed-escape
/ carriage-return-escape
/ horizontal-tab-escape
/ null-character-escape
ascii-character-escape = %s"\x" octal-digit hexadecimal-digit
unicode-character-escape = %s"\u{" 1*6hexadecimal-digit "}"
format string and grammar changes
2021-07-21 00:52:35 +03:00
string-literal = double-quote *string-literal-element double-quote
[ABNF] Add string literals. These are a new kind of literals that denote arrays of characters, which is how we initially represent strings in Leo.
2021-05-13 05:04:11 +03:00
[ABNF] Fix/improve handling of line terminators. 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.
2022-06-12 01:56:49 +03:00
string-literal-element =
not-double-quote-or-backslash-or-line-feed-or-carriage-return
/ simple-character-escape
/ ascii-character-escape
/ unicode-character-escape
[ABNF] Add string literals. These are a new kind of literals that denote arrays of characters, which is how we initially represent strings in Leo.
2021-05-13 05:04:11 +03:00
[ABNF] Factor integer literals into a rule. This mirrors the structure of the rules for types, where there is an `integer-type` consisting of `unsigned-type` and `signed-type`. There is no change to the language.
2022-04-08 20:05:57 +03:00
integer-literal = unsigned-literal
[ABNF] Add a rule for function calls. (#1747) * [ABNF] Add a rule for function calls. This does not change the language. It just slightly reformulates the grammar for greater clarity and to help establish a nomenclature for constructs. Also remove a trailing space. * [ABNF] Re-generate markdown. Co-authored-by: collin <16715212+collinc97@users.noreply.github.com>
2022-04-13 22:22:04 +03:00
/ signed-literal
[ABNF] Factor integer literals into a rule. This mirrors the structure of the rules for types, where there is an `integer-type` consisting of `unsigned-type` and `signed-type`. There is no change to the language.
2022-04-08 20:05:57 +03:00
[ABNF] Add rule for numeric literals. This does not change the language. It just factors things better and introduces more nomenclature in the grammar.
2022-04-19 03:35:14 +03:00
numeric-literal = integer-literal
/ field-literal
/ product-group-literal
[ABNF] Add scalar type.
2022-05-14 07:32:56 +03:00
/ scalar-literal
[ABNF] Add rule for numeric literals. This does not change the language. It just factors things better and introduces more nomenclature in the grammar.
2022-04-19 03:35:14 +03:00
atomic-literal = numeric-literal
[ABNF] Allow spaces in affine group literals.
2021-04-05 23:55:05 +03:00
/ boolean-literal
/ address-literal
[ABNF] Add string literals. These are a new kind of literals that denote arrays of characters, which is how we initially represent strings in Leo.
2021-05-13 05:04:11 +03:00
/ string-literal
consistent keyword order and names
2021-03-23 19:11:42 +03:00
[ABNF] Grammar for pre-testnet3 version. 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.
2022-03-17 07:39:17 +03:00
symbol = "!" / "&&" / "||"
consistent keyword order and names
2021-03-23 19:11:42 +03:00
/ "==" / "!="
/ "<" / "<=" / ">" / ">="
/ "+" / "-" / "*" / "/" / "**"
[ABNF] Grammar for pre-testnet3 version. 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.
2022-03-17 07:39:17 +03:00
/ "="
consistent keyword order and names
2021-03-23 19:11:42 +03:00
/ "(" / ")"
[ABNF] Add (first draft of) input grammar. This is the (sub)grammar for input files. It is an initial draft, written based on the Notion page 'Leo Input File Doc/Spec'. This should be compared with the currently implemented parser of input (i.e. .in) files. As the Leo Reference will describe (that part has not been written yet), the input grammar is based on the lexical grammar, i.e. an input file consists of tokens, comments, and whitespace. However, only some tokens (compared to the syntactic grammar for Leo code files) are used, namely the ones reachable from the `input-file` nonterminal. Currently (i.e. im this initial version of Leo) `input-type` is (any) `type` and `input-expression` is just a `literal`, but these may evolve as we extend the language (e.g. we'll probably disallow circuit types and allow tuple and array constructions). The intent is that `input-type` will be a subset of `type` and that `input-expression` will be a subset of `expression`.
2022-04-16 05:54:41 +03:00
/ "[" / "]"
consistent keyword order and names
2021-03-23 19:11:42 +03:00
/ "{" / "}"
[ABNF] Add syntax for static function calls. 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`).
2022-06-20 23:46:43 +03:00
/ "," / "." / ".." / ";" / ":" / "::" / "?"
_ token in parser and symbol in abnf
2021-03-24 18:40:26 +03:00
/ "->" / "_"
[ABNF] Allow spaces in affine group literals.
2021-04-05 23:55:05 +03:00
/ %s")group"
consistent keyword order and names
2021-03-23 19:11:42 +03:00
token = keyword
/ identifier
[ABNF] Allow spaces in affine group literals.
2021-04-05 23:55:05 +03:00
/ atomic-literal
[ABNF] Add numerals to tokens. 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.
2022-04-05 06:47:57 +03:00
/ numeral
consistent keyword order and names
2021-03-23 19:11:42 +03:00
/ symbol
[ABNF] Add a notion of lexeme. This is just for nomenclature. It does not change the language or anything.
2021-07-29 02:33:14 +03:00
lexeme = token / comment / whitespace
consistent keyword order and names
2021-03-23 19:11:42 +03:00
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
; Syntactic Grammar
; -----------------
unsigned-type = %s"u8" / %s"u16" / %s"u32" / %s"u64" / %s"u128"
signed-type = %s"i8" / %s"i16" / %s"i32" / %s"i64" / %s"i128"
integer-type = unsigned-type / signed-type
field-type = %s"field"
group-type = %s"group"
[ABNF] Add scalar type.
2022-05-14 07:32:56 +03:00
scalar-type = %s"scalar"
arithmetic-type = integer-type / field-type / group-type / scalar-type
consistent keyword order and names
2021-03-23 19:11:42 +03:00
boolean-type = %s"bool"
address-type = %s"address"
[ABNF] Add string type.
2022-06-02 06:39:27 +03:00
string-type = %s"string"
primitive-type = boolean-type / arithmetic-type / address-type / string-type
consistent keyword order and names
2021-03-23 19:11:42 +03:00
[ABNF] Add syntax for static function calls. 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`).
2022-06-20 23:46:43 +03:00
named-type = primitive-type / identifier
type = named-type
[ABNF] Allow spaces in affine group literals.
2021-04-05 23:55:05 +03:00
[ABNF] add parens in group-coordinate for readability; fix indentation of format-string-element to make consistent with other indentation
2022-03-17 08:42:30 +03:00
group-coordinate = ( [ "-" ] numeral ) / "+" / "-" / "_"
[ABNF] Allow spaces in affine group literals.
2021-04-05 23:55:05 +03:00
[ABNF] Fix rule for affine group literals. This was affine-group-literal = "(" group-coordinate "," group-coordinate ")" %s"group" instead of affine-group-literal = "(" group-coordinate "," group-coordinate %s")group" (note the different ending). This change should have been part of the PR for whitespace in group literals, but apparently I failed to do that, along with the other changes. This commit rectifies that omission.
2021-04-07 02:39:07 +03:00
affine-group-literal = "(" group-coordinate "," group-coordinate %s")group"
[ABNF] Allow spaces in affine group literals.
2021-04-05 23:55:05 +03:00
literal = atomic-literal / affine-group-literal
group-literal = product-group-literal / affine-group-literal
[ABNF] Add circuits and add associated constants.
2022-06-24 01:06:39 +03:00
primary-expression = literal
/ variable-or-free-constant
/ associated-constant
consistent keyword order and names
2021-03-23 19:11:42 +03:00
/ "(" expression ")"
[ABNF] Add syntax for static function calls. 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`).
2022-06-20 23:46:43 +03:00
/ free-function-call
/ static-function-call
[ABNF] Add circuits and add associated constants.
2022-06-24 01:06:39 +03:00
/ circuit-expression
variable-or-free-constant = identifier
associated-constant = named-type "::" identifier
[ABNF] Add syntax for static function calls. 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`).
2022-06-20 23:46:43 +03:00
free-function-call = identifier function-arguments
[ABNF] Add a rule for function calls. (#1747) * [ABNF] Add a rule for function calls. This does not change the language. It just slightly reformulates the grammar for greater clarity and to help establish a nomenclature for constructs. Also remove a trailing space. * [ABNF] Re-generate markdown. Co-authored-by: collin <16715212+collinc97@users.noreply.github.com>
2022-04-13 22:22:04 +03:00
[ABNF] Add syntax for static function calls. 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`).
2022-06-20 23:46:43 +03:00
static-function-call = named-type "::" identifier function-arguments
consistent keyword order and names
2021-03-23 19:11:42 +03:00
[ABNF] Grammar for pre-testnet3 version. 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.
2022-03-17 07:39:17 +03:00
function-arguments = "(" [ expression *( "," expression ) [ "," ] ] ")"
consistent keyword order and names
2021-03-23 19:11:42 +03:00
[ABNF] Prohibit empty circuits. 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).
2022-06-24 07:13:24 +03:00
circuit-expression = identifier "{" circuit-component-initializer
*( "," circuit-component-initializer )
[ "," ] "}"
[ABNF] Add circuits and add associated constants.
2022-06-24 01:06:39 +03:00
circuit-component-initializer = identifier
/ identifier ":" expression
[ABNF] Improve the grammar for operator calls. 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.
2022-06-19 01:45:33 +03:00
postfix-expression = primary-expression
[ABNF] Add circuits and add associated constants.
2022-06-24 01:06:39 +03:00
/ circuit-component-expression
[ABNF] Improve the grammar for operator calls. 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.
2022-06-19 01:45:33 +03:00
/ operator-call
[ABNF] Add circuits and add associated constants.
2022-06-24 01:06:39 +03:00
circuit-component-expression = postfix-expression "." identifier
[ABNF] Add operator calls. 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).
2022-06-13 23:24:05 +03:00
operator-call = unary-operator-call / binary-operator-call
[ABNF] Improve the grammar for operator calls. 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.
2022-06-19 01:45:33 +03:00
unary-operator-call = postfix-expression "." identifier "(" ")"
[ABNF] Add operator calls. 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).
2022-06-13 23:24:05 +03:00
binary-operator-call =
[ABNF] Improve the grammar for operator calls. 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.
2022-06-19 01:45:33 +03:00
postfix-expression "." identifier "(" expression [ "," ] ")"
consistent keyword order and names
2021-03-23 19:11:42 +03:00
[ABNF] Improve the grammar for operator calls. 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.
2022-06-19 01:45:33 +03:00
unary-expression = postfix-expression
consistent keyword order and names
2021-03-23 19:11:42 +03:00
/ "!" unary-expression
/ "-" unary-expression
remove cast-expression from abnf for now
2021-04-14 23:17:57 +03:00
exponential-expression = unary-expression
/ unary-expression "**" exponential-expression
consistent keyword order and names
2021-03-23 19:11:42 +03:00
multiplicative-expression = exponential-expression
/ multiplicative-expression "*" exponential-expression
/ multiplicative-expression "/" exponential-expression
additive-expression = multiplicative-expression
/ additive-expression "+" multiplicative-expression
/ additive-expression "-" multiplicative-expression
[ABNF] Add new operators. 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.
2022-06-17 00:02:22 +03:00
shift-expression = additive-expression
/ shift-expression "<<" additive-expression
/ shift-expression ">>" additive-expression
bitwise-and-expression = shift-expression
/ bitwise-and-expression "&" shift-expression
bitwise-inclusive-or-expression =
bitwise-and-expression
/ bitwise-inclusive-or-expression "|" bitwise-and-expression
bitwise-exclusive-or-expression =
bitwise-inclusive-or-expression
/ bitwise-exclusive-or-expression "^" bitwise-inclusive-or-expression
[ABNF] Fix overlooked update. Thanks to @gluax for reporting the issue.
2022-06-17 01:18:59 +03:00
ordering-expression =
bitwise-exclusive-or-expression
/ bitwise-exclusive-or-expression "<" bitwise-exclusive-or-expression
/ bitwise-exclusive-or-expression ">" bitwise-exclusive-or-expression
/ bitwise-exclusive-or-expression "<=" bitwise-exclusive-or-expression
/ bitwise-exclusive-or-expression ">=" bitwise-exclusive-or-expression
consistent keyword order and names
2021-03-23 19:11:42 +03:00
equality-expression = ordering-expression
change equality_expressions
2021-07-01 23:40:29 +03:00
/ ordering-expression "==" ordering-expression
/ ordering-expression "!=" ordering-expression
consistent keyword order and names
2021-03-23 19:11:42 +03:00
[ABNF] Add new operators. 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.
2022-06-17 00:02:22 +03:00
boolean-and-expression = equality-expression
/ boolean-and-expression "&&" equality-expression
consistent keyword order and names
2021-03-23 19:11:42 +03:00
[ABNF] Add new operators. 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.
2022-06-17 00:02:22 +03:00
boolean-or-expression = boolean-and-expression
/ boolean-or-expression "||" boolean-and-expression
consistent keyword order and names
2021-03-23 19:11:42 +03:00
[ABNF] Add new operators. 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.
2022-06-17 00:02:22 +03:00
binary-expression = boolean-or-expression
[ABNF] Add rule for binary expressions. This does not change the language. It just adds a rule to name binary expressions explicitly. This makes the relation with ternary expressions clearer, and as usual it explicates more terminology.
2022-04-15 08:26:25 +03:00
conditional-expression = binary-expression
/ binary-expression "?" expression ":" expression
consistent keyword order and names
2021-03-23 19:11:42 +03:00
expression = conditional-expression
[ABNF] Remove expression statements. 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.
2022-03-30 07:20:26 +03:00
statement = return-statement
declaration refactor as suggested
2021-04-28 19:41:42 +03:00
/ variable-declaration
/ constant-declaration
consistent keyword order and names
2021-03-23 19:11:42 +03:00
/ conditional-statement
/ loop-statement
/ assignment-statement
/ console-statement
/ block
block = "{" *statement "}"
semi-colon after return statements are required
2021-04-14 23:59:07 +03:00
return-statement = %s"return" expression ";"
consistent keyword order and names
2021-03-23 19:11:42 +03:00
[ABNF] Grammar for pre-testnet3 version. 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.
2022-03-17 07:39:17 +03:00
variable-declaration = %s"let" identifier ":" type "=" expression ";"
declaration refactor as suggested
2021-04-28 19:41:42 +03:00
[ABNF] Grammar for pre-testnet3 version. 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.
2022-03-17 07:39:17 +03:00
constant-declaration = %s"const" identifier ":" type "=" expression ";"
consistent keyword order and names
2021-03-23 19:11:42 +03:00
branch = %s"if" expression block
conditional-statement = branch
/ branch %s"else" block
/ branch %s"else" conditional-statement
[ABNF] Require types to avoid type inference. Types are now required in variable and constant declarations (including for loop variables), and for literals (i.e. there are no longer untyped literals).
2022-03-06 10:52:34 +03:00
loop-statement = %s"for" identifier ":" type
[ABNF] Grammar for pre-testnet3 version. 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.
2022-03-17 07:39:17 +03:00
%s"in" expression ".." expression
[ABNF] Improve nomenclature. Replace 'circuit-or-alias-type' with 'identifier-or-self-type'. This makes the nomenclature for types more clear and extensible: - A type may be an identifier, which may be the name of a circuit type or the name of a type alias. - In the future, an identifier used as a type could refer to other kinds of types that we may add, such as enumerations. - While both 'alias type' and 'type alias' could be acceptable terms, it seems best to standardize on 'type alias': the latter describes an alias of a type (which is the right concept), while the former suggests a type of the "alias" kind (cf. 'circuit type', 'field type', 'integer type', etc.). Type aliases are not another kind of types like the other: they are aliases of (any of) those kinds of types. So by not having 'circuit-or-alias-type' we avoid suggesting a notion of 'alias type'. This does not change the language described by the grammar, it merely changes some nomenclature in the grammar. Thus, no change to the parser is needed. Aligning the nomenclature in the abstract syntax and parser to the ABNF would be good, but entirely optional at this point.
2021-09-03 07:54:42 +03:00
block
consistent keyword order and names
2021-03-23 19:11:42 +03:00
[ABNF] Grammar for pre-testnet3 version. 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.
2022-03-17 07:39:17 +03:00
assignment-operator = "="
consistent keyword order and names
2021-03-23 19:11:42 +03:00
assignment-statement = expression assignment-operator expression ";"
[ABNF] Fix rule for console statements. The ending semicolon was missing. This was found by @bendyarm, while investigating a discrepancy between the Leo parser in Rust and the Leo parser in ACL2: the latter was correctly following the erroneous grammar rule; it will be changed to be consistent with the fixed rule.
2021-10-20 04:01:48 +03:00
console-statement = %s"console" "." console-call ";"
consistent keyword order and names
2021-03-23 19:11:42 +03:00
console-call = assert-call
/ print-call
assert-call = %s"assert" "(" expression ")"
fix console debug grammar discrep
2022-02-26 00:45:49 +03:00
print-function = %s"error" / %s"log"
consistent keyword order and names
2021-03-23 19:11:42 +03:00
[ABNF] Grammar for pre-testnet3 version. 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.
2022-03-17 07:39:17 +03:00
print-arguments = "(" string-literal *( "," expression ) [ "," ] ")"
consistent keyword order and names
2021-03-23 19:11:42 +03:00
print-call = print-function print-arguments
[ABNF] Grammar for pre-testnet3 version. 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.
2022-03-17 07:39:17 +03:00
function-declaration = %s"function" identifier
[ABNF] Require function output type. 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.
2022-03-28 22:26:36 +03:00
"(" [ function-parameters ] ")" "->" type
consistent keyword order and names
2021-03-23 19:11:42 +03:00
block
[ABNF] Grammar for pre-testnet3 version. 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.
2022-03-17 07:39:17 +03:00
function-parameters = function-parameter *( "," function-parameter ) [ "," ]
[ABNF] Keep file to 80 columns.
2022-04-30 08:01:54 +03:00
function-parameter = [ %s"public" / %s"constant" / %s"const" ]
identifier ":" type
[ABNF] Grammar for pre-testnet3 version. 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.
2022-03-17 07:39:17 +03:00
[ABNF] Prohibit empty circuits. 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).
2022-06-24 07:13:24 +03:00
circuit-declaration = %s"circuit" "{" circuit-component-declaration
*( "," circuit-component-declaration )
[ "," ] "}"
[ABNF] Add circuits and add associated constants.
2022-06-24 01:06:39 +03:00
circuit-component-declaration = identifier ":" type
[ABNF] Grammar for pre-testnet3 version. 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.
2022-03-17 07:39:17 +03:00
declaration = function-declaration
[ABNF] Add circuits and add associated constants.
2022-06-24 01:06:39 +03:00
/ circuit-declaration
consistent keyword order and names
2021-03-23 19:11:42 +03:00
file = *declaration
[ABNF] Move the format note to the end of the file. Make this change on the .txt file.
2021-04-21 01:46:48 +03:00
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
[ABNF] Grammar for pre-testnet3 version. 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.
2022-03-17 07:39:17 +03:00
; Format String Grammar
; ---------------------
[ABNF] Improve doc comment. Given that the Leo Reference explains well that the format string grammar applies to the character sequence after processing escapes, we do not need to say this here. Instead, we just explain the rule similarly to what we do for others.
2022-04-30 07:58:34 +03:00
not-brace = %x0-7A / %x7C / %x7E-10FFFF ; anything but { or }
[ABNF] Grammar for pre-testnet3 version. 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.
2022-03-17 07:39:17 +03:00
format-string-container = "{}"
format-string-open-brace = "{{"
format-string-close-brace = "}}"
format-string-element = not-brace
[ABNF] add parens in group-coordinate for readability; fix indentation of format-string-element to make consistent with other indentation
2022-03-17 08:42:30 +03:00
/ format-string-container
/ format-string-open-brace
/ format-string-close-brace
[ABNF] Grammar for pre-testnet3 version. 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.
2022-03-17 07:39:17 +03:00
format-string = *format-string-element
[ABNF] Add (first draft of) input grammar. This is the (sub)grammar for input files. It is an initial draft, written based on the Notion page 'Leo Input File Doc/Spec'. This should be compared with the currently implemented parser of input (i.e. .in) files. As the Leo Reference will describe (that part has not been written yet), the input grammar is based on the lexical grammar, i.e. an input file consists of tokens, comments, and whitespace. However, only some tokens (compared to the syntactic grammar for Leo code files) are used, namely the ones reachable from the `input-file` nonterminal. Currently (i.e. im this initial version of Leo) `input-type` is (any) `type` and `input-expression` is just a `literal`, but these may evolve as we extend the language (e.g. we'll probably disallow circuit types and allow tuple and array constructions). The intent is that `input-type` will be a subset of `type` and that `input-expression` will be a subset of `expression`.
2022-04-16 05:54:41 +03:00
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
; Input Grammar
; -------------
update abnf
2022-06-01 18:48:36 +03:00
input-type = primitive-type
[ABNF] Add (first draft of) input grammar. This is the (sub)grammar for input files. It is an initial draft, written based on the Notion page 'Leo Input File Doc/Spec'. This should be compared with the currently implemented parser of input (i.e. .in) files. As the Leo Reference will describe (that part has not been written yet), the input grammar is based on the lexical grammar, i.e. an input file consists of tokens, comments, and whitespace. However, only some tokens (compared to the syntactic grammar for Leo code files) are used, namely the ones reachable from the `input-file` nonterminal. Currently (i.e. im this initial version of Leo) `input-type` is (any) `type` and `input-expression` is just a `literal`, but these may evolve as we extend the language (e.g. we'll probably disallow circuit types and allow tuple and array constructions). The intent is that `input-type` will be a subset of `type` and that `input-expression` will be a subset of `expression`.
2022-04-16 05:54:41 +03:00
[ABNF] Relax input and output expressions. 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.
2022-06-01 05:20:11 +03:00
input-expression = expression
[ABNF] Add (first draft of) input grammar. This is the (sub)grammar for input files. It is an initial draft, written based on the Notion page 'Leo Input File Doc/Spec'. This should be compared with the currently implemented parser of input (i.e. .in) files. As the Leo Reference will describe (that part has not been written yet), the input grammar is based on the lexical grammar, i.e. an input file consists of tokens, comments, and whitespace. However, only some tokens (compared to the syntactic grammar for Leo code files) are used, namely the ones reachable from the `input-file` nonterminal. Currently (i.e. im this initial version of Leo) `input-type` is (any) `type` and `input-expression` is just a `literal`, but these may evolve as we extend the language (e.g. we'll probably disallow circuit types and allow tuple and array constructions). The intent is that `input-type` will be a subset of `type` and that `input-expression` will be a subset of `expression`.
2022-04-16 05:54:41 +03:00
input-item = identifier ":" input-type "=" input-expression ";"
[ABNF] Refine the rule for input titles. Since we only allow four kinds of input section titles, corresponding to the public/private/constant/const characterization of function inputs, it seems beneficial to put this into the grammar, where it is easily captured. Note that the previous version of the rule, which uses `identifier`, is not quite right, because, for example, `public` is not an identiifer (it is a keyword). So the rule would have to be modified anyways.
2022-05-21 07:58:51 +03:00
input-title = "[" ( %s"public" / %s"private" / %s"constant" / %s"const" ) "]"
[ABNF] Add (first draft of) input grammar. This is the (sub)grammar for input files. It is an initial draft, written based on the Notion page 'Leo Input File Doc/Spec'. This should be compared with the currently implemented parser of input (i.e. .in) files. As the Leo Reference will describe (that part has not been written yet), the input grammar is based on the lexical grammar, i.e. an input file consists of tokens, comments, and whitespace. However, only some tokens (compared to the syntactic grammar for Leo code files) are used, namely the ones reachable from the `input-file` nonterminal. Currently (i.e. im this initial version of Leo) `input-type` is (any) `type` and `input-expression` is just a `literal`, but these may evolve as we extend the language (e.g. we'll probably disallow circuit types and allow tuple and array constructions). The intent is that `input-type` will be a subset of `type` and that `input-expression` will be a subset of `expression`.
2022-04-16 05:54:41 +03:00
input-section = input-title *input-item
input-file = *input-section
[ABNF] Add initial output grammar. This is for the current simplified version of Leo. When the main function is executed, it returns a value. According to this grammar, the output (i.e. `.out`) file contains a single literal, which describes the output value, preceded by an `[output]` title. This may be extended in the future.
2022-05-25 09:05:14 +03:00
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
; Output Grammar
; --------------
[ABNF] Relax input and output expressions. 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.
2022-06-01 05:20:11 +03:00
output-expression = expression
[ABNF] Add initial output grammar. This is for the current simplified version of Leo. When the main function is executed, it returns a value. According to this grammar, the output (i.e. `.out`) file contains a single literal, which describes the output value, preceded by an `[output]` title. This may be extended in the future.
2022-05-25 09:05:14 +03:00
output-item = output-expression ";"
output-title = "[" %s"output" "]"
output-section = output-title output-item
output-file = output-section
Reference in New Issue Copy Permalink