summaryrefslogtreecommitdiff
path: root/sites/pmikkelsen.com/APL-and-J
diff options
context:
space:
mode:
authorPeter Mikkelsen <petermikkelsen10@gmail.com>2022-02-02 21:54:28 +0000
committerPeter Mikkelsen <petermikkelsen10@gmail.com>2022-02-02 21:54:28 +0000
commit34270afac08c5ab0a2fd1dd9a388d34d51979d01 (patch)
treee3a4b3a48cebf0b8b20e3c8fb3a45808ff76822c /sites/pmikkelsen.com/APL-and-J
parent417548361eb0c7a4c449245d19436e24d1b7f80a (diff)
Add APL site
Diffstat (limited to 'sites/pmikkelsen.com/APL-and-J')
-rw-r--r--sites/pmikkelsen.com/APL-and-J/Designing_an_APL_for_9front.md83
1 files changed, 83 insertions, 0 deletions
diff --git a/sites/pmikkelsen.com/APL-and-J/Designing_an_APL_for_9front.md b/sites/pmikkelsen.com/APL-and-J/Designing_an_APL_for_9front.md
new file mode 100644
index 0000000..21604e9
--- /dev/null
+++ b/sites/pmikkelsen.com/APL-and-J/Designing_an_APL_for_9front.md
@@ -0,0 +1,83 @@
+# Designing an APL for 9front
+
+*The problem:* there is no APL for 9front.
+
+I know, for most people this is no problem at all. But for me it is.
+This document intends to describe what I want/need from such a system, but
+until implementation begins, this is all just ideas. The implementation
+will most likely begin in february 2022 after my exams.
+
+## Implementation requirements/goals
+
+1. Must be implemented in C (don't want to deal with other language issues. One is enough)
+2. Must use utf-8 (easy, it is plan 9 after all)
+3. Must store code and data as plain text files, no workspaces.
+4. Must focus on simplicity in implementation, rather than speed. It is a one man project,
+ and I would rather have slow features than missing features.
+5. The primitive functions and operators should be as close to dyalog APL as possible,
+ since that is what I normally use.
+6. Must support arbitrary precision integers.
+7. No double letter stuff like `⍺⍺` `⍵⍵` and `∇∇` and `∘.`
+
+The above are the top priority goals, and below in the next few sections are some plans for _how_ the goals should be met.
+
+## Goal 1 and 2
+
+Plan 9 C makes is quite easy to work with unicode data, as it has the `Rune` type which represents a unicode character.
+The downsides of using C are well known, such as the need for manually managing memory. However, C is the only fully supported
+programming language on plan 9 (not considering the shell and awk and stuff like that). While go is ported and works, I don't
+want to rely on it.
+
+## Goal 3
+
+Plan 9 gets most of its power from the file system abstractions, and it would simply be stupid to
+ignore this and save code in a binary workspace format. I also believe it makes is easier for other programmers,
+since this is the norm in pretty much every language in use. It also means there has to be some way to import the
+code from other files, perhaps with a `⎕IMPORT`, or a feature to link a folder to the session like dyalog does with
+`]LINK.create`.
+
+Anyways, I want to be able to type `)ed someFunction` in the REPL an have it create/open the definition of a function/operator
+in the editor, via the plumber of course.
+
+## Goal 4
+
+This is important if the implementation is to ever be useful.
+The simplicity comes in two ways: avoiding implementing unwanted features, and doing the simple thing instead of the fastest.
+
+The first of those two is pretty simple to acheive: just don't implement the features that I don't want. This would mean that,
+at least in the beginning, stuff like tradfns and control structures will not be implemented, as I see dfns as superior. New features
+can always be added later.
+
+The second is more important. I know the commercial APL implementations are known for their speed due to fancy use of vector instructions
+and special casing a lot of things, but this takes time and effort and is, in my opinition, not worth it at all in the early stages
+of the project. It would be nice if the system could allow defining some primitives directly in terms of others, with the definitions written in APL itself. For example, in the C code for `⊢` (a very simple example), I would like to just write:
+
+ Array builtin_right_tack(Array alpha, Array omega, ...)
+ {
+ return PRIM_FUNC("{⍵}", alpha, omega);
+ }
+
+or something.
+
+## Goal 5
+
+Familiar primitives are easier to implement. Features from J may be added, as they have some good stuff as well.
+
+## Goal 6
+
+No more overflows. Plan 9 has `<mp.h>` which I might use in the beginning.
+
+## Goal 7
+
+I will use the following symbols instead of those in Dyalog apl:
+
+* `⍶` instead of `⍺⍺`
+* `⍹` instead of `⍵⍵`
+* `∆` instead of `∇∇` for monadic operator self reference
+* `⍙` instead of `∇∇` for dyadic operator self reference
+* `⌾` instead of `∘.`
+
+# Current progress
+See [https://git.sr.ht/~pmikkelsen/APL9](the git repository).
+
+*NOTE:* See the new website for this project instead: [https://apl.pmikkelsen.com](https://apl.pmikkelsen.com)