From 4ac3f5940a89dcbc165479603689e02c29f50feb Mon Sep 17 00:00:00 2001 From: Marshall Lochbaum Date: Thu, 23 Jun 2022 16:33:26 -0400 Subject: Document [] notation --- README.md | 2 +- doc/arrayrepr.md | 22 ++++++++++------------ doc/expression.md | 10 ++++++++-- doc/syntax.md | 15 +++++++++------ docs/doc/arrayrepr.html | 31 ++++++++++++------------------- docs/doc/expression.html | 14 ++++++++++++-- docs/doc/syntax.html | 17 +++++++++++------ docs/help/beginlist.html | 2 +- docs/help/endlist.html | 2 +- docs/help/strand.html | 2 +- docs/index.html | 2 +- help/beginlist.md | 2 +- help/endlist.md | 2 +- help/strand.md | 2 +- 14 files changed, 70 insertions(+), 55 deletions(-) diff --git a/README.md b/README.md index b638ce7d..0bf1d0e4 100644 --- a/README.md +++ b/README.md @@ -55,7 +55,7 @@ It incorporates concepts developed over years of APL practice: * Lightweight [**anonymous functions**](doc/block.md) (like [dfns](https://aplwiki.com/wiki/Dfn)) borrow some power from Lisp. But it's redesigned from the ground up, with many features new to the array paradigm: -* The [**based array model**](doc/based.md) eliminates the surprise of floating arrays and the hassle of explicit boxes, while dedicated [**list notation**](doc/arrayrepr.md#list-literals) does away with the [gotchas](doc/arrayrepr.md#why-not-whitespace) of [stranding](https://aplwiki.com/wiki/Strand_notation). +* The [**based array model**](doc/based.md) eliminates the surprise of floating arrays and the hassle of explicit boxes, while dedicated [**array notation**](doc/arrayrepr.md#array-literals) does away with the [gotchas](doc/arrayrepr.md#why-not-whitespace) of [stranding](https://aplwiki.com/wiki/Strand_notation). * [**Context-free grammar**](doc/context.md) makes it easier for machines and humans to understand code, and naturally leads to [**first-class functions**](doc/functional.md), which can even be used to [reinvent control structures](doc/control.md). * [**New symbols**](keymap.md) for built-in functionality make the syntactic role of every primitive instantly visible, and aim to be more consistent and intuitive. * No-nonsense [**namespace syntax**](doc/namespace.md) encapsulates data and even allows for a little [object-oriented programming](doc/oop.md). diff --git a/doc/arrayrepr.md b/doc/arrayrepr.md index e4f93948..ca2f3f86 100644 --- a/doc/arrayrepr.md +++ b/doc/arrayrepr.md @@ -84,11 +84,11 @@ The second is for lists with simple enough elements, which are displayed on one This case also covers empty lists, which are shown as `⟨⟩`. This includes an empty string, as the only difference between an empty string and any other empty list is its fill element and array displays don't depend on the fill. -## List literals +## Array literals *The tutorial section [here](../tutorial/list.md#list-notation) also covers this topic.* -There are three kinds literal notation for lists: strings, list notation, and stranding. Strings indicate character lists (with space for the [fill](fill.md)) and the other two can combine any sequence of elements. +There are three kinds literal notation for lists: strings, list notation, and stranding. Strings indicate character lists (with space for the [fill](fill.md)) and the other two can combine any sequence of elements. Additionally, there's a square bracket notation that can form higher-rank arrays. ### Strings @@ -121,6 +121,14 @@ BQN's separator rules give list notation a very flexible structure. You can put "e6" ⟩ +#### High-rank arrays + +Higher-rank arrays can be written with `[]`, an **array notation** that indicates each element is to be used as a [cell](array.md#cells) of its result. It's identical to forming a list and applying [Merge](couple.md#merge-and-array-theory) (`[…]` is the same as `>⟨…⟩`). + + [2‿3, 4‿1, 0‿5] + +This syntax doesn't work for creating rank 0 arrays—use [Enclose](enclose.md) `<` for these—or empty arrays. The notation `[]` would be ambiguous, so it's not allowed (although it can be used for destructuring, which works with an existing array). To create a specific empty array, [Reshape](reshape.md) (`⥊`) is probably the best approach. + ### Strands **Strand notation** is another way to write lists of length two or more. The elements are connected with the ligature character `‿`. It has a precedence lower than the [namespace](namespace.md) dot but higher than anything else other than paired brackets `()`, `{}`, and `⟨⟩`, so compound elements generally need to be placed in parentheses. Expressions joined by ligatures behave exactly the same as those in list notation: they are evaluated in order and placed in a list. @@ -146,13 +154,3 @@ Explicit stranding is also more general, because it applies equally to elements Why couldn't the more explicit list notation `⟨a,b,c⟩` drop the separators? This is also largely for reasons of generality—even more important here since `⟨⟩` is the more general-purpose list notation. Writing `⟨÷,-,4⟩` without the `,` won't go well. For something like `⟨2×c,b-1⟩`, maybe the interpreter could sort it out but it would be pretty confusing. Pretty soon you're going through the list character by character trying to figure out which space is actually a separator. And cursing, probably. Fortunately, I find that after a reasonable period of adjustment typing ligatures instead of spaces doesn't feel strange, and reading code is improved overall by the more explicit notation. A minor note is that lists of literal numbers, where APL-style stranding is best, tend to show up more in the snippets that beginners write to test out the language than in programs even in the tens of lines. So this issue sticks out in first experiences with BQN, but will come up less later on. - -### Array notation? - -BQN has literal notation for lists only right now. To get an array with rank other than 1, either [reshape](reshape.md) a list, or [merge](couple.md#merge-and-array-theory) a list of arrays: - - ∘‿2 ⥊ ⟨2,3, 4,1, 0,5⟩ - - [2‿3, 4‿1, 0‿5] - -The characters `[]` are reserved to potentially combine list notation with merging, allowing the above to be written `[2‿3, 4‿1, 0‿5]`. This would allow non-empty arrays with rank one or more to be written without a primitive, but not rank 0 or empty arrays. Since creating arrays in general would still require primitives like `<` or `⥊`, it's not clear whether this notation is worth it. General array notation is a surprisingly complicated topic; see the article about it [on the APL Wiki](https://aplwiki.com/wiki/Array_notation). diff --git a/doc/expression.md b/doc/expression.md index 754775ea..d5ca2035 100644 --- a/doc/expression.md +++ b/doc/expression.md @@ -2,7 +2,7 @@ # Expression syntax -BQN expressions are the part of [syntax](syntax.md) that describes computations to perform. Programs are mainly made up of expressions with a little organizing material like [blocks](block.md) and [namespaces](namespace.md) around them. This page explains how functions, modifiers, and assignment combine with their inputs. It doesn't describe [constant](syntax.md#constants) and [array](arrayrepr.md#list-literals) literals, which each form a single subject for grammatical purposes. +BQN expressions are the part of [syntax](syntax.md) that describes computations to perform. Programs are mainly made up of expressions with a little organizing material like [blocks](block.md) and [namespaces](namespace.md) around them. This page explains how functions, modifiers, and assignment combine with their inputs. It doesn't describe [constant](syntax.md#constants) and [array](arrayrepr.md#array-literals) literals, which each form a single subject for grammatical purposes. The [first tutorial](../tutorial/expression.md) also covers how to build and read BQN expressions. @@ -54,7 +54,7 @@ Primitive tokens, since they have a fixed value, always have a role that matches Variable names can be written in any case and with underscores added, and these changes don't affect what [identifier](lexical.md) the name refers to. `ab`, `aB`, `AB`, and `_a_B_` are all the same variable. However, the spelling—specifically the first and last characters—determine the variable's role. A lowercase first letter indicates a subject, and an uppercase first letter makes it a function. A leading underscore (regardless of the following character) indicates a 1-modifier, and both leading and trailing underscores makes a 2-modifier. -Besides these, character, string, and [list literals](arrayrepr.md#list-literals) always have a subject role, and the role of a [block](block.md) is determined by its type, which depends either on the header it has or which special variables it uses. +Besides these, character, string, and [array literals](arrayrepr.md#array-literals) always have a subject role, and the role of a [block](block.md) is determined by its type, which depends either on the header it has or which special variables it uses. The role of a compound expression, formed by applying an operation to some inputs, depends on the operation applied. This system is discussed in the remaining sections below. @@ -114,6 +114,12 @@ The left hand side of assignment in a subject expression can be *compound*, so t s +Array destructuring using `[]` is also possible: it's equivalent to splitting the right-hand side with `<˘` and then applying list destructuring. + + [t,u] ← ↕2‿3 + + u + Namespace destructuring uses an overlapping syntax, fully described in [its own section](namespace.md#imports). The left hand side is a list of names or aliases `to⇐from`. q‿r ↩ {q⇐2+r⇐0.5} ⋄ q diff --git a/doc/syntax.md b/doc/syntax.md index 7464d533..bbde476e 100644 --- a/doc/syntax.md +++ b/doc/syntax.md @@ -20,8 +20,9 @@ Glyph(s) | Meaning `⇐` | [Export](expression.md#exports) `↩` | [Change](expression.md#assignment) `⋄,` or newline | Statement or element [separator](#separators) -`⟨⟩` | [List](#list-notation) (rank-1 array) -`‿` | [Strand](#list-notation) (lightweight list syntax) +`⟨⟩` | [List](#list-and-array-notation) +`[]` | [Array](#list-and-array-notation) +`‿` | [Strand](#list-and-array-notation) (lightweight list syntax) `{}` | [Block](#blocks) such as a function definition `:` | [Block header](block.md#block-headers) `;` | [Block body separator](block.md#multiple-bodies) @@ -74,20 +75,22 @@ The four [roles](expression.md#syntactic-role) (subject, function, two kinds of The double arrow `⇐` is used for functionality relating to [namespaces](namespace.md). It has a few purposes: exporting assignment `name⇐value`, plain export `name⇐`, and aliasing `⟨alias⇐field⟩←namespace`. A block that uses it for export returns a namespace rather than the result of its last statement. The other namespace-related bit of syntax is field access `ns.field`. -## Lists and blocks +## Arrays and blocks -Lists and code blocks can both be represented as sequences of expressions in source code. They both have paired bracket representations, using `⟨⟩` for lists and `{}` for blocks, as well as a shortcut "stranding" notation using `‿` for lists. +Arrays and code blocks can both be represented as sequences of expressions in source code. There are paired bracket representations, using `⟨⟩` for lists, `[]` for arrays, and `{}` for blocks, as well as a shortcut "stranding" notation using `‿` for lists. ### Separators The characters `⋄` and `,` and newline are completely interchangeable and are used to separate expressions. An expression might be an element in a list or a line in a block. Empty sections—those that consist only of whitespace—are ignored. This means that any number of separators can be used between expressions, and that leading and trailing separators are also allowed. The expressions are evaluated in text order: left to right and top to bottom. -### List notation +### List and array notation -*[Full documentation](arrayrepr.md#list-literals)* +*[Full documentation](arrayrepr.md#array-literals)* Lists (1-dimensional arrays) are enclosed in angle brackets `⟨⟩`, with the results of the expressions in between being the list's elements. Lists of two elements or more can also be written with the ligature character `‿`. This character has higher binding strength than any part of an expression except `.` for namespace field access. If one of the elements is a compound expression, then it will need to be enclosed in parentheses. +Arrays, or at least non-empty ones with rank 1 or more, can be written with square brackets `[]`. These work just like angle brackets but [merge](couple.md#merge-and-array-theory) the elements so that they form cells of the result. + ### Blocks *[Full documentation](block.md)* diff --git a/docs/doc/arrayrepr.html b/docs/doc/arrayrepr.html index 6009a771..06a55f82 100644 --- a/docs/doc/arrayrepr.html +++ b/docs/doc/arrayrepr.html @@ -158,9 +158,9 @@ ⟨⟩

This case also covers empty lists, which are shown as ⟨⟩. This includes an empty string, as the only difference between an empty string and any other empty list is its fill element and array displays don't depend on the fill.

-

List literals

+

Array literals

The tutorial section here also covers this topic.

-

There are three kinds literal notation for lists: strings, list notation, and stranding. Strings indicate character lists (with space for the fill) and the other two can combine any sequence of elements.

+

There are three kinds literal notation for lists: strings, list notation, and stranding. Strings indicate character lists (with space for the fill) and the other two can combine any sequence of elements. Additionally, there's a square bracket notation that can form higher-rank arrays.

Strings

A string consists of a sequence of characters surrounded by double quotes "". The only rule for the characters inside is that any double quote must be escaped by repeating it twice; otherwise the string ends at that point.

↗️
    "-'×%""*"
@@ -192,6 +192,16 @@
   "e6"
 ⟩
+

High-rank arrays

+

Higher-rank arrays can be written with [], an array notation that indicates each element is to be used as a cell of its result. It's identical to forming a list and applying Merge ([…] is the same as >⟨…⟩).

+↗️
    [2‿3, 4‿1, 0‿5]
+┌─     
+╵ 2 3  
+  4 1  
+  0 5  
+      ┘
+
+

This syntax doesn't work for creating rank 0 arrays—use Enclose < for these—or empty arrays. The notation [] would be ambiguous, so it's not allowed (although it can be used for destructuring, which works with an existing array). To create a specific empty array, Reshape (⥊) is probably the best approach.

Strands

Strand notation is another way to write lists of length two or more. The elements are connected with the ligature character ‿. It has a precedence lower than the namespace dot but higher than anything else other than paired brackets (), {}, and ⟨⟩, so compound elements generally need to be placed in parentheses. Expressions joined by ligatures behave exactly the same as those in list notation: they are evaluated in order and placed in a list.

↗️
    +‿´‿∘‿×
@@ -213,20 +223,3 @@
 
Explicit stranding is also more general, because it applies equally to elements of any role. 2‿+‿3 is a perfectly fine list in BQN—maybe it's part of an AST—while 2 + 3 is clearly not a list. Meanwhile J and K restrict their stranding even further, to numbers only. It does mean that issues with stranding show up in fewer cases, but it also means that changing one element of a list from a constant to a variable requires rewriting the whole list.

 
Why couldn't the more explicit list notation ⟨a,b,c⟩ drop the separators? This is also largely for reasons of generality—even more important here since ⟨⟩ is the more general-purpose list notation. Writing ⟨÷,-,4⟩ without the , won't go well. For something like ⟨2×c,b-1⟩, maybe the interpreter could sort it out but it would be pretty confusing. Pretty soon you're going through the list character by character trying to figure out which space is actually a separator. And cursing, probably.

 
Fortunately, I find that after a reasonable period of adjustment typing ligatures instead of spaces doesn't feel strange, and reading code is improved overall by the more explicit notation. A minor note is that lists of literal numbers, where APL-style stranding is best, tend to show up more in the snippets that beginners write to test out the language than in programs even in the tens of lines. So this issue sticks out in first experiences with BQN, but will come up less later on.

-
Array notation?

-
BQN has literal notation for lists only right now. To get an array with rank other than 1, either reshape a list, or merge a list of arrays:

-↗️
    ∘‿2 ⥊ ⟨2,3, 4,1, 0,5⟩
-┌─     
-╵ 2 3  
-  4 1  
-  0 5  
-      ┘
-
-    [2‿3, 4‿1, 0‿5]
-┌─     
-╵ 2 3  
-  4 1  
-  0 5  
-      ┘
-

-
The characters [] are reserved to potentially combine list notation with merging, allowing the above to be written [2‿3, 4‿1, 0‿5]. This would allow non-empty arrays with rank one or more to be written without a primitive, but not rank 0 or empty arrays. Since creating arrays in general would still require primitives like < or ⥊, it's not clear whether this notation is worth it. General array notation is a surprisingly complicated topic; see the article about it on the APL Wiki.

diff --git a/docs/doc/expression.html b/docs/doc/expression.html
index b2f40951..067eed73 100644
--- a/docs/doc/expression.html
+++ b/docs/doc/expression.html
@@ -5,7 +5,7 @@
 
 
(github) / BQN / doc

 
Expression syntax

-
BQN expressions are the part of syntax that describes computations to perform. Programs are mainly made up of expressions with a little organizing material like blocks and namespaces around them. This page explains how functions, modifiers, and assignment combine with their inputs. It doesn't describe constant and array literals, which each form a single subject for grammatical purposes.

+
BQN expressions are the part of syntax that describes computations to perform. Programs are mainly made up of expressions with a little organizing material like blocks and namespaces around them. This page explains how functions, modifiers, and assignment combine with their inputs. It doesn't describe constant and array literals, which each form a single subject for grammatical purposes.

 
The first tutorial also covers how to build and read BQN expressions.

 
Overview

 
BQN expressions consist of subjects, functions, and modifiers arranged in sequence, with parentheses to group parts into subexpressions. Assignment arrows ← and ↩ can also be present and mostly behave similar to functions. Functions can be applied to subjects or grouped into trains, while modifiers can be applied to subjects or functions. The most important kinds of application are:

@@ -106,7 +106,7 @@
 
 
Primitive tokens, since they have a fixed value, always have a role that matches their type. They are functions, unless they fall into one of the two modifier patterns. 1-modifiers have superscript glyphs, and 2-modifiers have glyphs with an unbroken circle—that is, one without a line through it, excluding functions ⌽ and ⍉.

 
Variable names can be written in any case and with underscores added, and these changes don't affect what identifier the name refers to. ab, aB, AB, and _a_B_ are all the same variable. However, the spelling—specifically the first and last characters—determine the variable's role. A lowercase first letter indicates a subject, and an uppercase first letter makes it a function. A leading underscore (regardless of the following character) indicates a 1-modifier, and both leading and trailing underscores makes a 2-modifier.

-
Besides these, character, string, and list literals always have a subject role, and the role of a block is determined by its type, which depends either on the header it has or which special variables it uses.

+
Besides these, character, string, and array literals always have a subject role, and the role of a block is determined by its type, which depends either on the header it has or which special variables it uses.

 
The role of a compound expression, formed by applying an operation to some inputs, depends on the operation applied. This system is discussed in the remaining sections below.

 
Nothing

 
The character · is called Nothing. While it can be easier to think of it as a value, it can't be passed around in variables, and so can also be interpreted as an element of syntax. The special name 𝕨 also functions as Nothing if the block that contains it is called with one argument (the uppercase spelling 𝕎 doesn't, but instead immediately causes an error). Both · and 𝕨 have a subject role.

@@ -218,6 +218,16 @@
     s
 ⟨ 0 1 2 3 ⟩
+

Array destructuring using [] is also possible: it's equivalent to splitting the right-hand side with <˘ and then applying list destructuring.

+↗️
    [t,u] ← ↕2‿3
+┌─                         
+╵ ⟨ 0 0 ⟩ ⟨ 0 1 ⟩ ⟨ 0 2 ⟩  
+  ⟨ 1 0 ⟩ ⟨ 1 1 ⟩ ⟨ 1 2 ⟩  
+                          ┘
+
+    u
+⟨ ⟨ 1 0 ⟩ ⟨ 1 1 ⟩ ⟨ 1 2 ⟩ ⟩
+

Namespace destructuring uses an overlapping syntax, fully described in its own section. The left hand side is a list of names or aliases to⇐from.

↗️
    q‿r ↩ {q⇐2+r⇐0.5} ⋄ q
 2.5
diff --git a/docs/doc/syntax.html b/docs/doc/syntax.html
index 6312fbbd..a5c75b6e 100644
--- a/docs/doc/syntax.html
+++ b/docs/doc/syntax.html
@@ -58,11 +58,15 @@
 
 
 ⟨⟩
-List (rank-1 array)
+List
+
+
+[]
+Array
 
 
 ‿
-Strand (lightweight list syntax)
+Strand (lightweight list syntax)
 
 
 {}
@@ -182,13 +186,14 @@
 
The four roles (subject, function, two kinds of modifier) describe expressions, not values. When an expression is evaluated, the value's type doesn't have to correspond to its role, and can even change from one evaluation to another. An expression's role is determined entirely by its source code, so it's fixed.

 
Assignment arrows ←, ↩, and ⇐ store expression results in variables: ← and ⇐ create new variables while ↩ modifies existing ones. The general format is Name ← Value, where the two sides have the same role. Additionally, lhs F↩ rhs is a shortened form of lhs ↩ lhs F rhs and lhs F↩ expands to lhs ↩ F lhs.

 
The double arrow ⇐ is used for functionality relating to namespaces. It has a few purposes: exporting assignment name⇐value, plain export name⇐, and aliasing ⟨alias⇐field⟩←namespace. A block that uses it for export returns a namespace rather than the result of its last statement. The other namespace-related bit of syntax is field access ns.field.

-
Lists and blocks

-
Lists and code blocks can both be represented as sequences of expressions in source code. They both have paired bracket representations, using ⟨⟩ for lists and {} for blocks, as well as a shortcut "stranding" notation using ‿ for lists.

+
Arrays and blocks

+
Arrays and code blocks can both be represented as sequences of expressions in source code. There are paired bracket representations, using ⟨⟩ for lists, [] for arrays, and {} for blocks, as well as a shortcut "stranding" notation using ‿ for lists.

 
Separators

 
The characters ⋄ and , and newline are completely interchangeable and are used to separate expressions. An expression might be an element in a list or a line in a block. Empty sections—those that consist only of whitespace—are ignored. This means that any number of separators can be used between expressions, and that leading and trailing separators are also allowed. The expressions are evaluated in text order: left to right and top to bottom.

-
List notation

-
Full documentation

+
List and array notation

+
Full documentation

 
Lists (1-dimensional arrays) are enclosed in angle brackets ⟨⟩, with the results of the expressions in between being the list's elements. Lists of two elements or more can also be written with the ligature character ‿. This character has higher binding strength than any part of an expression except . for namespace field access. If one of the elements is a compound expression, then it will need to be enclosed in parentheses.

+
Arrays, or at least non-empty ones with rank 1 or more, can be written with square brackets []. These work just like angle brackets but merge the elements so that they form cells of the result.

 
Blocks

 
Full documentation

 
Blocks are written with curly braces {} and can have a subject, function, or modifier role. The contents are any number of bodies separated by ;. Each body is a sequence of expressions to be evaluated in order, possibly with a header, followed by :, that sets the type and describes expected inputs. A body runs in its own environment according to the rules of lexical scoping. The result is either a namespace, if the body used ⇐, or the result of the last expression.

diff --git a/docs/help/beginlist.html b/docs/help/beginlist.html
index 478c61d8..0f1493be 100644
--- a/docs/help/beginlist.html
+++ b/docs/help/beginlist.html
@@ -6,7 +6,7 @@
 
(github) / BQN / help

 
Mathematical Left Angle Bracket (⟨)

 
⟨ ...: Begin list

-
→full documentation

+
→full documentation

 
Starts a list. Inner elements must be separated by , or ⋄.
 Lists can be nested in other lists.

 
Must end with a corresponding ⟩.

diff --git a/docs/help/endlist.html b/docs/help/endlist.html
index 5355f722..ddc54ed5 100644
--- a/docs/help/endlist.html
+++ b/docs/help/endlist.html
@@ -6,7 +6,7 @@
 
(github) / BQN / help

 
Mathematical Right Angle Bracket (⟩)

 
... ⟩: End list

-
→full documentation

+
→full documentation

 
Ends a list started by a ⟨. See Begin List for more details.

 ↗️
    ⟨1, 2, 3⟩
 ⟨ 1 2 3 ⟩
diff --git a/docs/help/strand.html b/docs/help/strand.html
index 60d577aa..d464f95c 100644
--- a/docs/help/strand.html
+++ b/docs/help/strand.html
@@ -6,7 +6,7 @@
 
(github) / BQN / help

 
Undertie (‿)

 
‿: Strand

-
→full documentation

+
→full documentation

 
Create a list via strand notation.

 
Placing ‿ between valid BQN expressions will create a list out of the end results of those expressions.

 ↗️
    1‿2‿3
diff --git a/docs/index.html b/docs/index.html
index 1b13d42c..962ea837 100644
--- a/docs/index.html
+++ b/docs/index.html
@@ -53,7 +53,7 @@
 
 
But it's redesigned from the ground up, with many features new to the array paradigm:

 
    
-
  • The based array model eliminates the surprise of floating arrays and the hassle of explicit boxes, while dedicated list notation does away with the gotchas of stranding.
    • 
+
  • The based array model eliminates the surprise of floating arrays and the hassle of explicit boxes, while dedicated array notation does away with the gotchas of stranding.
    • 
 
  • Context-free grammar makes it easier for machines and humans to understand code, and naturally leads to first-class functions, which can even be used to reinvent control structures.
    • 
 
  • New symbols for built-in functionality make the syntactic role of every primitive instantly visible, and aim to be more consistent and intuitive.
    • 
 
  • No-nonsense namespace syntax encapsulates data and even allows for a little object-oriented programming.
    • 
diff --git a/help/beginlist.md b/help/beginlist.md
index c1dee17b..f0ba9fdd 100644
--- a/help/beginlist.md
+++ b/help/beginlist.md
@@ -3,7 +3,7 @@
 # Mathematical Left Angle Bracket (`⟨`)
 
 ## `⟨ ...`: Begin list
-[→full documentation](../doc/syntax.md#list-notation)
+[→full documentation](../doc/syntax.md#list-and-array-notation)
 
 Starts a list. Inner elements must be separated by `,` or `⋄`.
 Lists can be nested in other lists.
diff --git a/help/endlist.md b/help/endlist.md
index 234690aa..75404314 100644
--- a/help/endlist.md
+++ b/help/endlist.md
@@ -3,7 +3,7 @@
 # Mathematical Right Angle Bracket (`⟩`)
 
 ## `... ⟩`: End list
-[→full documentation](../doc/syntax.md#list-notation)
+[→full documentation](../doc/syntax.md#list-and-array-notation)
 
 Ends a list started by a `⟨`. See [Begin List](beginlist.md) for more details.
 
diff --git a/help/strand.md b/help/strand.md
index 696bb1d5..165d796c 100644
--- a/help/strand.md
+++ b/help/strand.md
@@ -3,7 +3,7 @@
 # Undertie (`‿`)
 
 ## `‿`: Strand
-[→full documentation](../doc/syntax.md#list-notation)
+[→full documentation](../doc/syntax.md#list-and-array-notation)
 
 Create a list via [strand notation](../doc/arrayrepr.md#strands).
 
-- 
cgit v1.2.3