Support line breaks inside brackets in markdown BQN evaluation

5 files changed, 69 insertions, 66 deletions

diff --git a/doc/arrayrepr.md b/doc/arrayrepr.md
index cc437ed1..04ce96f4 100644
--- a/doc/arrayrepr.md
+++ b/doc/arrayrepr.md
@@ -24,7 +24,8 @@ Array displays show only the array shape and elements. The [fill](fill.md) is an
 
 Those top-left and bottom-right corners are a distinctive part of BQN's display, as other systems almost always completely enclose the contents. BQN could add the other two corners, naturally; it just doesn't. Within the corners, elements are separated by whitespace only, and generally aligned to the top left.
 
-        ⟨2,"xy"⟩≍⟨2‿2⥊"abcd",4⟩  # Nested 2×2 array
+        [⟨2         , "xy"⟩
+         ⟨2‿2⥊"abcd", 4   ⟩]
 
 The lack of extra separation is to make it clear that the corners enclose the whole array rather than any of its elements (elements are still distinguishable becase an individual element won't contain whitespace, except maybe between quotes). Every set of corners indicates one array. This is a good fit for the [based array model](based.md), where data doesn't have to be in an array.
 
@@ -44,9 +45,9 @@ Up to one axis can be oriented horizontally, and then all the rest are laid out
 
 We've seen already that elements of a list are placed side by side, while the rows of a table (rank-2 array) are stacked on top of each other.
 
-        <¨ ↕5        # A list of units
+        <¨ ↕5          # A list of units
 
-        2‿3‿4≍1‿0‿5  # A table
+        [2‿3‿4,1‿0‿5]  # A table
 
 The 2-cells of a rank 3 array are *also* stacked on top of each other, but separated by a space. Below is a list of two examples. The second cell in the character array is marked with a `·` to indicate that the gap above it really separates cells as opposed to just being a row of space characters.
 
@@ -110,16 +111,16 @@ Entries in a list are evaluated in source order, and the value will be the list
 
 BQN's separator rules give list notation a very flexible structure. You can put all the elements on one line or spread them across lines, with the option of adding blank lines between elements. A separator at the end of a line is never needed, but leading and trailing separators are allowed.
 
-    ⟨
-      "e0", "e1"
-      ⟨
-        'e'
-        '2'
-      ⟩
-      "e3", "e4", "e5"
+        ⟨
+          "e0", "e1"
+          ⟨
+            'e'
+            '2'
+          ⟩
+          "e3", "e4", "e5"
 
-      "e6"
-    ⟩
+          "e6"
+        ⟩
 
 #### High-rank arrays
 
diff --git a/doc/block.md b/doc/block.md
index 823007f1..e4d32fa4 100644
--- a/doc/block.md
+++ b/doc/block.md
@@ -20,7 +20,11 @@ Because they use [lexical scoping](lexical.md), blocks also encapsulate code. If
 
 In the simplest case a block is just a list of statements, which are executed to *evaluate* the block. A block with no special names like `𝕨` or `𝕩` is called an *immediate block*, and is evaluated as soon as it is reached. The only thing such a block does is group some statements, and create a scope for them so that definitions made there are discarded when the block finishes. Even this small amount of functionality could be useful; as an example the following program can build up an array from named components without polluting the rest of the program with those names.
 
-        updown ← { up←↕5 ⋄ down←⌽up ⋄ up∾down }
+        updown ← {
+          up ← ↕5
+          down ← ⌽up
+          up∾down
+        }
         updown
 
 An immediate block is only ever evaluated once, and can't be used for control flow in a program. Special names can be used to define [functions and modifiers](ops.md), which have a broader range of uses. All special names are listed below:
@@ -105,9 +109,10 @@ Because `𝕣` only ever refers to a 1-modifier or 2-modifer, it can never make
 
 As a program becomes larger, it often becomes necessary to name inputs to blocks rather than just using special names. It can also become difficult to identify what kind of block is being defined, as it requires scanning through the block for special names. A *block header*, which is separated from the body of a block by a colon `:`, specifies the kind of block and can declare names for the block and its inputs.
 
-    Fact ← { F n:
-      n × (0⊸<)◶1‿F n-1
-    }
+        Fact_head ← { F n:
+          n × (0⊸<)◶1‿F n-1
+        }
+        Fact_head 7
 
 Its syntax mirrors an application of the block. As suggested by the positioning, the names given in a header apply only inside the block: for example `F` above is only defined inside the `{}` braces while `Fact` could be used either outside or inside. Some other possibilites are given below.
 
@@ -175,7 +180,11 @@ Blocks can include more than one body, separated by semicolons `;`. The body use
 
 Bodies with headers come before any that don't have them. When a block is called, its headers are checked in order for compatibility with the arguments, and the first body with a compatible header is used.
 
-        CaseAdd ← { 2𝕊3:0‿5 ; 2𝕊𝕩:⟨1,2+𝕩⟩ ; 𝕊𝕩:2‿𝕩 }
+        CaseAdd ← {
+          2𝕊3: 0‿5 ;
+          2𝕊𝕩: ⟨1,2+𝕩⟩ ;
+           𝕊𝕩: 2‿𝕩
+        }
 
         2 CaseAdd 3
 
@@ -191,12 +200,13 @@ If no header is compatible, the call results in an error.
 
 A special rule allows for convenient case-matching syntax for one-argument functions. In any function header with one argument, the function name can be omitted as long as the argument is *not* a plain identifier—it must be `𝕩` or a compound value like a list to distinguish it from an immediate block label.
 
-    Test ← {
-      "abc": "string" ;
-      ⟨2,b⟩: ⌽𝕩       ;
-      5:     "number" ;
-      𝕩:     "default"
-    }
+        Test ← {
+          "abc": "string" ;
+          ⟨2,b⟩: ⌽𝕩       ;
+          5:     "number" ;
+          𝕩:     "default"
+        }
+        Test 5
 
 These case-style headers function exactly the same as if they were preceded by `𝕊`, and can be mixed with other kinds of headers.
 
diff --git a/doc/functional.md b/doc/functional.md
index cd7656ca..7f44f877 100644
--- a/doc/functional.md
+++ b/doc/functional.md
@@ -102,14 +102,13 @@ What does functional programming in BQN look like? How is it different from the
 
 First, let's look at the basics: a small program that has functions as its argument and result. The function `Lin` below gives a [linear approximation](https://en.wikipedia.org/wiki/Linear_approximation) to its function argument based on the values at 0 and 1. To find these two values, we call the argument as a function by using its uppercase spelling, `𝕏`.
 
-    Lin ← {
-      v0 ← 𝕏 0
-      v0 + ((𝕏 1) - v0) × ⊢
-    }
+        Lin ← {
+          v0 ← 𝕏 0
+          v0 + ((𝕏 1) - v0) × ⊢
+        }
 
 We can pass it the [exponential](arithmetic.md#basic-arithmetic) function as an argument by giving it the name `Exp` and then referring to it in lowercase (that is, in a subject role). The result is a [train](train.md) that adds 1 to *e*-1 times the argument (we'll discuss only tacit functions here; for blocks see [lexical scoping](lexical.md)).
 
-        Lin ← { v0←𝕏0 ⋄ v0+((𝕏1)-v0)×⊢ }  # (copy of above)
         Exp ← ⋆
         Lin exp
 
@@ -128,14 +127,13 @@ Not the most accurate approximation, though.
 
 Note also in this case that we could have used a modifier with a very similar definition to `Lin`. The modifier is identical in definition except that `𝕏` is replaced with `𝔽`.
 
-    _lin ↩ {
-      v0 ← 𝔽 0
-      v0 + ((𝔽 1) - v0) × ⊢
-    }
+        _lin ↩ {
+          v0 ← 𝔽 0
+          v0 + ((𝔽 1) - v0) × ⊢
+        }
 
 Its call syntax is simpler as well. In other cases, however, the function version might be preferable, for example when dealing with arrays of functions or many arguments including a function.
 
-        _lin ↩ { v0←𝔽0 ⋄ v0+((𝔽1)-v0)×⊢ }  # (copy again)
         Exp _lin 5
 
 ### Arrays of functions
diff --git a/doc/oop.md b/doc/oop.md
index bca8287b..9f007566 100644
--- a/doc/oop.md
+++ b/doc/oop.md
@@ -23,21 +23,21 @@ Mixins              | Not really (needs `this`)
 
 An object in BQN is simply a namespace: its fields and methods are variables in the namespace, and a variable can be accessed outside of the namespace with dot syntax if it's exported with `⇐`. Unexported variables are instance-private in OOP parlance, meaning that they're only visible to the object containing them. They could be utilities, or hold state for the object. As an example, the object below implements the [Tower of Hanoi](https://en.wikipedia.org/wiki/Tower_of_Hanoi) puzzle with five disks. You can view the state (a list of disks occupying each of the three rods) with `towerOfHanoi.View`, or move the top disk from one rod to another with `towerOfHanoi.Move`.
 
-    towerOfHanoi ← {
-      l ← ↕¨5‿0‿0
-      View ⇐ {𝕤
-        l
-      }
-      Move ⇐ {from‿to:
-        l ↩ Transfer´⌾(𝕩⊸⊏)⍟(≠´𝕩) l
-      }
-      # Move a disk from 𝕨 to 𝕩
-      Transfer ← {
-        "No disk to move"!0<≠𝕨
-        "Can't place larger disk on smaller one"!(0<≠)◶⟨1,𝕨<○⊑⊢⟩𝕩
-        ⟨1↓𝕨, 𝕨⊏⊸∾𝕩⟩
-      }
-    }
+        towerOfHanoi ← {
+          l ← ↕¨5‿0‿0
+          View ⇐ {𝕤
+            l
+          }
+          Move ⇐ {from‿to:
+            l ↩ Transfer´⌾(𝕩⊸⊏)⍟(≠´𝕩) l
+          }
+          # Move a disk from 𝕨 to 𝕩
+          Transfer ← {
+            "No disk to move"!0<≠𝕨
+            "Can't place larger disk on smaller one"!(0<≠)◶⟨1,𝕨<○⊑⊢⟩𝕩
+            ⟨1↓𝕨, 𝕨⊏⊸∾𝕩⟩
+          }
+        }
 
 Two variables `l` and `Transfer` aren't exported, for two different reasons. `l` encodes the state of the tower, but it's only exposed with the function `View`, which allows the internal representation to be changed freely. `Transfer` is just a utility function. While it's not dangerous to use outside of the object, there's no reason to expose it through `towerOfHanoi`'s interface. If it's wanted in another place it should be moved to a common location.
 
@@ -45,19 +45,14 @@ Here are the results of a few applications of these functions.
 
         t ← towerOfHanoi
         t.View@
-    ⟨ ⟨ 0 1 2 3 4 ⟩ ⟨⟩ ⟨⟩ ⟩
 
         t.Move 0‿2
-    ⟨ ⟨ 1 2 3 4 ⟩ ⟨⟩ ⟨ 0 ⟩ ⟩
 
         t.Move 1‿2
-    ! "No disk to move"
 
         t.Move 0‿1
-    ⟨ ⟨ 2 3 4 ⟩ ⟨ 1 ⟩ ⟨ 0 ⟩ ⟩
 
         t.Move 2‿1
-    ⟨ ⟨ 2 3 4 ⟩ ⟨ 0 1 ⟩ ⟨⟩ ⟩
 
 ## Classes
 
diff --git a/doc/quick.md b/doc/quick.md
index 2b3baafc..962216cc 100644
--- a/doc/quick.md
+++ b/doc/quick.md
@@ -41,12 +41,12 @@ Now let's see how it works.
 
 ## Case conversion
 
-    # Case conversion utilities
-    case ← {
-      diff ← -´ "Aa"
-      Lower ⇐ -⟜diff
-      Upper ⇐ Lower⁼
-    }
+        # Case conversion utilities
+        case ← {
+          diff ← -´ "Aa"
+          Lower ⇐ -⟜diff
+          Upper ⇐ Lower⁼
+        }
 
 This part of the code defines a [namespace](namespace.md) using braces `{}`, then [assigns](expression.md#assignment) it to the name `case`. There are three assignments inside the namespace too. Since BQN uses [lexical scoping](lexical.md), code outside the namespace can't access the variables `diff`, `Lower`, and `Upper` directly. Oh, and the first line is a [comment](token.md#comments).
 
@@ -113,23 +113,22 @@ The function that does this is [Enclose](enclose.md) [Cells](rank.md), `<˘`. Th
 This statement consists of the name `hw` just defined, a compound function, and then the new character `↩`. This is another form of [assignment](expression.md#assignment), like `←`, but it changes the value of an existing variable instead of defining a new one. There's also some special `↩` syntax here: the expression `val Fn↩` is shorthand for `val ↩ Fn val`, avoiding the need to write the name `hw` twice (and `val Fn↩ arg` means `val ↩ val Fn arg`, like `+=` and so on from C). So we are modifying `hw` by applying this function `case.Upper⌾(⊑¨)`.
 
         hw ← <˘ 2‿∘ ⥊ "helloworld"
-        Upper ← -⟜(-´"Aa")⁼
 
-        Upper⌾(⊑¨) hw
+        case.Upper⌾(⊑¨) hw
 
-        hw Upper⌾(⊑¨)↩  # Sets new value for hw
+        hw case.Upper⌾(⊑¨)↩  # Sets new value for hw
 
 That converts the first character of each string to uppercase! `case.Upper` is the case conversion function defined before, so that part makes sense. The rest of the function, `⌾(⊑¨)`, would be pronounced "[Under](under.md) the [First](pick.md#first) of [Each](map.md#one-argument-mapping)", which… pretty much makes sense too? The First Each function extracts the first element of each list in `hw`, the part that used to be `"hw"` but is now `"HW"`.
 
         ⊑¨ hw
 
-        Upper "hw"
+        case.Upper "hw"
 
-The Under modifier keeps track of where that string came from and puts it *back*, to produce a new, altered array. It's kind of special, like Undo, but works on all sorts of fancy selections. It's also worth pointing out that `Upper` applies to a string here, not an individual character. That's because arithmetic is [pervasive](arithmetic.md#pervasion), so that functions made of arithmetic naturally work on arrays. Although in this case it wasn't really necessary, because it's also possible to map over the two strings and uppercase the first character of each separately:
+The Under modifier keeps track of where that string came from and puts it *back*, to produce a new, altered array. It's kind of special, like Undo, but works on all sorts of fancy selections. It's also worth pointing out that `case.Upper` applies to a string here, not an individual character. That's because arithmetic is [pervasive](arithmetic.md#pervasion), so that functions made of arithmetic naturally work on arrays. Although in this case it wasn't really necessary, because it's also possible to map over the two strings and uppercase the first character of each separately:
 
-        Upper⌾⊑¨ "hello"‿"world"
+        case.Upper⌾⊑¨ "hello"‿"world"
 
-Modifiers are applied from left to right, opposite to functions (1-modifiers also take the operand on the left while prefix functions have the argument on the right). So `Upper⌾⊑¨` means `(Upper⌾⊑)¨`.
+Modifiers are applied from left to right, opposite to functions (1-modifiers also take the operand on the left while prefix functions have the argument on the right). So `case.Upper⌾⊑¨` means `(case.Upper⌾⊑)¨`.
 
 ### Punctuation and printing