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.

NOTE: See the new website for this project instead: https://apl.pmikkelsen.com