aboutsummaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorMarshall Lochbaum <mwlochbaum@gmail.com>2020-07-18 23:00:43 -0400
committerMarshall Lochbaum <mwlochbaum@gmail.com>2020-07-18 23:00:43 -0400
commit7b36cd6a7a6d576c19c60e7842a0d0d0c460702a (patch)
tree8c66983cc29babe5f24df783dab1db879b802ebc
parent2366e5a6275d39c1bd9cab2ada26bea00394820d (diff)
Add links to html versions at the top of markdown files
-rw-r--r--doc/README.md2
-rw-r--r--doc/context.md2
-rw-r--r--doc/depth.md2
-rw-r--r--doc/fromDyalog.md2
-rw-r--r--doc/functional.md2
-rw-r--r--doc/group.md2
-rw-r--r--doc/indices.md2
-rw-r--r--doc/join.md2
-rw-r--r--doc/logic.md2
-rw-r--r--doc/transpose.md2
-rw-r--r--doc/windows.md2
-rw-r--r--md.bqn4
-rw-r--r--problems.md2
-rw-r--r--running.md2
-rw-r--r--spec/README.md2
-rw-r--r--spec/evaluate.md2
-rw-r--r--spec/grammar.md2
-rw-r--r--spec/literal.md2
-rw-r--r--spec/token.md2
-rw-r--r--spec/types.md2
20 files changed, 42 insertions, 0 deletions
diff --git a/doc/README.md b/doc/README.md
index 8636b23c..142b3f9c 100644
--- a/doc/README.md
+++ b/doc/README.md
@@ -1,3 +1,5 @@
+*View this file with results and syntax highlighting [here](https://mlochbaum.github.io/BQN/doc/index.html).*
+
# BQN documentation
Here is the documentation for BQN, describing what features BQN has, how to use them (with examples), and why they were chosen. As it is considerably more in-depth than the [specification](../spec/README.md), the documentation is much less complete. The following pages are present now:
diff --git a/doc/context.md b/doc/context.md
index e3328fc8..fe800cfa 100644
--- a/doc/context.md
+++ b/doc/context.md
@@ -1,3 +1,5 @@
+*View this file with results and syntax highlighting [here](https://mlochbaum.github.io/BQN/doc/context.html).*
+
# BQN's context-free grammar
APL has a problem. To illustrate, let's look at an APL expression:
diff --git a/doc/depth.md b/doc/depth.md
index a901982c..855ca6ab 100644
--- a/doc/depth.md
+++ b/doc/depth.md
@@ -1,3 +1,5 @@
+*View this file with results and syntax highlighting [here](https://mlochbaum.github.io/BQN/doc/depth.html).*
+
# Depth
The depth of an array is the greatest level of array nesting it attains, or, put another way, the greatest number of times you can pick an element starting from the original array before reaching a non-array. The monadic function Depth (`≡`) returns the depth of its argument, while the 2-modifier Depth (`⚇`) can control the way its left operand is applied based on the depth of its arguments. Several primitive functions also use the depth of the left argument to decide whether it applies to a single axis of the right argument or to several axes.
diff --git a/doc/fromDyalog.md b/doc/fromDyalog.md
index 9af9555c..3eaf752d 100644
--- a/doc/fromDyalog.md
+++ b/doc/fromDyalog.md
@@ -1,3 +1,5 @@
+*View this file with results and syntax highlighting [here](https://mlochbaum.github.io/BQN/doc/fromDyalog.html).*
+
# BQN–Dyalog APL dictionary
A few tables to help users of Dyalog APL (or similar) get started quickly on BQN. Here we assume `⎕ML` is 1 for Dyalog.
diff --git a/doc/functional.md b/doc/functional.md
index 45614904..c3dae74c 100644
--- a/doc/functional.md
+++ b/doc/functional.md
@@ -1,3 +1,5 @@
+*View this file with results and syntax highlighting [here](https://mlochbaum.github.io/BQN/doc/functional.html).*
+
# Functional programming
BQN boasts of its functional capabilities, including first-class functions. What sort of functional support does it have, and how can a BQN programmer exercise these and out themself as a Schemer at heart?
diff --git a/doc/group.md b/doc/group.md
index 197e8977..2790a851 100644
--- a/doc/group.md
+++ b/doc/group.md
@@ -1,3 +1,5 @@
+*View this file with results and syntax highlighting [here](https://mlochbaum.github.io/BQN/doc/group.html).*
+
# Group
BQN replaces the [Key](https://aplwiki.com/wiki/Key) operator from J or Dyalog APL, and [many forms of partitioning](https://aplwiki.com/wiki/Partition_representations), with a single (ambivalent) Group function `⊔`. This function is somewhat related to the K function `=` of the same name, but results in an array rather than a dictionary.
diff --git a/doc/indices.md b/doc/indices.md
index 0634087d..cc7c5f67 100644
--- a/doc/indices.md
+++ b/doc/indices.md
@@ -1,3 +1,5 @@
+*View this file with results and syntax highlighting [here](https://mlochbaum.github.io/BQN/doc/indices.html).*
+
# Indices
One-dimensional arrays such as K lists or Python arrays have only one kind of index, a single number that refers to an element. For multidimensional arrays using the leading axis theory, there are several types of indexing that can be useful. Historically, nested APL designs have equivocated between these, which I believe can lead to subtle errors when programming. BQN focuses on single-number (depth 0) indices, which can refer to list elements or array major cells (or more generally indexing along any particular axis). When using this kind of element index, indexed arrays are required to be lists. Only two functions allow the use of list element indices: Range (`↕`), which can accept a list argument, and Pick (`⊑`), which uses the depth-1 arrays in its left argument as index scalars or lists. Others use single-number indices to refer to cells.
diff --git a/doc/join.md b/doc/join.md
index 31ec3876..c7603628 100644
--- a/doc/join.md
+++ b/doc/join.md
@@ -1,3 +1,5 @@
+*View this file with results and syntax highlighting [here](https://mlochbaum.github.io/BQN/doc/join.html).*
+
# Join
Join (`∾`) is an extension of the monadic function [Raze](https://aplwiki.com/wiki/Raze) from A+ and J to arbitrary argument ranks. It has the same relationship to Join to, the dyadic function sharing the same glyph, as Merge (`>`) does to Couple (`≍`): `a≍b` is `>a‿b` and `a∾b` is `∾a‿b`. While Merge and Couple combine arrays (the elements of Merge's argument, or the arguments themselves for Couple) along a new leading axis, Join and Join to combine them along the existing leading axis. Both Merge and Join can also be called on a higher-rank array, causing Merge to add multiple leading axes while Join combines elements along multiple existing axes.
diff --git a/doc/logic.md b/doc/logic.md
index 638bdace..13a9c3b2 100644
--- a/doc/logic.md
+++ b/doc/logic.md
@@ -1,3 +1,5 @@
+*View this file with results and syntax highlighting [here](https://mlochbaum.github.io/BQN/doc/logic.html).*
+
# Logic functions: And, Or, Not (also Span)
BQN retains the APL symbols `∧` and `∨` for logical *and* and *or*, and changed APL's `~` to `¬` for *not*, since `~` looks too much like `˜` and `¬` is more common in mathematics today. Like J, BQN extends Not to the linear function `1⊸-`. However, it discards [GCD](https://aplwiki.com/wiki/GCD) and [LCM](https://aplwiki.com/wiki/LCM) as extensions of And and Or, and instead uses bilinear extensions: And is identical to Times (`×`), while Or is `×⌾¬`, following De Morgan's laws (other ways of obtaining a function for Or give an equivalent result—there is only one bilinear extension).
diff --git a/doc/transpose.md b/doc/transpose.md
index 73653e0e..a00ff28c 100644
--- a/doc/transpose.md
+++ b/doc/transpose.md
@@ -1,3 +1,5 @@
+*View this file with results and syntax highlighting [here](https://mlochbaum.github.io/BQN/doc/transpose.html).*
+
# 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.
diff --git a/doc/windows.md b/doc/windows.md
index 82397a42..e82b9e6b 100644
--- a/doc/windows.md
+++ b/doc/windows.md
@@ -1,3 +1,5 @@
+*View this file with results and syntax highlighting [here](https://mlochbaum.github.io/BQN/doc/windows.html).*
+
# Windows
In BQN, it's strongly preferred to use functions, and not modifiers, for array manipulation. Functions are simpler as they have fewer moving parts. They are more concrete, since the array results can always be viewed right away. They are easier to implement with reasonable performance as well, since there is no need to recognize many possible function operands as special cases.
diff --git a/md.bqn b/md.bqn
index 85684053..ee79c49f 100644
--- a/md.bqn
+++ b/md.bqn
@@ -292,6 +292,10 @@ Markdown ← {𝕊𝕩:1𝕊𝕩; extensions𝕊𝕩:
######
# Create the block structure using line classifications.
+
+ # First remove the html link line: the output *is* the html file.
+ 𝕩 ↩ 2⊸↓⍟("*View this file" (⊣ ≡ ⌊○≠↑⊢) ⊑) 𝕩
+
lengths ← ≠¨ 𝕩 # Length of each line
blanks ← (Lead ' '⊸=)¨ 𝕩 # Number of leading blanks
nonEmptyMask ← blanks < lengths # Empty ←→ all leading blanks
diff --git a/problems.md b/problems.md
index a6fe9d09..d9a68c88 100644
--- a/problems.md
+++ b/problems.md
@@ -1,3 +1,5 @@
+*View this file with results and syntax highlighting [here](https://mlochbaum.github.io/BQN/problems.html).*
+
# Problems with BQN
Every language has some issues that everyone can agree make programming harder. Sometimes there is a simple solution that has not yet been discovered; sometimes the problem is inherent to the language because it's caused by fundamental choices (or anywhere in between). Below are problems I have identified in BQN, ordered from what I consider the most severe to the least. This is independent of whether the issue can be solved—if it somehow went away, how much better would the language be?
diff --git a/running.md b/running.md
index 987d149d..5ea21f0b 100644
--- a/running.md
+++ b/running.md
@@ -1,3 +1,5 @@
+*View this file with results and syntax highlighting [here](https://mlochbaum.github.io/BQN/running.html).*
+
# How to run BQN
BQN is in a very early stage of development, and there is currently no complete implementation of the language. However, it's a relatively simple language to implement, and a few implementations come close.
diff --git a/spec/README.md b/spec/README.md
index e1039865..c372df91 100644
--- a/spec/README.md
+++ b/spec/README.md
@@ -1,3 +1,5 @@
+*View this file with results and syntax highlighting [here](https://mlochbaum.github.io/BQN/spec/index.html).*
+
# BQN specification
This directory gives a (currently incomplete) specification for BQN. The specification differs from the [documentation](../doc/README.md) in that its purpose is only to describe the exact details of BQN's operation in the most quickly accessible way, rather than to explain the core ideas of BQN functionality and how it might be used. Since it is easier to specify than to document, the specification is currently more complete than the documentation; for example, it includes nearly all primitives.
diff --git a/spec/evaluate.md b/spec/evaluate.md
index a555740f..556a4efb 100644
--- a/spec/evaluate.md
+++ b/spec/evaluate.md
@@ -1,3 +1,5 @@
+*View this file with results and syntax highlighting [here](https://mlochbaum.github.io/BQN/spec/evaluate.html).*
+
This page describes the semantics of the code constructs whose grammar is given in [grammar.md](grammar.md). The formation rules there are not named, and here they are identified by either the name of the term or by copying the rule entirely if there are several alternative productions.
Here we assume that the referent of each identifier, or equivalently the connections between identifiers, have been identified according to the [scoping rules](scope.md).
diff --git a/spec/grammar.md b/spec/grammar.md
index 58544ce8..5b411000 100644
--- a/spec/grammar.md
+++ b/spec/grammar.md
@@ -1,3 +1,5 @@
+*View this file with results and syntax highlighting [here](https://mlochbaum.github.io/BQN/spec/grammar.html).*
+
BQN's grammar is given below. Terms are defined in a [BNF](https://en.wikipedia.org/wiki/Backus%E2%80%93Naur_form) variant. However, handling special names properly is possible but difficult in BNF, so they are explained in text along with the braced block grammar.
The symbols `s`, `F`, `_m`, and `_c_` are identifier tokens with subject, function, 1-modifier, and 2-modifier classes respectively. Similarly, `sl`, `Fl`, `_ml`, and `_cl_` refer to literals and primitives of those classes. While names in the BNF here follow the identifier naming scheme, this is informative only: syntactic classes are no longer used after parsing and cannot be inspected in a running program.
diff --git a/spec/literal.md b/spec/literal.md
index 937363e0..9d60f067 100644
--- a/spec/literal.md
+++ b/spec/literal.md
@@ -1,3 +1,5 @@
+*View this file with results and syntax highlighting [here](https://mlochbaum.github.io/BQN/spec/literal.html).*
+
A *literal* is a single [token](token.md) that indicates a fixed character, number, or array. While literals indicate values of a data type, [primitives](primitive.md) indicate values of an operation type: function, 1-modifier, or 2-modifier.
Two types of literal deal with text. As the source code is considered to be a sequence of unicode code points ("characters"), and these code points are also used for BQN's character [data type](types.md), the representation of a text literal is very similar to its value. In a text literal, the newline character is always represented using the ASCII line feed character, code point 10. A *character literal* is enclosed with single quotes `'` and its value is identical to the single character between them. A *string literal* is enclosed in double quotes `"`, and any double quotes between them must come in pairs, as a lone double quote marks the end of the literal. The value of a string literal is a rank-1 array whose elements are the characters in between the enclosing quotes, after replacing each pair of double quotes with only one such quote.
diff --git a/spec/token.md b/spec/token.md
index 3c2235eb..52e46d25 100644
--- a/spec/token.md
+++ b/spec/token.md
@@ -1,3 +1,5 @@
+*View this file with results and syntax highlighting [here](https://mlochbaum.github.io/BQN/spec/token.html).*
+
This page describes BQN's token formation rules (token formation is also called scanning). Most tokens in BQN are a single character long, but quoted characters and strings, identifiers, and numbers can consist of multiple characters, and comments, spaces, and tabs are discarded during token formation.
BQN source code should be considered as a series of unicode code points, which we refer to as "characters". The separator between lines in a file is considered to be a single character, newline, even though some operating systems such as Windows typically represent it with a two-character CRLF sequence. Implementers should note that not all languages treat unicode code points as atomic, as exposing the UTF-8 or UTF-16 representation instead is common. For a language such as JavaScript that uses UTF-16, the double-struck characters `𝕨𝕎𝕩𝕏𝕗𝔽𝕘𝔾` are represented as two 16-bit surrogate characters, but BQN treats them as a single unit.
diff --git a/spec/types.md b/spec/types.md
index 0d142630..d0658feb 100644
--- a/spec/types.md
+++ b/spec/types.md
@@ -1,3 +1,5 @@
+*View this file with results and syntax highlighting [here](https://mlochbaum.github.io/BQN/spec/types.html).*
+
BQN programs manipulate data of six types:
- Character
- Number