diff options
| author | Marshall Lochbaum <mwlochbaum@gmail.com> | 2022-04-17 17:14:50 -0400 |
|---|---|---|
| committer | Marshall Lochbaum <mwlochbaum@gmail.com> | 2022-04-17 18:03:42 -0400 |
| commit | 6553132505093fce4b7a3b2c95ad7d945d97e168 (patch) | |
| tree | 4e876921b7040538393952b4ef402fd73509304e /docs/spec/grammar.html | |
| parent | 5ed42f60312b87a1c85f701ed21d9d07181171e1 (diff) | |
Style fixes, and remove last uses of brace to mean block
Diffstat (limited to 'docs/spec/grammar.html')
| -rw-r--r-- | docs/spec/grammar.html | 10 |
1 files changed, 5 insertions, 5 deletions
diff --git a/docs/spec/grammar.html b/docs/spec/grammar.html index 3f9bce5f..19425e06 100644 --- a/docs/spec/grammar.html +++ b/docs/spec/grammar.html @@ -5,9 +5,9 @@ </head> <div class="nav">(<a href="https://github.com/mlochbaum/BQN">github</a>) / <a href="../index.html">BQN</a> / <a href="index.html">spec</a></div> <h1 id="specification-bqn-grammar"><a class="header" href="#specification-bqn-grammar">Specification: BQN grammar</a></h1> -<p>BQN's grammar is given below. Terms are defined in a <a href="https://en.wikipedia.org/wiki/Backus%E2%80%93Naur_form">BNF</a> variant. However, handling special names properly is possible but difficult in BNF, so they are explained in text along with the braced block grammar.</p> +<p>BQN's grammar is given below. Terms are defined in a <a href="https://en.wikipedia.org/wiki/Backus%E2%80%93Naur_form">BNF</a> variant. However, handling special names properly is possible but difficult in BNF, so they are explained in text along with the block grammar.</p> <p>The symbols <code><span class='Value'>s</span></code>, <code><span class='Function'>F</span></code>, <code><span class='Modifier'>_m</span></code>, and <code><span class='Modifier2'>_c_</span></code> are identifier tokens with subject, function, 1-modifier, and 2-modifier classes respectively. Similarly, <code><span class='Value'>sl</span></code>, <code><span class='Function'>Fl</span></code>, <code><span class='Modifier'>_ml</span></code>, and <code><span class='Modifier2'>_cl_</span></code> refer to literals and primitives of those classes. While names in the BNF here follow the identifier naming scheme, this is informative only: syntactic roles are no longer used after parsing and cannot be inspected in a running program.</p> -<p>A program is a list of statements. Almost all statements are expressions. Namespace export statements, and valueless results stemming from <code><span class='Nothing'>·</span></code>, or <code><span class='Value'>𝕨</span></code> in a monadic brace function, can be used as statements but not expressions.</p> +<p>A program is a list of statements. Almost all statements are expressions. Namespace export statements, and valueless results stemming from <code><span class='Nothing'>·</span></code>, or <code><span class='Value'>𝕨</span></code> in a monadic block function, can be used as statements but not expressions.</p> <pre><span class='Function'>PROGRAM</span> <span class='Function'>=</span> <span class='Separator'>⋄</span><span class='Head'>?</span> <span class='Paren'>(</span> <span class='Function'>STMT</span> <span class='Separator'>⋄</span> <span class='Paren'>)</span><span class='Value'>*</span> <span class='Function'>STMT</span> <span class='Separator'>⋄</span><span class='Head'>?</span> <span class='Function'>STMT</span> <span class='Function'>=</span> <span class='Function'>EXPR</span> <span class='Function'>|</span> <span class='Value'>nothing</span> <span class='Function'>|</span> <span class='Function'>EXPORT</span> <span class='Separator'>⋄</span> <span class='Function'>=</span> <span class='Paren'>(</span> <span class='String'>"⋄"</span> <span class='Function'>|</span> <span class='String'>","</span> <span class='Function'>|</span> <span class='Value'>\n</span> <span class='Paren'>)</span><span class='Function'>+</span> @@ -86,7 +86,7 @@ <span class='Function'>|</span> <span class='Function'>FuncName</span> <span class='String'>"˜"</span><span class='Head'>?</span> <span class='String'>"⁼"</span> <span class='Function'>|</span> <span class='Value'>lhsComp</span> </pre> -<p>A braced block contains bodies, which are lists of statements, separated by semicolons and possibly preceded by headers, which are separated from the body with a colon. A non-final expression can be made into a predicate by following it with the separator-like <code><span class='Head'>?</span></code>. Multiple bodies allow different handling for various cases, which are pattern-matched by headers. A block can have any number of bodies with headers. After these there can be bodies without headers—up to one for an immediate block and up to two for a block with arguments. If a block with arguments has one such body, it's ambivalent, but two of them refer to the monadic and dyadic cases.</p> +<p>A block is written with braces. It contains bodies, which are lists of statements, separated by semicolons. Multiple bodies can handle different cases, as determined by headers and predicates. A header is written before its body with a separating colon, and an expression other than the last in a body can be made into a predicate by following it with the separator-like <code><span class='Head'>?</span></code>. A block can have any number of bodies with headers. After these there can be bodies without headers—up to one for an immediate block and up to two for a block with arguments. If a block with arguments has one such body, it's ambivalent, but two of them refer to the monadic and dyadic cases.</p> <pre><span class='Function'>BODY</span> <span class='Function'>=</span> <span class='Separator'>⋄</span><span class='Head'>?</span> <span class='Paren'>(</span> <span class='Function'>STMT</span> <span class='Separator'>⋄</span> <span class='Function'>|</span> <span class='Function'>EXPR</span> <span class='Separator'>⋄</span><span class='Head'>?</span> <span class='String'>"?"</span> <span class='Separator'>⋄</span><span class='Head'>?</span> <span class='Paren'>)</span><span class='Value'>*</span> <span class='Function'>STMT</span> <span class='Separator'>⋄</span><span class='Head'>?</span> <span class='Function'>CASE</span> <span class='Function'>=</span> <span class='Function'>BODY</span> <span class='Function'>I_CASE</span> <span class='Function'>=</span> <span class='Separator'>⋄</span><span class='Head'>?</span> <span class='Function'>IMM_HEAD</span> <span class='Separator'>⋄</span><span class='Head'>?</span> <span class='String'>":"</span> <span class='Function'>BODY</span> @@ -98,7 +98,7 @@ <span class='Modifier'>_blMod1</span> <span class='Function'>=</span> <span class='Function'>IMM_BLK</span> <span class='Function'>|</span> <span class='Function'>ARG_BLK</span> <span class='Modifier2'>_blMod2_</span> <span class='Function'>=</span> <span class='Function'>IMM_BLK</span> <span class='Function'>|</span> <span class='Function'>ARG_BLK</span> </pre> -<p>Three additional rules apply to blocks, allowing the ambiguous grammar above to be disambiguated. They are shown in the table below. First, each block type allows the special names in its row to be used as the given token types within <code><span class='Function'>BODY</span></code> terms (not headers). Except for the spaces labelled "None", each of these four columns is cumulative, so that a given entry also includes all the entries above it. Second, a block can't contain one of the tokens from the "label" column of a different row. Third, each <code><span class='Function'>BrFunc</span></code>, <code><span class='Modifier'>_brMod1</span></code>, and <code><span class='Modifier2'>_brMod2_</span></code> term <em>must</em> contain one of the names on, and not above, the corresponding row (including the "label" column).</p> +<p>Three additional rules apply to blocks, allowing the ambiguous grammar above to be disambiguated. They are shown in the table below. First, each block type allows the special names in its row to be used as the given token types within <code><span class='Function'>BODY</span></code> terms (not headers). Except for the spaces labelled "None", each of these four columns is cumulative, so that a given entry also includes all the entries above it. Second, a block can't contain one of the tokens from the "label" column of a different row. Third, each <code><span class='Function'>BlFunc</span></code>, <code><span class='Modifier'>_blMod1</span></code>, and <code><span class='Modifier2'>_blMod2_</span></code> term <em>must</em> contain one of the names on, and not above, the corresponding row (including the "label" column).</p> <table> <thead> <tr> @@ -151,4 +151,4 @@ <span class='Function'>|</span> <span class='Paren'>(</span> <span class='Value'>subject_allow1</span> <span class='Function'>|</span> <span class='Value'>nothing_allow1</span> <span class='Paren'>)</span><span class='Head'>?</span> <span class='Function'>Derv_req1</span> <span class='Value'>arg_allow1</span> <span class='Function'>|</span> <span class='Paren'>(</span> <span class='Value'>subject_allow1</span> <span class='Function'>|</span> <span class='Value'>nothing_allow1</span> <span class='Paren'>)</span><span class='Head'>?</span> <span class='Function'>Derv_allow1</span> <span class='Value'>arg_req1</span> </pre> -<p>Quite tedious. The explosion of rules is partly due to the fact that the brace-typing rule falls into a weaker class of grammars than the other rules. Most of BQN is <a href="https://en.wikipedia.org/wiki/Deterministic_context-free_grammar">deterministic context-free</a> but brace-typing is not, only context-free. Fortunately brace typing does not introduce the parsing difficulties that can be present in a general context-free grammar, and it can easily be performed in linear time: after <a href="token.html">scanning</a> but before parsing, move through the source code maintaining a stack of the current top-level set of braces. Whenever a colon or special name is encountered, annotate that set of braces to indicate that it is present. When a closing brace is encountered and the top brace is popped off the stack, the type is needed if there was no colon, and can be found based on which names were present. One way to present this information to the parser is to replace the brace tokens with new tokens that indicate the type.</p> +<p>Quite tedious. The explosion of rules is partly due to the fact that the block-typing rule falls into a weaker class of grammars than the other rules. Most of BQN is <a href="https://en.wikipedia.org/wiki/Deterministic_context-free_grammar">deterministic context-free</a> but block-typing is not, only context-free. Fortunately block typing does not introduce the parsing difficulties that can be present in a general context-free grammar, and it can easily be performed in linear time: after <a href="token.html">scanning</a> but before parsing, move through the source code maintaining a stack of the current top-level set of braces. Whenever a colon or special name is encountered, annotate that set of braces to indicate that it is present. When a closing brace is encountered and the top brace is popped off the stack, the type is needed if there was no colon, and can be found based on which names were present. One way to present this information to the parser is to replace the brace tokens with new tokens that indicate the type.</p> |
