From eb01eb415a5304d98c55f844188bb0defac90c67 Mon Sep 17 00:00:00 2001 From: Marshall Lochbaum Date: Fri, 17 Jul 2020 12:04:34 -0400 Subject: Character entity escaping for "&<> --- docs/context.html | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'docs/context.html') diff --git a/docs/context.html b/docs/context.html index 75d55842..201be8ab 100644 --- a/docs/context.html +++ b/docs/context.html @@ -10,7 +10,7 @@

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 a and e are arrays, b and c are functions, and d 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:

a B C _d e
 
-

Here, the lowercase spelling indicates that a and e are to be treated as values ("arrays" in APL) while the uppercase spelling of variables B and C are used as functions and _d is a 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 a, A, _a, and _a_ all refer to exact same variable, but in different roles; typically we use the lowercase name to refer to the variable in isolation. While we still don't know anything about what values a, b, c, and so on have, we know how they interact in the line of code above.

+

Here, the lowercase spelling indicates that a and e are to be treated as values ("arrays" in APL) while the uppercase spelling of variables B and C are used as functions and _d is a 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 a, A, _a, and _a_ all refer to exact same variable, but in different roles; typically we use the lowercase name to refer to the variable in isolation. While we still don't know anything about what values a, b, c, and so on have, we know how they interact in the line of code above.

Is grammatical context really a problem?

Yes, in the sense of problems with BQN. A grammar that uses context is harder for humans to read and machines to execute. A particular difficulty is that parts of an expression you don't yet understand can interfere with parts you do, making it difficult to work through an unknown codebase.

One difficulty beginners to APL will encounter is that code in APL at first appears like a string of undifferentiated symbols. For example, a tacit Unique Mask implementation ⍳⍨= consists of six largely unfamiliar characters with little to distinguish them (in fact, the one obvious bit of structure, the repeated , is misleading as it means different things in each case!). Simply placing parentheses into the expression, like (⍳⍨)=(), can be a great help to a beginner, and part of learning APL is to naturally see where the parentheses should go. The equivalent BQN expression, ˜=↕, will likely appear equally intimidating at first, but the path to learning which things apply to which is much shorter: rather than learning the entire list of APL primitives, a beginner just needs to know that superscript characters like ˜ are modifiers and characters like with unbroken circles are compositions before beginning to learn the BQN grammar that will explain how to tie the various parts together.

-- cgit v1.2.3