From 93f75e97685520cdad3afab0134e2f65e5e211e2 Mon Sep 17 00:00:00 2001 From: Marshall Lochbaum Date: Tue, 21 Jul 2020 19:48:24 -0400 Subject: =?UTF-8?q?Add=20Insert=20(=CB=9D)=201-modifier?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- docs/doc/context.html | 2 +- docs/doc/fromDyalog.html | 8 ++++---- docs/doc/group.html | 6 +++--- docs/doc/transpose.html | 2 +- docs/doc/windows.html | 4 ++-- docs/index.html | 6 ++++++ docs/problems.html | 16 ++++++++-------- docs/spec/token.html | 2 +- 8 files changed, 26 insertions(+), 20 deletions(-) (limited to 'docs') diff --git a/docs/doc/context.html b/docs/doc/context.html index b4c5616f..8d108e5f 100644 --- a/docs/doc/context.html +++ b/docs/doc/context.html @@ -50,7 +50,7 @@ -

Unlike variables, BQN primitives have only one spelling, and a fixed role (but their values can be used in a different role by storing them in variables). Superscript glyphs ˜¨˘⁼⌜´` are used for 1-modifiers, and glyphs ∘○⊸⟜⌾⊘◶⚇⎉⍟ with an unbroken circle are 2-modifiers. Other primitives are functions. String and numeric literals are subjects.

+

Unlike variables, BQN primitives have only one spelling, and a fixed role (but their values can be used in a different role by storing them in variables). Superscript glyphs ˜¨˘⁼⌜´˝` are used for 1-modifiers, and glyphs ∘○⊸⟜⌾⊘◶⚇⎉⍟ with an unbroken circle are 2-modifiers. Other primitives are functions. String and numeric literals are subjects.

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.

diff --git a/docs/doc/fromDyalog.html b/docs/doc/fromDyalog.html index 0b9ca972..ec02f2e7 100644 --- a/docs/doc/fromDyalog.html +++ b/docs/doc/fromDyalog.html @@ -116,7 +116,7 @@ BQN ¨ ⌜ -´ +˝ ⎉ ⍟ ˜ @@ -175,19 +175,19 @@ ⍕ ⊥ {+⟜(𝕨⊸×)´⌽𝕩} ⊤ {𝕨|1↓⌊∘÷`⌾⌽𝕨∾<𝕩} - ⌹ +´∘×⎉1‿∞⁼ I guess + ⌹ +˝∘×⎉1‿∞⁼ I guess ⌷ N/A ⊏ - + - + diff --git a/docs/doc/group.html b/docs/doc/group.html index 590b166b..2ec68f63 100644 --- a/docs/doc/group.html +++ b/docs/doc/group.html @@ -138,17 +138,17 @@ ⟨ ⟨⟩ ⟨⟩ "string" "with" ⟨⟩ "spaces" ⟩

However, trailing spaces are ignored because Group never produces trailing empty groups (to get them back we would use a dummy final character in the string). To avoid empty words, we should increase the word index only once per group of spaces. We can do this by taking the prefix sum of a list that is 1 only for a space with no space before it. To make such a list, we can use the Windows function. We will extend our list with an initial 1 so that leading spaces will be ignored. Then we take windows of the same length as the original list: the first includes the dummy argument followed by a shifted copy of the list, and the second is the original list. These represent whether the previous and current characters are spaces; we want positions where the previous wasn't a space and the current is.

-
    ≍⟜((<´<˘)≠↕1∾⊢) ' '="  string with  spaces   "  # All, then filtered, spaces
+
    ≍⟜(<˝≠↕1∾⊢) ' '="  string with  spaces   "  # All, then filtered, spaces
 ┌─                                                 
 ╵ 1 1 0 0 0 0 0 0 1 0 0 0 0 1 1 0 0 0 0 0 0 1 1 1  
   0 0 0 0 0 0 0 0 1 0 0 0 0 1 0 0 0 0 0 0 0 1 0 0  
                                                   ┘
-    ≍⟜(⊢-˜¬×+`∘((<´<˘)≠↕1∾⊢))' '="  string with  spaces   "  # More processing
+    ≍⟜(⊢-˜¬×+`∘(<˝≠↕1∾⊢))' '="  string with  spaces   "  # More processing
 ┌─                                                         
 ╵  1  1 0 0 0 0 0 0  1 0 0 0 0  1  1 0 0 0 0 0 0  1  1  1  
   ¯1 ¯1 0 0 0 0 0 0 ¯1 1 1 1 1 ¯1 ¯1 2 2 2 2 2 2 ¯1 ¯1 ¯1  
                                                           ┘
-    ' '((⊢-˜¬×+`∘((<´<˘)≠↕1∾⊢))∘=⊔⊢)"  string with  spaces   "  # Final result
+    ' '((⊢-˜¬×+`∘(<˝≠↕1∾⊢))∘=⊔⊢)"  string with  spaces   "  # Final result
 ⟨ "string" "with" "spaces" ⟩
 

 
diff --git a/docs/doc/transpose.html b/docs/doc/transpose.html
index 3b5af23b..93e5da73 100644
--- a/docs/doc/transpose.html
+++ b/docs/doc/transpose.html
@@ -3,7 +3,7 @@
 
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

-
Transposing a matrix exchanges its axes, mirroring it across the diagonal. APL extends the function to any rank by reversing all axes, but this generalization isn't very natural and is almost never used. The main reason for it is to maintain the equivalence a MP b ←→ a MP⌾⍉ b, where MP ← (+´<˘)∘×⎉1‿∞ is the generalized matrix product. But even here APL's Transpose is suspect. It does much more work than it needs to, as we'll see.

+
Transposing a matrix exchanges its axes, mirroring it across the diagonal. APL extends the function to any rank by reversing all axes, but this generalization isn't very natural and is almost never used. The main reason for it is to maintain the equivalence a MP b ←→ a MP⌾⍉ b, where MP ← +˝∘×⎉1‿∞ is the generalized matrix product. But even here APL's Transpose is suspect. It does much more work than it needs to, as we'll see.

 
BQN's transpose takes the first axis of its argument and moves it to the end.

 
    ≢ a23456 ← ↕2‿3‿4‿5‿6
 ⟨ 2 3 4 5 6 ⟩
diff --git a/docs/doc/windows.html b/docs/doc/windows.html
index c20d6591..113d5ffd 100644
--- a/docs/doc/windows.html
+++ b/docs/doc/windows.html
@@ -81,11 +81,11 @@
 
A common task is to pair elements, with an initial or final element so the total length stays the same. This can also be done with a pairwise reduction, but another good way (and more performant without special support in the interpreter) is to add the element and then use windows matching the original length. Here both methods are used to invert +`, which requires we take pairwise differences starting at initial value 0.

 
    -˜´˘2↕0∾ +` 3‿2‿1‿1
 ⟨ 3 2 1 1 ⟩
-    ((-˜´<˘)≠↕0∾⊢) +` 3‿2‿1‿1
+    (-˜˝≠↕0∾⊢) +` 3‿2‿1‿1
 ⟨ 3 2 1 1 ⟩
 

 
This method extends to any number of initial elements. We can modify the running sum above to keep the length constant by starting with two zeros.

-
    ((+´<˘)≠↕(2⥊0)⊸∾) ⟨2,6,0,1,4,3⟩
+
    (+˝≠↕(2⥊0)⊸∾) ⟨2,6,0,1,4,3⟩
 ⟨ 2 8 8 7 5 8 ⟩
 

 
diff --git a/docs/index.html b/docs/index.html
index 57e708ba..711e419e 100644
--- a/docs/index.html
+++ b/docs/index.html
@@ -434,6 +434,12 @@
+ + + + + + diff --git a/docs/problems.html b/docs/problems.html index 252cdb1c..595ed18d 100644 --- a/docs/problems.html +++ b/docs/problems.html @@ -20,14 +20,6 @@

There are a lot of standard functions and I don't want to use separate primitives or a menu-style primitive like APL Circle for them. You can define all the functions eventually if you use complex exponential and take real and imaginary parts and inverses, but this doesn't sound well-suited for implementation. And there should be a math library that gives you the standard functions with normal names, but how will it be implemented?

Right-to-left multi-line functions go upwards

If you include multiple multi-line functions in what would otherwise be a one-liner, the flow in each function goes top to bottom but the functions are executed bottom to top. I think the fix here is to just say give your functions names and don't do this.

-

Array reductions are annoying

-

There are really three kinds of reduction a BQN programmer might want to use.

- -

It seems that the first is the most common, but the others aren't really rare. The current list reduction also encourages patterns like +´˘2↕mat, which don't work on higher-rank arrays and mix the result (possibly unwanted).

Subtraction, division, and span are backwards

The left argument feels much more like the primary one in these cases (indeed, this matches the typical left-to-right ordering of binary operators in mathematics). Not really fixable; too much precedent.

Can't access array ordering directly

@@ -104,6 +96,14 @@

I went with "Index of" and "Less Than or Equal to" but the last word blends into surrounding text. Should they be fully capitalized or hyphenated?

Solved problems

Problems that existed in mainstream APL or a transitional BQN that have in my opinion been put to rest (while in some cases introducing new problems). Listed in reverse chronological order by time solved, by my recollection.

+

Array reductions are annoying

+

There are really three kinds of reduction a BQN programmer might want to use.

+ +

BQN bounced between these some at first; eventually I decided it really needed two, with 𝔽˝ equivalent to 𝔽´<˘. The last requires two symbols, but they can always be used together as a unit, so I think this is no longer annoying.

"Modifier" and "composition" terminology

1-modifiers and 2-modifiers used to be called "modifiers" and "compositions", respectively, and sometimes "operators" collectively. The new names are much better, although they do leave a disconnect between the names for modifiers, and those for their inputs—"operands".

Can't return from inner functions

diff --git a/docs/spec/token.html b/docs/spec/token.html index c12fc3e4..3fcfbe6d 100644 --- a/docs/spec/token.html +++ b/docs/spec/token.html @@ -22,7 +22,7 @@ - + -- cgit v1.2.3
Operators
Syntax Monadic Dyadic
⌿ ´ ↕
⌿ ˝ ↕
⍀ ↑ or `
¨ ¨
⍨ ˜
⍣ ⍟
f.g (f´<˘)∘g⎉1‿∞
f.g f˝∘g⎉1‿∞
∘.f f⌜
A∘g A⊸g
f∘B f⟜B
˝Insert
` Scan
Primitive 1-Modifier˜˘¨⌜⁼´`˜˘¨⌜⁼´˝`
Primitive 1-Modifier