From 9bccc26a0c3231d7cc9adc37c1a850ef44fd436a Mon Sep 17 00:00:00 2001 From: Marshall Lochbaum Date: Thu, 24 Sep 2020 11:00:52 -0400 Subject: Add breadcrumbs to generated html --- docs/doc/based.html | 2 +- docs/doc/block.html | 2 +- docs/doc/context.html | 2 +- docs/doc/couple.html | 2 +- docs/doc/depth.html | 2 +- docs/doc/extensions.html | 2 +- docs/doc/fromDyalog.html | 2 +- docs/doc/functional.html | 2 +- docs/doc/glossary.html | 2 +- docs/doc/group.html | 2 +- docs/doc/index.html | 2 +- docs/doc/indices.html | 2 +- docs/doc/join.html | 2 +- docs/doc/leading.html | 2 +- docs/doc/logic.html | 2 +- docs/doc/prefixes.html | 2 +- docs/doc/primitive.html | 2 +- docs/doc/shift.html | 2 +- docs/doc/syntax.html | 2 +- docs/doc/transpose.html | 2 +- docs/doc/types.html | 2 +- docs/doc/windows.html | 2 +- docs/implementation/codfns.html | 2 +- docs/implementation/index.html | 2 +- docs/implementation/vm.html | 2 +- docs/problems.html | 2 +- docs/running.html | 2 +- docs/spec/evaluate.html | 2 +- docs/spec/grammar.html | 2 +- docs/spec/index.html | 2 +- docs/spec/inferred.html | 4 ++-- docs/spec/literal.html | 2 +- docs/spec/scope.html | 2 +- docs/spec/token.html | 2 +- docs/spec/types.html | 2 +- docs/tutorial/expression.html | 2 +- docs/tutorial/index.html | 2 +- docs/tutorial/list.html | 2 +- 38 files changed, 39 insertions(+), 39 deletions(-) (limited to 'docs') diff --git a/docs/doc/based.html b/docs/doc/based.html index 68407f38..2389481b 100644 --- a/docs/doc/based.html +++ b/docs/doc/based.html @@ -3,7 +3,7 @@ BQN: Based array theory -
BQN
+
BQN / main / doc

Based array theory

"Like a normal programming language"

This page explains how BQN's array model (christened "based" in 1981) differs from the models used by existing APL dialects, and why the choice was made to discard APL's "everything is an array" dictum. If you're not wondering what the difference is, and don't think everything should be an array, then you can probably just read about BQN's type system instead.

diff --git a/docs/doc/block.html b/docs/doc/block.html index 8c7a7770..5aae039f 100644 --- a/docs/doc/block.html +++ b/docs/doc/block.html @@ -3,7 +3,7 @@ BQN: Blocks -
BQN
+
BQN / main / doc

Blocks

In BQN, a block is any piece of code surrounded with curly braces {}. Blocks can be used simply to group statements, or can define functions or modifiers. They are the sole large-scale structure used to organize programs.

Blocks are most commonly used to define functions by including one of the special names for arguments, 𝕨 or 𝕩. With the operands 𝔽 or 𝔾, they can also define 1-modifiers or 2-modifiers.

diff --git a/docs/doc/context.html b/docs/doc/context.html index ba87f85c..a46a4659 100644 --- a/docs/doc/context.html +++ b/docs/doc/context.html @@ -3,7 +3,7 @@ BQN's context-free grammar -
BQN
+
BQN / main / doc

BQN's context-free grammar

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

a b c d e
diff --git a/docs/doc/couple.html b/docs/doc/couple.html
index ee145b54..69f85bab 100644
--- a/docs/doc/couple.html
+++ b/docs/doc/couple.html
@@ -3,7 +3,7 @@
   
   BQN: Couple and Merge
 
-
BQN

+
BQN / main / doc

 
Couple and Merge

 
Solo/Couple (≍) and Merge (>) are functions that create a higher-rank array from lower-rank components. Each takes some number of inner arrays organized in an outer structure, and creates a single array combining all elements of those inner arrays. For example, let's couple two arrays of shape 2‿3:

 ↗️
    ⊢ p ← 3‿5×⌜↕3
diff --git a/docs/doc/depth.html b/docs/doc/depth.html
index a80cf4c9..d67ce4ed 100644
--- a/docs/doc/depth.html
+++ b/docs/doc/depth.html
@@ -3,7 +3,7 @@
   
   BQN: Depth
 
-
BQN

+
BQN / main / doc

 
Depth

 
The depth of an array is the greatest level of array nesting it attains, or, put another way, the greatest number of times you can pick an element starting from the original array before reaching an atom. The monadic function Depth (≡) returns the depth of its argument, while the 2-modifier Depth (⚇) can control the way its left operand is applied based on the depth of its arguments. Several primitive functions also use the depth of the left argument to decide whether it applies to a single axis of the right argument or to several axes.

 
The Depth function

diff --git a/docs/doc/extensions.html b/docs/doc/extensions.html
index e3244153..e781194f 100644
--- a/docs/doc/extensions.html
+++ b/docs/doc/extensions.html
@@ -3,7 +3,7 @@
   
   BQN extensions
 
-
BQN

+
BQN / main / doc

 
BQN extensions

 
This page describes features that are not part of the core BQN specification, but may be specified in the future. If specified, these features would be optional, so that an implementation could choose to support them or not.

 
Complex numbers

diff --git a/docs/doc/fromDyalog.html b/docs/doc/fromDyalog.html
index be98d6ce..96320db6 100644
--- a/docs/doc/fromDyalog.html
+++ b/docs/doc/fromDyalog.html
@@ -3,7 +3,7 @@
   
   BQN–Dyalog APL dictionary
 
-
BQN

+
BQN / main / doc

 
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.

 
Terminology

diff --git a/docs/doc/functional.html b/docs/doc/functional.html
index 04205144..a2902fa1 100644
--- a/docs/doc/functional.html
+++ b/docs/doc/functional.html
@@ -3,7 +3,7 @@
   
   BQN: Functional programming
 
-
BQN

+
BQN / main / doc

 
Functional programming

 
BQN boasts of its functional capabilities, including first-class functions. What sort of functional support does it have, and how can a BQN programmer exercise these and out themself as a Schemer at heart?

 
First, let's be clear about what the terms we're using mean. A language has first-class functions when functions (however they are defined) can be used in all the same ways as "ordinary" values like numbers and so on, such as being passed as an argument or placed in a list. Lisp and JavaScript have first-class functions, C has unsafe first-class functions via function pointers, and Java and APL don't have them as functions can't be placed in lists or used as arguments. This doesn't mean every operation is supported on functions: for instance, numbers can be added, compared, and sorted; while functions could perhaps be added to give a train, comparing or sorting them as functions (not representations) isn't computable, and BQN doesn't support any of the three operations when passing functions as arguments.

diff --git a/docs/doc/glossary.html b/docs/doc/glossary.html
index f6f2cc30..f8d2ded0 100644
--- a/docs/doc/glossary.html
+++ b/docs/doc/glossary.html
@@ -3,7 +3,7 @@
   
   BQN glossary
 
-
BQN

+
BQN / main / doc

 
BQN glossary

 
Below are short, and sometimes vague, definitions of terms used to describe BQN code.

 
Types

diff --git a/docs/doc/group.html b/docs/doc/group.html
index be2192b2..9b74f0f6 100644
--- a/docs/doc/group.html
+++ b/docs/doc/group.html
@@ -3,7 +3,7 @@
   
   BQN: Group
 
-
BQN

+
BQN / main / doc

 
Group

 
BQN replaces the Key operator from J or Dyalog APL, and many forms of partitioning, with a single (ambivalent) Group function ⊔. This function is somewhat related to the K function = of the same name, but results in an array rather than a dictionary.

 
Definition

diff --git a/docs/doc/index.html b/docs/doc/index.html
index 8668bba6..f578e4fc 100644
--- a/docs/doc/index.html
+++ b/docs/doc/index.html
@@ -3,7 +3,7 @@
   
   BQN documentation
 
-
BQN

+
BQN / main

 
BQN documentation

 
Here is the documentation for BQN, describing what features BQN has, how to use them (with examples), and why they were chosen. As it is considerably more in-depth than the specification, the documentation is much less complete. The following pages are present now:

 
Overview:

diff --git a/docs/doc/indices.html b/docs/doc/indices.html
index 2fa56e29..b50cd571 100644
--- a/docs/doc/indices.html
+++ b/docs/doc/indices.html
@@ -3,7 +3,7 @@
   
   BQN: Indices
 
-
BQN

+
BQN / main / doc

 
Indices

 
One-dimensional arrays such as K lists or Python arrays have only one kind of index, a single number that refers to an element. For multidimensional arrays using the leading axis theory, there are several types of indexing that can be useful. Historically, nested APL designs have equivocated between these, which I believe can lead to subtle errors when programming. BQN focuses on single-number (atomic) indices, which can refer to list elements or array major cells (or more generally indexing along any particular axis). When using atomic indices to select elements, the indexed array has to be a list. In contrast, elements of any array can be indicated by list indices with length equal to that array's rank. Only two BQN primitives use these list indices: Range (↕), which returns an array of them if given a list argument, and Pick (⊑), where the depth-1 components of an array left argument are list indices.

 
The following functions take or return indices. Except where marked, the indices are in the result; this is by far the most common type of index use. ⊔ is given two rows as it falls into both cases. Note that in the result case, there is usually no possibility for the programmer to select the format of indices. Instead, the language should be carefully designed to make sure that the kind of index returned is as useful as possible.

diff --git a/docs/doc/join.html b/docs/doc/join.html
index 312a1f95..aa2637dd 100644
--- a/docs/doc/join.html
+++ b/docs/doc/join.html
@@ -3,7 +3,7 @@
   
   BQN: Join
 
-
BQN

+
BQN / main / doc

 
Join

 
Join (∾) is an extension of the monadic function Raze from A+ and J to arbitrary argument ranks. It has the same relationship to Join to, the dyadic function sharing the same glyph, as Merge (>) does to Couple (≍): a≍b is >a‿b and a∾b is ∾a‿b. While Merge and Couple combine arrays (the elements of Merge's argument, or the arguments themselves for Couple) along a new leading axis, Join and Join to combine them along the existing leading axis. Both Merge and Join can also be called on a higher-rank array, causing Merge to add multiple leading axes while Join combines elements along multiple existing axes.

 
Join can be used to combine several strings into a single string, like array.join() in Javascript (but it doesn't force the result to be a string).

diff --git a/docs/doc/leading.html b/docs/doc/leading.html
index b2f2cda6..b96c2d9a 100644
--- a/docs/doc/leading.html
+++ b/docs/doc/leading.html
@@ -3,7 +3,7 @@
   
   BQN: The leading axis convention
 
-
BQN

+
BQN / main / doc

 
The leading axis convention

 
Several primitive functions manipulate the right argument, or sometimes both arguments, along one or more axes. According to the leading axis model, it's best to make the primitives operate on initial axes, because the Rank modifier then allows it to apply to later axes as well. Here we'll see how this pattern works in BQN.

 
Monadic functions

diff --git a/docs/doc/logic.html b/docs/doc/logic.html
index e19e4e92..0ede46e7 100644
--- a/docs/doc/logic.html
+++ b/docs/doc/logic.html
@@ -3,7 +3,7 @@
   
   BQN: Logic functions: And, Or, Not (also Span)
 
-
BQN

+
BQN / main / doc

 
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.

diff --git a/docs/doc/prefixes.html b/docs/doc/prefixes.html
index 34b52fc7..9aa3dd20 100644
--- a/docs/doc/prefixes.html
+++ b/docs/doc/prefixes.html
@@ -3,7 +3,7 @@
   
   BQN: Prefixes and Suffixes
 
-
BQN

+
BQN / main / doc

 
Prefixes and Suffixes

 
The Prefixes (↑) function gives a list of all prefixes of its argument array along the first axis, and Suffixes (↓) gives a similar list for suffixes. Because the result can be much larger than the argument, these functions may not be used often in high-performance code, but they are a powerful conceptual tool and can make sense for algorithms that are inherently quadratic.

 ↗️
    ↑ "abcde"
diff --git a/docs/doc/primitive.html b/docs/doc/primitive.html
index bca3ee06..4ce6a7c4 100644
--- a/docs/doc/primitive.html
+++ b/docs/doc/primitive.html
@@ -3,7 +3,7 @@
   
   BQN primitives
 
-
BQN

+
BQN / main / doc

 
BQN primitives

 
Primitives are functions and modifiers that are built into the language.

 
Functions

diff --git a/docs/doc/shift.html b/docs/doc/shift.html
index c9d84e1e..f96661d1 100644
--- a/docs/doc/shift.html
+++ b/docs/doc/shift.html
@@ -3,7 +3,7 @@
   
   BQN: Shift functions
 
-
BQN

+
BQN / main / doc

 
Shift functions

 
The shift functions « and » are two new primitives added to BQN based on a pattern used heavily in the compiler and a reasonable amount everywhere else. Shifts resemble but are more general than the bit-based shift operations used in low-level languages. They replace the APL pattern of a 2-wise reduction after appending or prepending an element (APL's 2≠/0,v translates to »⊸≠v), one of the more common uses of 2-wise reduction.

 
The result of a shift function always has the same shape as its right argument. The function adds major cells to the beginning (») or end («) of 𝕩, moving the cells already in 𝕩 to accomodate them. Some cells on the opposite side from those added will "fall off" and not be included in the result.

diff --git a/docs/doc/syntax.html b/docs/doc/syntax.html
index 5fc5ff3a..427f05c9 100644
--- a/docs/doc/syntax.html
+++ b/docs/doc/syntax.html
@@ -3,7 +3,7 @@
   
   BQN: Syntax overview
 
-
BQN

+
BQN / main / doc

 
Syntax overview

 
BQN syntax consists of expressions where computation is done with a little organizing structure around them like assignment, functions, and list notation. Expressions are where the programmer is in control so the design tries to do as much as possible with them before introducing special syntax.

 
Special glyphs

diff --git a/docs/doc/transpose.html b/docs/doc/transpose.html
index 96371227..b7ecac6d 100644
--- a/docs/doc/transpose.html
+++ b/docs/doc/transpose.html
@@ -3,7 +3,7 @@
   
   BQN: Transpose
 
-
BQN

+
BQN / main / doc

 
Transpose

 
As in APL, Transpose (⍉) is a tool for rearranging the axes of an array. BQN's version is tweaked to align better with the leading axis model and make common operations easier.

 
Monadic Transpose

diff --git a/docs/doc/types.html b/docs/doc/types.html
index bf9a9c9e..258f026f 100644
--- a/docs/doc/types.html
+++ b/docs/doc/types.html
@@ -3,7 +3,7 @@
   
   BQN: Types
 
-
BQN

+
BQN / main / doc

 
Types

 
BQN supports the following fundamental types:

 
    
diff --git a/docs/doc/windows.html b/docs/doc/windows.html
index 7a446b90..f2310333 100644
--- a/docs/doc/windows.html
+++ b/docs/doc/windows.html
@@ -3,7 +3,7 @@
   
   BQN: Windows
 
-
    BQN
    
+
    BQN / main / doc
    
 
    Windows
    
 
    In BQN, it's strongly preferred to use functions, and not modifiers, for array manipulation. Functions are simpler as they have fewer moving parts. They are more concrete, since the array results can always be viewed right away. They are easier to implement with reasonable performance as well, since there is no need to recognize many possible function operands as special cases.
    
 
    The Window function replaces APL's Windowed Reduction, J's more general Infix operator, and Dyalog's Stencil, which is adapted from one case of J's Cut operator.
    
diff --git a/docs/implementation/codfns.html b/docs/implementation/codfns.html
index 3b15070a..563c4bfe 100644
--- a/docs/implementation/codfns.html
+++ b/docs/implementation/codfns.html
@@ -3,7 +3,7 @@
   
   Co-dfns versus BQN's implementation
 
-
    BQN
    
+
    BQN / main / implementation
    
 
    Co-dfns versus BQN's implementation
    
 
    The BQN self-hosted compiler is directly inspired by the Co-dfns project, a compiler for a subset of Dyalog APL. I'm very grateful to Aaron for showing that array-oriented compilation is even possible! In addition to the obvious difference of target language, BQN differs from Co-dfns both in goals and methods.
    
 
    The shared goals of BQN and Co-dfns are to implement a compiler for an array language with whole-array operations. This provides the theoretical benefit of a short critical path, which in practice means that both compilers can make good use of a GPU or a CPU's vector instructions simply by providing an appropriate runtime (however, only Co-dfns has such a runtime—an ArrayFire program on the GPU and Dyalog APL on the CPU). The two implementations also share a preference for working "close to the metal" by passing around arrays of numbers rather than creating abstract types to work with data. Objects are right out. These choices lead to a compact source code implementation, and may have some benefits in terms of how easy it is to write and understand the compiler.
    
diff --git a/docs/implementation/index.html b/docs/implementation/index.html
index d4d7c047..2ab839e4 100644
--- a/docs/implementation/index.html
+++ b/docs/implementation/index.html
@@ -3,7 +3,7 @@
   
   BQN implementation notes
 
-
    BQN
    
+
    BQN / main
    
 
    BQN implementation notes
    
 
    Notes about how BQN is implemented. There's not too much here yet.
    
 
      
diff --git a/docs/implementation/vm.html b/docs/implementation/vm.html
index cf39c1ce..c0608644 100644
--- a/docs/implementation/vm.html
+++ b/docs/implementation/vm.html
@@ -3,7 +3,7 @@
   
   The BQN virtual machine and runtime
 
-
      BQN
      
+
      BQN / main / implementation
      
 
      The BQN virtual machine and runtime
      
 
      BQN's self-hosted compiler and runtime mean that only a small amount of native code is needed to run BQN on any given platform. For example, the Javascript environment requires about 200 lines of Javascript code even though it compiles BQN bytecode to Javascript, a more complex strategy than interpreting it directly. This makes it fairly easy to port BQN to new platforms, allowing BQN to run "natively" within other programming languages and interact with arrays in those languages.
      
 
      Bytecode
      
diff --git a/docs/problems.html b/docs/problems.html
index 8b6afb02..d8e920af 100644
--- a/docs/problems.html
+++ b/docs/problems.html
@@ -3,7 +3,7 @@
   
   Problems with BQN
 
-
      BQN
      
+
      BQN / main
      
 
      Problems with BQN
      
 
      Every language has some issues that everyone can agree make programming harder. Sometimes there is a simple solution that has not yet been discovered; sometimes the problem is inherent to the language because it's caused by fundamental choices (or anywhere in between). Below are problems I have identified in BQN, ordered from what I consider the most severe to the least. This is independent of whether the issue can be solved—if it somehow went away, how much better would the language be?
      
 
      I've omitted problems that are obviously addressed by speculated extensions. Of course adding A fixes the problem "doesn't have A". Problems that only exist in reference to some existing convention (e.g. unfamiliarity to APLers) are also left out, unless the convention manifests technically (Unicode support).
      
diff --git a/docs/running.html b/docs/running.html
index 9d7ad14b..91a52089 100644
--- a/docs/running.html
+++ b/docs/running.html
@@ -3,7 +3,7 @@
   
   How to run BQN
 
-
      BQN
      
+
      BQN / main
      
 
      How to run BQN
      
 
      BQN is in an early stage of development, and no implementation is complete yet. However, it's a relatively simple language to implement, and a few implementations come close. At the moment, dzaima/BQN is the most usable version, with good performance and error reporting.
      
 
      BQN
      
diff --git a/docs/spec/evaluate.html b/docs/spec/evaluate.html
index bfe9cbef..ab2b6bf4 100644
--- a/docs/spec/evaluate.html
+++ b/docs/spec/evaluate.html
@@ -3,7 +3,7 @@
   
   Specification: BQN evaluation
 
-
      BQN
      
+
      BQN / main / spec
      
 
      Specification: BQN evaluation
      
 
      This page describes the semantics of the code constructs whose grammar is given in grammar.md. The formation rules there are not named, and here they are identified by either the name of the term or by copying the rule entirely if there are several alternative productions.
      
 
      Here we assume that the referent of each identifier, or equivalently the connections between identifiers, have been identified according to the scoping rules.
      
diff --git a/docs/spec/grammar.html b/docs/spec/grammar.html
index 4928aed8..66734fc4 100644
--- a/docs/spec/grammar.html
+++ b/docs/spec/grammar.html
@@ -3,7 +3,7 @@
   
   Specification: BQN grammar
 
-
      BQN
      
+
      BQN / main / spec
      
 
      Specification: BQN grammar
      
 
      BQN's grammar is given below. Terms are defined in a BNF variant. However, handling special names properly is possible but difficult in BNF, so they are explained in text along with the braced block grammar.
      
 
      The symbols s, F, _m, and _c_ are identifier tokens with subject, function, 1-modifier, and 2-modifier classes respectively. Similarly, sl, Fl, _ml, and _cl_ 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.
      
diff --git a/docs/spec/index.html b/docs/spec/index.html
index 8a7d2a69..3d9ae69a 100644
--- a/docs/spec/index.html
+++ b/docs/spec/index.html
@@ -3,7 +3,7 @@
   
   BQN specification
 
-
      BQN
      
+
      BQN / main
      
 
      BQN specification
      
 
      This directory gives a (currently incomplete) specification for BQN. The specification differs from the documentation in that its purpose is only to describe the exact details of BQN's operation in the most quickly accessible way, rather than to explain the core ideas of BQN functionality and how it might be used. Since it is easier to specify than to document, the specification is currently more complete than the documentation; for example, it includes nearly all primitives.
      
 
      The following aspects define BQN and are or will be specified:
      
diff --git a/docs/spec/inferred.html b/docs/spec/inferred.html
index 7dc99db6..f01450ea 100644
--- a/docs/spec/inferred.html
+++ b/docs/spec/inferred.html
@@ -3,7 +3,7 @@
   
   Specification: BQN inferred properties
 
-
      BQN
      
+
      BQN / main / spec
      
 
      Specification: BQN inferred properties
      
 
      BQN includes some simple deductive capabilities: detecting the type of empty array elements, and the Undo (⁼) and Under (⌾) modifiers. These tasks are a kind of proof-based or constraint programming, and can never be solved completely (some instances will be undecidable) but can be solved in more instances by ever-more sophisticated algorithms. To allow implementers to develop more advanced implementations while offering some stability and portability to programmers, two kinds of specification are given here. First, constraints are given on the behavior of inferred properties. These are not exact and require some judgment on the part of the implementer. Second, behavior for common or useful cases is specified more precisely. Non-normative suggestions are also given as a reference for implementers.
      
 
      For the specified cases, the given functions and modifiers refer to those particular representations. It is not necessary to detect equivalent representations, for example to reduce (+-×)⁼ to ∨⁼. However, it is necessary to identify computed functions and modifiers: for example F⁼ when the value of F in the expression is ∨, or (1⊑∧‿∨)⁼.
      
@@ -44,7 +44,7 @@
 
 
 √
-⋆⟜2
+ט
 ⋆˜
 
 
diff --git a/docs/spec/literal.html b/docs/spec/literal.html
index 39ac864a..c9e9d362 100644
--- a/docs/spec/literal.html
+++ b/docs/spec/literal.html
@@ -3,7 +3,7 @@
   
   Specification: BQN literal notation
 
-
      BQN
      
+
      BQN / main / spec
      
 
      Specification: BQN literal notation
      
 
      A literal is a single token that indicates a fixed character, number, or array. While literals indicate values of a data type, primitives indicate values of an operation type: function, 1-modifier, or 2-modifier.
      
 
      Two types of literal deal with text. As the source code is considered to be a sequence of unicode code points ("characters"), and these code points are also used for BQN's character data type, the representation of a text literal is very similar to its value. In a text literal, the newline character is always represented using the ASCII line feed character, code point 10. A character literal is enclosed with single quotes ' and its value is identical to the single character between them. A string literal is enclosed in double quotes ", and any double quotes between them must come in pairs, as a lone double quote marks the end of the literal. The value of a string literal is a rank-1 array whose elements are the characters in between the enclosing quotes, after replacing each pair of double quotes with only one such quote. The null literal is the token @ and represents the null character, code point 0.
      
diff --git a/docs/spec/scope.html b/docs/spec/scope.html
index 95bb16c1..6e8dd6ac 100644
--- a/docs/spec/scope.html
+++ b/docs/spec/scope.html
@@ -3,7 +3,7 @@
   
   Specification: BQN variable scoping
 
-
      BQN
      
+
      BQN / main / spec
      
 
      Specification: BQN variable scoping
      
 
      BQN uses lexical scoping for variables, where scopes correspond roughly to blocks, or pairs of curly braces separated by semicolons. At the top level in a scope, new variables are visible only after they are defined, but in the scopes it contains, all variables defined in that scope are visible. This system is specified more precisely below.
      
 
      A running BQN program manipulates variables during its execution, but it is important to distinguish these variables from the identifiers that refer to them. As defined in the tokenization rules, an identifier is a particular kind of token found in a program's source code. The lexical scoping rules in this page define which identifiers are considered the same; these identifiers will refer to the same variables when the program is run. While each variable has only one identifier, an identifier can refer to any number of variables because a new variable is created for that identifier each time its containing scope is instantiated (that is, each time the contents of the block are evaluated).
      
diff --git a/docs/spec/token.html b/docs/spec/token.html
index 87e738ac..799ae387 100644
--- a/docs/spec/token.html
+++ b/docs/spec/token.html
@@ -3,7 +3,7 @@
   
   Specification: BQN token formation
 
-
      BQN
      
+
      BQN / main / spec
      
 
      Specification: BQN token formation
      
 
      This page describes BQN's token formation rules (token formation is also called scanning). Most tokens in BQN are a single character long, but quoted characters and strings, identifiers, and numbers can consist of multiple characters, and comments, spaces, and tabs are discarded during token formation.
      
 
      BQN source code should be considered as a series of unicode code points, which we refer to as "characters". The separator between lines in a file is considered to be a single character, newline, even though some operating systems such as Windows typically represent it with a two-character CRLF sequence. Implementers should note that not all languages treat unicode code points as atomic, as exposing the UTF-8 or UTF-16 representation instead is common. For a language such as JavaScript that uses UTF-16, the double-struck characters 𝕨𝕎𝕩𝕏𝕗𝔽𝕘𝔾 are represented as two 16-bit surrogate characters, but BQN treats them as a single unit.
      
diff --git a/docs/spec/types.html b/docs/spec/types.html
index 13345808..8c9c694a 100644
--- a/docs/spec/types.html
+++ b/docs/spec/types.html
@@ -3,7 +3,7 @@
   
   Specification: BQN types
 
-
      BQN
      
+
      BQN / main / spec
      
 
      Specification: BQN types
      
 
      BQN programs manipulate data of six types:
      
 
        
diff --git a/docs/tutorial/expression.html b/docs/tutorial/expression.html
index 6098e7a4..7be7064f 100644
--- a/docs/tutorial/expression.html
+++ b/docs/tutorial/expression.html
@@ -3,7 +3,7 @@
   
   Tutorial: BQN expressions
 
-
        BQN
        
+
        BQN / main / tutorial
        
 
        Tutorial: BQN expressions
        
 
        Arithmetic
        
 
        All right, let's get started! Since you can run BQN online from the REPL there aren't any real technical preliminaries, but if you'd like to look at non-web-based options head over to running.md.
        
diff --git a/docs/tutorial/index.html b/docs/tutorial/index.html
index 9b145061..ac8b515d 100644
--- a/docs/tutorial/index.html
+++ b/docs/tutorial/index.html
@@ -3,7 +3,7 @@
   
   BQN tutorials
 
-
        BQN
        
+
        BQN / main
        
 
        BQN tutorials
        
 
        BQN tutorials explain how to approach and use the language as a newcomer (or they try; please get in touch if you find that they skip ahead!). Tutorials are meant to explain key ideas and may ignore details that would be included in the documentation; also unlike the documentation they're meant to be read in order, as each tutorial will build on ideas from the previous ones.
        
 
        Tutorials assume (pretty presumptively, really. Disgusting.) that you are already motivated to learn BQN and use simple rather than flashy examples. Documents to induce motivation beyond the README are not yet available. Do feel free to skim or jump around if you find you are reading a lot of things that are already obvious.
        
diff --git a/docs/tutorial/list.html b/docs/tutorial/list.html
index bfeb2221..7895a891 100644
--- a/docs/tutorial/list.html
+++ b/docs/tutorial/list.html
@@ -3,7 +3,7 @@
   
   BQN: Tutorial: Working with lists
 
-
        BQN
        
+
        BQN / main / tutorial
        
 
        Tutorial: Working with lists
        
 
        Enough with all these preliminaries like learning how to read basic expressions. Let's get into what makes BQN special.
        
 ↗️
            ⟨1, 2, 3⟩
-- 
cgit v1.2.3