From 65eef4fade5eb426dae01d480f383b8a30b23071 Mon Sep 17 00:00:00 2001 From: Marshall Lochbaum Date: Wed, 11 Aug 2021 14:06:02 -0400 Subject: Change "BQN / main" in header to "(github) / BQN" --- docs/implementation/codfns.html | 2 +- docs/implementation/compile/dynamic.html | 2 +- docs/implementation/compile/index.html | 2 +- docs/implementation/index.html | 2 +- docs/implementation/kclaims.html | 2 +- docs/implementation/primitive/index.html | 2 +- docs/implementation/primitive/random.html | 2 +- docs/implementation/primitive/replicate.html | 2 +- docs/implementation/primitive/sort.html | 2 +- docs/implementation/vm.html | 2 +- 10 files changed, 10 insertions(+), 10 deletions(-) (limited to 'docs/implementation') diff --git a/docs/implementation/codfns.html b/docs/implementation/codfns.html index 48b1d1b9..57cfa3d5 100644 --- a/docs/implementation/codfns.html +++ b/docs/implementation/codfns.html @@ -3,7 +3,7 @@ Co-dfns versus BQN's implementation -
BQN / main / implementation
+
(github) / BQN / implementation

Co-dfns versus BQN's implementation

The BQN self-hosted compiler is directly inspired by the Co-dfns project, a compiler for a subset of Dyalog APL. I'm very grateful to Aaron for showing that array-oriented compilation is even possible! In addition to the obvious difference of target language, BQN differs from Co-dfns both in goals and methods.

The shared goals of BQN and Co-dfns are to implement a compiler for an array language with whole-array operations. This provides the theoretical benefit of a short critical path, which in practice means that both compilers can make good use of a GPU or a CPU's vector instructions simply by providing an appropriate runtime (however, only Co-dfns has such a runtime—an ArrayFire program on the GPU and Dyalog APL on the CPU). The two implementations also share a preference for working "close to the metal" by passing around arrays of numbers rather than creating abstract types to work with data. Objects are right out. These choices lead to a compact source code implementation, and may have some benefits in terms of how easy it is to write and understand the compiler.

diff --git a/docs/implementation/compile/dynamic.html b/docs/implementation/compile/dynamic.html index 1d232644..1edb73ef 100644 --- a/docs/implementation/compile/dynamic.html +++ b/docs/implementation/compile/dynamic.html @@ -3,7 +3,7 @@ BQN: Dynamic compilation -
BQN / main / implementation / compile
+
(github) / BQN / implementation / compile

Dynamic compilation

This page discusses at a high level (without covering any specific source transformations) how compilation and interpretation might be structured in order to execute BQN faster. Effective strategies will compile parts of the program with more specialization or higher optimization as it runs and more information about it becomes known.

To avoid confusion, an interpreter evaluates code to perform actions or produce a result; a CPU is a machine code interpreter. A compiler transforms code in one language or format to another. To run a program that does anything, it must eventually be interpreted; before this the program or parts of it might be compiled any number of times.

diff --git a/docs/implementation/compile/index.html b/docs/implementation/compile/index.html index 2ee01371..4ec585f0 100644 --- a/docs/implementation/compile/index.html +++ b/docs/implementation/compile/index.html @@ -3,7 +3,7 @@ BQN: Optimizing compilation notes -
BQN / main / implementation
+
(github) / BQN / implementation

Optimizing compilation notes

Pages here discuss advanced compilation strategies for BQN, that is, steps that might take take place after compiling to bytecode or a similar intermediate representation.

Most content here is currently speculative: C, Java, and Javascript backends are capable of compiling to native (x86, JVM, or Javascript) code in order to lower evaluation overhead but don't perform much if any analysis to improve this code. CBQN is likely to start making such optimizations in the future.

diff --git a/docs/implementation/index.html b/docs/implementation/index.html index 4cf1d1dc..d0b73c59 100644 --- a/docs/implementation/index.html +++ b/docs/implementation/index.html @@ -3,7 +3,7 @@ BQN implementation notes -
BQN / main
+
(github) / BQN

BQN implementation notes

Notes about how BQN is or could be implemented.

This repository's BQN implementation is written mainly in BQN: the bytecode compiler is completely self-hosted, and the majority of the runtime (r0, r1) is written in BQN except that it is allowed to define primitives; some preprocessing (pr) turns the primitives into identifiers.

diff --git a/docs/implementation/kclaims.html b/docs/implementation/kclaims.html index 667ff0fa..4d028e6c 100644 --- a/docs/implementation/kclaims.html +++ b/docs/implementation/kclaims.html @@ -3,7 +3,7 @@ BQN: Wild claims about K performance -
BQN / main / implementation
+
(github) / BQN / implementation

Wild claims about K performance

Sometimes I see unsourced, unclear, vaguely mystical claims about K being the fastest array language. It happens often enough that I'd like to write a long-form rebuttal to these, and a demand that the people who make these do more to justify them.

This isn't meant to put down the K language! K is in fact the only APL-family language other than BQN that I would recommend without reservations. And there's nothing wrong with the K community as a whole. Go to the k tree and meet them! What I want to fight is the myth of K, which is carried around as much by those who used K once upon a time, and no longer have any connection to it, as by active users.

diff --git a/docs/implementation/primitive/index.html b/docs/implementation/primitive/index.html index 25c831c3..b5256302 100644 --- a/docs/implementation/primitive/index.html +++ b/docs/implementation/primitive/index.html @@ -3,7 +3,7 @@ BQN: Primitive implementation notes -
BQN / main / implementation
+
(github) / BQN / implementation

Primitive implementation notes

Commentary on the best methods I know for implementing various primitives. Often there are many algorithms that are viable in different situations, and in these cases I try to discuss the tradeoffs.