From 0658e1ba9dc1095449e4c0289324955716d402ef Mon Sep 17 00:00:00 2001 From: Marshall Lochbaum Date: Sat, 13 Mar 2021 10:28:39 -0500 Subject: =?UTF-8?q?Use=20=E2=80=A2Eval=20or=20=E2=80=A2BQN=20instead=20of?= =?UTF-8?q?=20=E2=8D=8E?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- docs/doc/arithmetic.html | 16 ++++ docs/doc/fromDyalog.html | 6 +- docs/doc/fromJ.html | 15 ++++ docs/doc/oop.html | 137 ++++++++++++++++++++++++++++++ docs/doc/paradigms.html | 19 +++++ docs/doc/tacit.html | 213 +++++++++++++++++++++++++++++++++++++++++++++++ 6 files changed, 403 insertions(+), 3 deletions(-) create mode 100644 docs/doc/arithmetic.html create mode 100644 docs/doc/oop.html create mode 100644 docs/doc/paradigms.html create mode 100644 docs/doc/tacit.html (limited to 'docs') diff --git a/docs/doc/arithmetic.html b/docs/doc/arithmetic.html new file mode 100644 index 00000000..ee6e66ac --- /dev/null +++ b/docs/doc/arithmetic.html @@ -0,0 +1,16 @@ + + + + BQN: Arithmetic functions + +
BQN / main / doc
+

Arithmetic functions

+

BQN's arithmetic functions use mostly the same symbols as APL, and the functionality is actually defined by the language implementation's number system and not the specification, so there's not too much to say about them.

+

Summary of differences for APLers:

+ +

diff --git a/docs/doc/fromDyalog.html b/docs/doc/fromDyalog.html index f9c7eeaa..5a4f6241 100644 --- a/docs/doc/fromDyalog.html +++ b/docs/doc/fromDyalog.html @@ -280,7 +280,7 @@ * ⋆ ⍟ ⋆⁼ ! ×´1+↕ -˜(+÷○(×´)⊢)1+↕∘⊣ - ○ Some complex exponential stuff, maybe + ○ π⊸× •math ~ ¬ ¬∘∊/⊣ ? Library? ⍲ ¬∘∧ @@ -302,8 +302,8 @@ ⍋ ⍋ Give up ⍒ ⍒ Give up ≢ ≠ ≢ - ⍎ To be decided - ⍕ + ⍎ •Eval + ⍕ •Fmt ⊥ {+⟜(𝕨⊸×)´⌽𝕩} ⊤ {𝕨|1↓⌊∘÷`⌾⌽𝕨∾<𝕩} ⌹ +˝∘×⎉1‿∞⁼ I guess diff --git a/docs/doc/fromJ.html b/docs/doc/fromJ.html index 02fc397c..a39e156c 100644 --- a/docs/doc/fromJ.html +++ b/docs/doc/fromJ.html @@ -569,6 +569,16 @@ +". +•Eval + + + +": +•Fmt + + + e. ><∘∾∊¨⊢ ∊ @@ -598,6 +608,11 @@ ≡ + +o. +π⊸× +•math +

Some J modifier expressions are translated below. BQN doesn't keep track of the rank of functions, so the "close" compositions @ & &. have no BQN equivalents: instead, specify a rank after composing.

diff --git a/docs/doc/oop.html b/docs/doc/oop.html new file mode 100644 index 00000000..bfbdf2a7 --- /dev/null +++ b/docs/doc/oop.html @@ -0,0 +1,137 @@ + + + + Object-oriented programming in BQN + +
BQN / main / doc
+

Object-oriented programming in BQN

+

BQN's namespaces can be used to support a simple form of object-oriented programming (OOP) without type checking or inheritance. It's suitable for some program architectures but not others: making OOP work as a solution to every problem isn't a BQN design goal. In fact, BQN was never designed to support OOP at all! I added namespaces or modules as a way to structure programs. The techniques we're going to discuss are all just ways to use namespaces, and if it ever starts seeming like confusing magic it might help to go back to this model. However, thinking of namespaces as objects can be quite powerful in the right circumstances, and on this page I'm going to frame things in OOP terms. The following table shows which well-known aspects of OOP are supported in BQN:

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
FeatureIn BQN?
ObjectsYes (namespaces)
ClassesYes (function returning namespace)
FieldsYes
MethodsYes
Class variablesSort of
AccessPublic/instance-private
thisNo
Inheritance (is-a)No
Composition (has-a)Yes
InterfacesNo
Abstract classesNo
MixinsNot really (needs this)
+

Objects

+

An object in BQN is simply a namespace: its fields and methods are variables in the namespace, and one of these 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 only they're only visible to the object containing them. These might be used simply as utilities or they might hold state for the object. As an example, the object below implements the 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↓𝕨, 𝕨⊏⊸∾𝕩⟩
+  }
+}
+
+

Two fields l and Transfer aren't exported, for two different reasons. l encodes the state of the tower, but it's often better to expose it with the function View instead to allow the internal representation to be changed freely. Transfer is just a utility function. It's not dangerous to use outside of the object but 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.

+

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

+

The object above is a singleton: there's just one of it, at least in the scope it occupies. It's often more useful to have a class that can be used to create objects. What we'll call a "class" is a namespace function, that is, a function that contains ⇐ and so returns a namespace. It's very easy to convert a singleton object to a class: just add a no-op 𝕤 line to force it to be a function, and call it with @ when needed.

+
MakeStack ← {𝕤
+  st←@
+  Push⇐{   st↩𝕩‿st}
+  Pop ⇐{𝕤⋄ r‿s←st ⋄ st↩s ⋄ r}
+}
+
+

But there's no need to ignore the argument: often it's useful to initialize a class using one or two arguments. For example, the stack class above can be modified to use 𝕩 as an initial list of values for the stack.

+
MakeStack ← {
+  st←@
+  Push⇐{   st↩𝕩‿st}
+  Pop ⇐{𝕤⋄ r‿s←st ⋄ st↩s ⋄ r}
+  Push¨ 𝕩
+}
+
+

A stack is a particularly simple class to make because its state can be represented efficiently as a BQN value. Other data structures don't allow this, and will often require an extra Node class when they are implemented.

+

Mutability

+
MakeQueue ← {𝕤
+  t←h←e←{SetN⇐{h↩𝕩}}
+  Node←{v⇐𝕩⋄n⇐e ⋄ SetN⇐{n↩𝕩}}
+  Push⇐{t.SetN n←Node 𝕩 ⋄ t↩n}
+  Pop ⇐{𝕤⋄v←h.v⋄{t↩𝕩}⍟(e⊸=)h↩h.n⋄v}
+}
+
+

Composition

+

Class variables

+

Self-reference

+

An object's class is given by 𝕊. Remember, a class is an ordinary BQN function! It might be useful for an object to produce another object of the same class (particularly if it's immutable), and an object might also expose a field class⇐𝕤 to test whether an object o belongs to a class c with o.class = c.

+

It's not currently possible for an object to know its own value without some outside help, such as a special constructor:

+
IntrospectiveClass ← {
+  obj ← {
+    this⇐@
+    SetThis ⇐ { !this=@ ⋄ this↩𝕩 }
+  }
+  obj.setThis obj
+}
+
+

This is a pretty clunky solution, and exports a useless method SetThis (which gives an error if it's ever called). It would be possible for BQN to define a system value •this that just gets the namespace's value. It would work only at the top level, so it would have to be assigned (this←•this) in order to use it in functions. This means it's always used before the namespace is done being defined, so a drawback is that it introduces the possibility that an object used in a program has undefined fields. The reason this isn't possible for objects without •this is that BQN's blocks don't have any sort of control flow, so that they always execute every statement in order. The namespace becomes accessible as a value once the block finishes, and at this point every statement has been executed and every field is initialized.

diff --git a/docs/doc/paradigms.html b/docs/doc/paradigms.html new file mode 100644 index 00000000..091026dd --- /dev/null +++ b/docs/doc/paradigms.html @@ -0,0 +1,19 @@ + + + + BQN in programming paradigms + +
BQN / main / doc
+

BQN in programming paradigms

+

It hangs onto weakly positive connotations somehow, but the term "multi-paradigm" should not really impress you. Let's dig into exactly which paradigms BQN supports and how.

+

This information won't really tell you what tasks BQN is good for: after all, it turns out you can write a compiler entirely using array programming, something many people assumed was impossible. Instead, it tells you what approaches you can take to writing programs, and how comfortable you'll find it to work with BQN—or how much you can use it to stretch your brain in new directions.

+

dynamically typed +high level

+

BQN is not great for imperative programming.

+

imperative in which the programmer instructs the machine how to change its state, +procedural which groups instructions into procedures, +object-oriented which groups instructions with the part of the state they operate on,

+

declarative in which the programmer merely declares properties of the desired result, but not how to compute it +functional in which the desired result is declared as the value of a series of function applications, +logic or reactive

+

macros or reflection

diff --git a/docs/doc/tacit.html b/docs/doc/tacit.html new file mode 100644 index 00000000..20ba910a --- /dev/null +++ b/docs/doc/tacit.html @@ -0,0 +1,213 @@ + + + + Tacit (point-free) programming in BQN + +
BQN / main / doc
+

Tacit (point-free) programming in BQN

+

Tacit programming (APL Wiki) is a general term used to refer to ways to define functions that don't refer to arguments directly (say, with identifiers). Instead, tacit programs are built up by combining smaller functions together; we'll discuss the ways BQN offers to combine functions on this page. Since primitive functions like those returning the left (⊣) and right (⊢) arguments, and selection functions (⊏⊑), are available as building blocks, tacit programming doesn't keep the programmer from pinpointing a specific part of the input, as the description might lead you to believe. Nonetheless, it has its limitations. In larger tacit programs, moving values to the right place is tedious and error-prone because of the lack of a convenient labelling mechanism, and important context tends to disappear in a sea of symbols.

+

In smaller amounts—portions of a line—tacit programming can be the clearest way to express an idea, particularly when just one or two variables are used a few times. Consider the following three expressions to filter only the positive values from a list:

+↗️
    l ← 0‿5‿¯2‿1‿¯3‿¯4
+
+    (0<l)/l
+⟨ 5 1 ⟩
+    {(0<𝕩)/𝕩} l
+⟨ 5 1 ⟩
+    0⊸<⊸/ l
+⟨ 5 1 ⟩
+
+

The first of these expressions is the most direct, but with the variable name buried inside, it can't be used on an intermediate value and its input will have to be named. The other two forms stand alone as functions, so they can easily be placed anywhere in a program, even as an operand. But with even the small amount of structure added by a BQN anonymous function, the second method has more organization than action! The third, tacit, version strips away most of the organizing syntax to leave us with the essential pieces 0, <, and / joined by combinators. The explicit function uses 𝕩 as a sort of pronoun ("I want the elements of it where it's greater than zero"), while the tacit one elides it ("give me the elements greater than zero").

+

The ability to easily combine tacit and "explicit" programming such as statements or anonymous functions, far from being only a way to mitigate the disadvantages of these two methods, brings new advantages that no single paradigm could accomplish. Purely tacit programming requires programs to use no local variable names, but partly tacit programming allows them to use fewer names. That means names can be used only for the parts of a program that represent clean, human-understandable concepts. Another possible stategic choice is to use the fact that variables in a tacit expression are expanded as it's formed but those inside a block aren't. So F←a⊸+ can be chosen to "freeze" the value of a in F without having to use an extra variable, while F←{a+𝕩} uses the current value of a each time F is called.

+

The rest of this page describes BQN's tacit programming facilities. Deciding when to use them is a matter of taste, and experience.

+

Identity functions

+

These are the simplest functions possible. ⊢𝕩 is 𝕩 and ⊣𝕩 is 𝕩. 𝕨⊢𝕩 is 𝕩 and 𝕨⊣𝕩 is 𝕨. ⊢ returns its right argument and ⊣ returns its left argument but will settle for the right one if there's just one. ⊢ is {𝕩} and ⊣ is {𝕩;𝕨}. We will use them quite frequently here and you can decide at the end whether it's really worth it to soak up two symbols just to do nothing. Not that you'll change my mind about it.

+

Trains

+

In modern APL and its relatives, the backbone of tacit infrastructure is the function train. Trains can take some practice to understand and use well, so they're described in more depth on a dedicated page.

+

Trains are closely related to the mathematical convention that, for example, two functions F and G can be added to get a new function F+G that applies as (F+G)(x) = F(x)+G(x). In fact, with a little change to the syntax, we can do exactly this in BQN:

+↗️
    (⊢+⌽) ↕5
+⟨ 4 4 4 4 4 ⟩
+
+

So given a list of the first few natural numbers, that same list plus its reverse gives a list of just one number repeated many times. I'm sure if I were Gauss I'd be able to find some clever use for that fact. The mathematical convention extends to any central operator and any number of function arguments, which in BQN means we use any three functions, and call the train with a left argument as well—the only numbers of arguments BQN syntax allows are 1 and 2.

+↗️
    7 (+≍-) 2
+⟨ 9 5 ⟩
+
+

Here Couple (≍) is used to combine two units into a list, so we get seven plus and minus two. It's also possible to leave out the leftmost function of a train, or replace it with ·. In this case the function on the right is called, then the other function is called on its result—it's identical to the mathematical composition ∘, which is also part of BQN.

+↗️
    (∾⌽) "ab"‿"cde"‿"f"
+"fcdeab"
+    (·∾⌽) "ab"‿"cde"‿"f"
+"fcdeab"
+    ∾∘⌽ "ab"‿"cde"‿"f"
+"fcdeab"
+
+

The three functions ∾⌽, ·∾⌽, and ∾∘⌽ are completely identical. Why might we want three different ways to write the same thing? If we only want to define a function, there's hardly any difference. However, these three forms have different syntax, and might be easier or harder to use in different contexts. As we'll see, we can use ∾∘⌽ inside a train without parenthesizing it, and string ·∾⌽ but not ∾⌽ together with other trains. Let's look at how the train syntax extends to longer expressions.

+

Combinators

+ + + + Atop + + 𝔽∘𝔾 𝕩 + + + + + + 𝔽 + 𝔾 + 𝕩 + + + 𝕨 𝔽∘𝔾 𝕩 + + + + + + + + 𝔽 + 𝔾 + 𝕨 + 𝕩 + + + + + Over + + 𝔽○𝔾 𝕩 + + + + + + 𝔽 + 𝔾 + 𝕩 + + + 𝕨 𝔽○𝔾 𝕩 + + + + + + + + + + 𝔽 + 𝔾 + 𝔾 + 𝕨 + 𝕩 + + + + + Constant + + 𝕗˙ 𝕩 + + + + 𝕗 + 𝕩 + + + 𝕨 𝕗˙ 𝕩 + + + + + 𝕗 + 𝕨 + 𝕩 + + + + + Before + + 𝔽⊸𝔾 𝕩 + + + + + + + 𝔾 + 𝔽 + 𝕩 + + + 𝕨 𝔽⊸𝔾 𝕩 + + + + + + + + 𝔾 + 𝔽 + 𝕨 + 𝕩 + + + + + After + + 𝔽⟜𝔾 𝕩 + + + + + + + 𝔽 + 𝔾 + 𝕩 + + + 𝕨 𝔽⟜𝔾 𝕩 + + + + + + + + 𝔽 + 𝔾 + 𝕨 + 𝕩 + + + + + Self/Swap + + 𝔽˜ 𝕩 + + + + + 𝔽 + 𝕩 + + + 𝕨 𝔽˜ 𝕩 + + + + + + 𝔽 + 𝕨 + 𝕩 + + + + -- cgit v1.2.3