From acf90b32360c310c340965d41af30ffcb66ded04 Mon Sep 17 00:00:00 2001 From: Marshall Lochbaum Date: Mon, 9 Aug 2021 22:24:57 -0400 Subject: Section on why BQN rejects stranding with spaces --- docs/doc/arrayrepr.html | 12 ++++++++++++ 1 file changed, 12 insertions(+) (limited to 'docs/doc/arrayrepr.html') diff --git a/docs/doc/arrayrepr.html b/docs/doc/arrayrepr.html index 4c7f8268..99c485f7 100644 --- a/docs/doc/arrayrepr.html +++ b/docs/doc/arrayrepr.html @@ -201,6 +201,18 @@ 1

Strand notation is mainly useful for simple elements that don't require parentheses. A strand with one set of parentheses is no shorter than using list notation (but could look nicer), and one with more parentheses will be longer.

+

Why not whitespace?

+

In APL two or more arrays that are next to each other in the code are combined into a list, a convention known as stranding. So 2 3 5 + 1 adds a list to a number. This looks substantially cleaner than a BQN list, so it's reasonable to ask: why give it up? I admit I've been jealous of that clean look at times. But I'm also finding I view it with a certain unease: what's hiding in that space?

+

This feeling comes because the language is doing something I didn't ask it to, and it's justified. Consider the BQN expression a +˝∘×⎉1‿∞ b for a matrix product. If we remove the space then we have …⎉1 ∞ b. There's no good rule to say which of the three subjects 1, ∞, and b to strand together. For modifiers like Rank and Depth we'd like stranding to bind more tightly than modifier application, but in order to actually use arguments for these modifiers the modifier application should take precedence. Similar but simpler cases show up more often when binding an argument to a function. The difference between the following two statements is obvious in BQN, but with space-for-stranding one of them would require a complicating parenthesis.

+↗️
    3 1⊸+⊸× 5
+20
+
+    3‿1⊸+⊸× 5
+⟨ 40 30 ⟩
+
+

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. 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 can't the more explicit list notation ⟨a,b,c⟩ drop the separators? This is also largely for reasons of generality, which is even more important given that ⟨⟩ 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 probably 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⟩
-- 
cgit v1.2.3