diff options
Diffstat (limited to 'docs')
| -rw-r--r-- | docs/commentary/problems.html | 2 | ||||
| -rw-r--r-- | docs/doc/context.html | 2 | ||||
| -rw-r--r-- | docs/spec/grammar.html | 2 |
3 files changed, 3 insertions, 3 deletions
diff --git a/docs/commentary/problems.html b/docs/commentary/problems.html index d1dd2c17..0518a34f 100644 --- a/docs/commentary/problems.html +++ b/docs/commentary/problems.html @@ -179,7 +179,7 @@ <h3 id="stranding-gotchas">Stranding gotchas</h3> <p>Fixed with list notation, which descends from the array notation developed by Phil Last and later Adám Brudzewsky. The problem that array notation has much more cluttered syntax than stranding has pretty much been fixed by the ligature character <code><span class='Ligature'>‿</span></code>, which I discovered during proto-BQN discussions.</p> <h3 id="functions-are-not-first-class">Functions are not first class</h3> -<p>Fixed by allowing a variable to be written with a different syntactic class than it was created with, suggested by Adám in proto-BQN discussions.</p> +<p>Fixed by allowing a variable to be written with a different syntactic role than it was created with, suggested by Adám in proto-BQN discussions.</p> <h3 id="apl-is-not-context-free">APL is not context-free</h3> <p>Fixed with the casing conventions for variable names, which I think I first saw in <a href="https://aplwiki.com/wiki/APL%5Civ">APL\iv</a>, although the cases are swapped relative to BQN.</p> <h3 id="selective-assignment-requires-a-named-variable">Selective assignment requires a named variable</h3> diff --git a/docs/doc/context.html b/docs/doc/context.html index b08f70a0..1e73eced 100644 --- a/docs/doc/context.html +++ b/docs/doc/context.html @@ -12,7 +12,7 @@ <pre><span class='Value'>b</span><span class='Paren'>(</span><span class='Value'>a</span><span class='Separator'>,</span> <span class='Value'>d</span><span class='Paren'>(</span><span class='Value'>c</span><span class='Paren'>)(</span><span class='Value'>e</span><span class='Paren'>))</span> <span class='Paren'>(</span><span class='Value'>b</span> <span class='Value'>a</span> <span class='Paren'>((</span><span class='Value'>d</span> <span class='Value'>c</span><span class='Paren'>)</span> <span class='Value'>e</span><span class='Paren'>))</span> </pre> -<p>In each case, some values are used as inputs to functions while others are the functions being applied. The result of a function can be used either as an input or as a function again. These expressions correspond to the APL expression where <code><span class='Value'>a</span></code> and <code><span class='Value'>e</span></code> are arrays, <code><span class='Value'>b</span></code> and <code><span class='Value'>c</span></code> are functions, and <code><span class='Value'>d</span></code> is a monadic operator. However, these syntactic classes have to be known to see what the APL expression is doing—they are a form of context that is required for a reader to know the grammatical structure of the expression. In a context-free grammar like that of simple C or Lisp expressions, a value's grammatical role is part of the expression itself, indicated with parentheses: they come after the function in C and before it in Lisp. Of course, a consequence of using parentheses in this way is having a lot of parentheses. BQN uses a different method to annotate grammatical role:</p> +<p>In each case, some values are used as inputs to functions while others are the functions being applied. The result of a function can be used either as an input or as a function again. These expressions correspond to the APL expression where <code><span class='Value'>a</span></code> and <code><span class='Value'>e</span></code> are arrays, <code><span class='Value'>b</span></code> and <code><span class='Value'>c</span></code> are functions, and <code><span class='Value'>d</span></code> is a monadic operator. However, these syntactic roles have to be known to see what the APL expression is doing—they are a form of context that is required for a reader to know the grammatical structure of the expression. In a context-free grammar like that of simple C or Lisp expressions, a value's grammatical role is part of the expression itself, indicated with parentheses: they come after the function in C and before it in Lisp. Of course, a consequence of using parentheses in this way is having a lot of parentheses. BQN uses a different method to annotate grammatical role:</p> <pre><span class='Value'>a</span> <span class='Function'>B</span> <span class='Function'>C</span> <span class='Modifier'>_d</span> <span class='Value'>e</span> </pre> <p>Here, the lowercase spelling indicates that <code><span class='Value'>a</span></code> and <code><span class='Value'>e</span></code> are to be treated as subjects ("arrays" in APL) while the uppercase spelling of variables <code><span class='Function'>B</span></code> and <code><span class='Function'>C</span></code> are used as functions and <code><span class='Modifier'>_d</span></code> is a 1-modifier ("monadic operator"). Like parentheses for function application, the spelling is not inherent to the variable values used, but instead indicates their grammatical role in this particular expression. A variable has no inherent spelling and can be used in any role, so the names <code><span class='Value'>a</span></code>, <code><span class='Function'>A</span></code>, <code><span class='Modifier'>_a</span></code>, and <code><span class='Modifier2'>_a_</span></code> all refer to exact same variable, but in different roles; typically we use the lowercase name to refer to the variable in isolation—all values are nouns when speaking about them in English. While we still don't know anything about what values <code><span class='Value'>a</span></code>, <code><span class='Value'>b</span></code>, <code><span class='Value'>c</span></code>, and so on have, we know how they interact in the line of code above.</p> diff --git a/docs/spec/grammar.html b/docs/spec/grammar.html index ca000bc6..419eb406 100644 --- a/docs/spec/grammar.html +++ b/docs/spec/grammar.html @@ -6,7 +6,7 @@ <div class="nav"><a href="https://github.com/mlochbaum/BQN">BQN</a> / <a href="../index.html">main</a> / <a href="index.html">spec</a></div> <h1 id="specification-bqn-grammar">Specification: BQN grammar</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>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 classes are no longer used after parsing and cannot be inspected in a running program.</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> <pre><span class='Function'>PROGRAM</span> <span class='Function'>=</span> <span class='Separator'>⋄</span><span class='Value'>?</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='Value'>?</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> |