From e52d50ed594dd5626523ca7931315e47bde8c9d1 Mon Sep 17 00:00:00 2001 From: Marshall Lochbaum Date: Mon, 20 Jul 2020 14:05:36 -0400 Subject: Make header id slugs match Github's --- docs/doc/context.html | 8 ++++---- docs/doc/fromDyalog.html | 2 +- docs/doc/logic.html | 4 ++-- 3 files changed, 7 insertions(+), 7 deletions(-) (limited to 'docs/doc') diff --git a/docs/doc/context.html b/docs/doc/context.html index 90963840..b4c5616f 100644 --- a/docs/doc/context.html +++ b/docs/doc/context.html @@ -1,6 +1,6 @@
BQN
-

BQN's context-free grammar

+

BQN's context-free grammar

APL has a problem. To illustrate, let's look at an APL expression:

a b c d e
@@ -12,12 +12,12 @@ 
a B C _d e

Here, the lowercase spelling indicates that a and e are to be treated as subjects ("arrays" in APL) while the uppercase spelling of variables B and C are used as functions and _d 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 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—all values are nouns when speaking about them in English. 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?

+

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 1-modifiers and characters like ∘ with unbroken circles are 2-modifiers before beginning to learn the BQN grammar that will explain how to tie the various parts together.

This sounds like a distant concern to a master of APL or a computer that has no difficulty memorizing a few dozen glyphs. Quite the opposite: the same concern applies to variables whenever you begin work with an unfamiliar codebase! Many APL programmers even enforce variable name conventions to ensure they know the class of a variable. By having such a system built in, BQN keeps you from having to rely on programmers following a style guide, and also allows greater flexibility, including functional programming, as we'll see later.

Shouldn't a codebase define all the variables it uses, so we can see their class from the definition? Not always: consider that in a language with libraries, code might be imported from dependencies. Many APLs also have some dynamic features that can allow a variable to have more than one class, such as the ⍺←⊢ pattern in a dfn that makes ⍺ an array in the dyadic case but a function in the monadic case. Regardless, searching for a definition somewhere in the code is certainly a lot more work than knowing the class just from looking! One final difficulty is that even one unknown can delay understanding of an entire expression. Suppose in A B c, B is a function and c is an array, and both values are known to be constant. If A is known to be a function (even if its value is not yet known), its right argument B c can be evaluated ahead of time. But if A's type isn't known, it's impossible to know if this optimization is worth it, because if it is an array, B will instead be called dyadically.

-

BQN's spelling system

+

BQN's spelling system

BQN's expression grammar is a simplified version of the typical APL, removing some oddities like niladic functions and the two-glyph Outer Product operator. Every value can be used in any of four syntactic roles:

@@ -54,7 +54,7 @@

BQN's variables use another system, where the spelling indicates how the variable's value is used. A variable spelled with a lowercase first letter, like var, is a subject. Spelled with an uppercase first letter, like Var, it is a function. Underscores are placed where operands apply to indicate a 1-modifier _var or 2-modifier _var_. Other than the first letter or underscore, variables are case-insensitive.

The associations between spelling and syntactic role are considered part of BQN's token formation rules.

One rule for typing is also best considered to be a pre-parsing rule like the spelling system: the role of a brace construct {} with no header is determined by which special arguments it uses: it's a subject if there are none, but a 𝕨 or 𝕩 makes it at least a function, an 𝔽 makes it a 1- or 2-modifier, and a 𝔾 always makes it a 2-modifier.

-

BQN's grammar

+

BQN's grammar

A formal treatment is included in the spec. BQN's grammar—the ways syntactic roles interact—follows the original APL model (plus trains) closely, with allowances for new features like list notation. In order to keep BQN's syntax context-free, the syntactic role of any expression must be known from its contents, just like tokens.

Here is a table of the APL-derived modifier and function application rules:

diff --git a/docs/doc/fromDyalog.html b/docs/doc/fromDyalog.html index 70bdb134..0b9ca972 100644 --- a/docs/doc/fromDyalog.html +++ b/docs/doc/fromDyalog.html @@ -1,6 +1,6 @@
BQN
-

BQN–Dyalog APL dictionary

+

BQN–Dyalog APL dictionary

A few tables to help users of Dyalog APL (or similar) get started quickly on BQN. Here we assume ⎕ML is 1 for Dyalog.

For reading

Here are some closest equivalents in Dyalog APL for the BQN functions that don't use the same glyphs as APL. Correspondence can be approximate, and ⌽ is just used as a decorator to mean "reverse some things".

diff --git a/docs/doc/logic.html b/docs/doc/logic.html index 7ac951d8..d9d8a405 100644 --- a/docs/doc/logic.html +++ b/docs/doc/logic.html @@ -1,6 +1,6 @@
BQN
-

Logic functions: And, Or, Not (also Span)

+

Logic functions: And, Or, Not (also Span)

BQN retains the APL symbols ∧ and ∨ for logical and and or, and changed APL's ~ to ¬ for not, since ~ looks too much like ˜ and ¬ is more common in mathematics today. Like J, BQN extends Not to the linear function 1⊸-. However, it discards GCD and LCM as extensions of And and Or, and instead uses bilinear extensions: And is identical to Times (×), while Or is ×⌾¬, following De Morgan's laws (other ways of obtaining a function for Or give an equivalent result—there is only one bilinear extension).

If the arguments are probabilities of independent events, then an extended function gives the probability of the boolean function on their outcomes (for example, if A occurs with probability a and B with probability b independent of A, then A or B occurs with probability a∨b). These extensions have also been used in complexity theory, because they allow mathematicians to transfer a logical circuit from the discrete to the continuous domain in order to use calculus on it.

Both valences of ¬ are equivalent to the fork 1+-. The dyadic valence, called "Span", computes the number of integers in the range from 𝕩 to 𝕨, inclusive, when both arguments are integers and 𝕩≤𝕨 (note the reversed order, which is used for consistency with subtraction). This function has many uses, and in particular is relevant to the Windows function.

@@ -29,7 +29,7 @@ 1 1 1

As with logical And and Or, any value and 0 is 0, while any value or 1 is 1. The other boolean values give the identity elements for the two functions: 1 and any value gives that value, as does 0 or the value.

-

Why not GCD and LCM?

+

Why not GCD and LCM?

The main reason for omitting these functions is that they are complicated and, when applied to real or complex numbers, require a significant number of design decisions where there is no obvious choice (for example, whether to use comparison tolerance). On the other hand, these functions are fairly easy to implement, which allows the programmer to control the details, and also add functionality such as the extended GCD.

A secondary reason is that the GCD falls short as an extension of Or, because its identity element 0 is not total. 0∨x, for a real number x, is actually equal to |x and not x: for example, 0∨¯2 is 2 in APL. This means the identity 0∨x ←→ x isn't reliable in APL.

Identity elements

-- cgit v1.2.3