Saying Goodbye to one line of APL

When was the last time one line of code made you realize how far you’ve come?

For context, I’ve been writing a voxel game in Dyalog APL for nearly 7 months now. I started learning APL 9 months ago to be able to do this. Anything that is able to be done in APL I attempt to do purely in APL in a style befitting for APL. This includes Perlin noise terrain generation, converting internal representations of blocks into geometry to be rendered, frustum culling, collision and a lot more. It is currently able to reach >60 FPS on my MacBook with a render distance of 12, with most of the bottlenecks being silly choices from my part as I learn APL while doing this.

One line of code in this project that I greatly enjoy is the code that checks what faces of a chunk are exposed so that they can be selected and passed to the vertex buffer for the chunk. I like it so much that I even had a section dedicated to it in my talk at DYNA26

↑[0]{edges∨solid>⍵}¨0 1 2∘.{⍵⌽[⍺]solid}¯1 1

Very broad, what it does can be broken up like this.

• We have 2 3d boolean arrays solid and edges of size 16 128 16 that represent whether or not a solid block is found in each position. edges only checks if a solid block is found on the edges of the chunk.

• 0 1 2∘.{⍵⌽[⍺]solid}¯1 1 shifts the solid array in each of the 3 axes 0 1 2 back and forth ¯1 1. The outer product of it returns a 2d array where each row specifies an axes and the rotation.

• solid>⍵}¨ compares each shift with the original array. This being true indicates that the face is visible.

• {edges∨ makes it also set all edges to be visible. This is important since shifting wraps around the edges of the array that it shifts towards.

• ↑[0] puts it in a block-by-block order so that when it’s all enlisted we can easily select the faces we need.

Given a precomputed array representing all possible faces of a chunk, the data from this line of code is used to select what faces we need to render.

We can check the results quickly with a sized 3 3 3 chunk with a vertical line in the middle by looking at blocks that have any visible faces only:

⍝ Try it yourself! Paste into a Dyalog 20.0 REPL
    ⎕IO ← 0
    solid ← 1@(1 1 1⋄1 0 1⋄1 2 1⋄) ⊢ 3 3 3⍴0
    edges ← solid∧(∘.∨)⍨⍛(∘.∨) ⊢ 1 0 1
    1∘∊⍤2⍛⌿,[⍳3]↑[0]{edges∨solid>⍵}¨0 1 2∘.{⍵⌽[⍺]solid}¯1 1
1 1
1 1
1 1
   
1 1
0 0
1 1
   
1 1
1 1
1 1

The two blocks on the top and bottom have all faces since they’re on the edges and the center one has all except the top and bottom face (on the 2nd row).

I like this line of APL a lot. It’s been a core part of my voxel game for quite some time and I can rattle off some insights about it that also inadvertently explains why I like APL.

Sits on the shoulder of giants.

The broad idea of this line of code was directly leveraged from the famous Game of Life one liner.

{⊃1 ⍵ ∨.∧ 3 4 = +/ +⌿ ¯1 0 1 ∘.⊖ ¯1 0 1 ⌽¨ ⊂⍵}

In specific, the outer-product ⊖ combined with ⌽ to move the 2d space around for each cell and perform computations on them. This idea directly inspired my line of code.

That’s pretty cool! I don’t think it would’ve if I saw a Game of Life implementation across dozens of lines!

Amenable to conventional explanation.

Here’s a message I wrote in my first week or so of learning APL in wondering how I could leverage its notation to write a voxel game.

Right now my idea is: have a precomputed 3d matrix or array of cube vertex data for each direction. The blocks can be represented as a 3d matrix bit mask that can be rolled (and some sort of padding?) in each 6 directions and logical nor’d with it and its rolls to see which faces should be drawn per block. I think with an enlist and a where I then have indices I get vertex data from the precomputed chunk I use as the vertex buffer and pass to OpenGL?

Let me align the parts of the message that are relevant to this line of code.

• “The blocks can be represented as a 3d matrix bit mask” solid
• “that can be rolled … in each 6 directions” 0 1 2∘.{⍵⌽[⍺]solid}¯1 1
• “and logical nor’d compared with it and its rolls to see which faces should be drawn per block” solid>⍵}¨

I started actually working on the game months after I started learning APL, so it’s interesting that my implementation didn’t fall far from how I originally described it.

Fits in your head

I think I have this memorized by heart. I would probably be able to write it out under 30 seconds without looking at the code for a good few month (If you’ve done low-level graphics before, what code that does something equivalently do you think you can memorize like that :P).

cool who cares? – There’s a fact you hear across different disciplines constantly that we can only hold 7 things in our head at a time. Not sure if this is true or not, but it feels like I can only hold half of that most of the time. This makes it exceedingly easy to work with, especially when I’m not at a computer.

If I’m eating lunch or going for a walk I can juggle with the notation in my head to see what I can do to make it more performant directly in APL. I usually am able to apply what I had in mind once I sit down and work on without hiccups.

Weirdly unintuitive from the programming I’m used to

The core what it does seems ridiculously simple. So much so that when I initially considered this I didn’t think it would even be close to being performant. I mean, an interpreted language and all of these movements on large shapes at once!–doesn’t feel like it would be a good idea!!! I guess I was wrong? Doing this on a chunk sized 16 128 16 is pretty fast and I’m able to fly around the map at high speeds (TBA: me demoing this live in a presentation). This kind of boggled my mind and broke my intuitions of what I considered good patterns, at least in the domain of APL.¹

⍝ Try it yourself! Paste into a Dyalog 20.0 REPL
⍝ Benchmarks doing it on a randomly selected boolean array + its respective edges
	⎕IO←0 ⋄ 'cmpx'⎕CY'dfns'
	chunks←0.5<?0⍴⍨10,l←16 128 16
	box ← ⊃∘.∨/1@0¨l-⍛↑¨1
	edges ← box∘∨⍤¯1 ⊢ chunks
	cmpx '{solid←(i←?10)⌷chunks⋄edge←i⌷edges⋄↑[0]{edge∨solid>⍵}¨0 1 2∘.{⍵⌽[⍺]solid}¯1 1} ⍬'
6.1E¯5

Despite all of this praise towards one line of code, it is a bit inefficient and I am always looking to make things faster.

This line is pretty inefficient in terms of having too much useless geometry. All blocks on the edges have all faces visible instead of faces pointing towards adjacent chunks (or even testing against adjacent chunks). I originally thought that this wouldn’t be an issue since only +/∊⊃∘.∨/1@0¨(l←16 128 16)-⍛↑¨1 out of ×/l blocks would do this, but it turns out that’s enough to be a big difference!

I decided to ditch avoiding the checks on the edges and instead add padding to each direction I shift towards!

↑[0]{solid>⍵}¨0 1 2∘.{⍵↓[⍺](0<⍵)⌽[⍺]0,[⍺]solid}¯1 1

• 0,[⍺]solid Prepend 0s on the axis we’re targeting.
• (0<⍵)⌽[⍺] Shift on the axis so that 0s are at the end of the axis if we’re shifting in the positive direction.
• ⍵↓[⍺] Remove where the data ‘rolled over’ from the shift would be

Tad bit more to juggle in your head, so let me just show what the new code does with a 2d example:

⍝ Try it yourself! Paste into a Dyalog 20.0 REPL
	]box on
	⎕IO←0 
	A←[1 2 ⋄ 3 4]
	0 1 ∘.{(0<⍵)⌽[⍺]0,[⍺] A} ¯1 1
┌─────┬─────┐
│0 0  │1 2  │
│1 2  │3 4  │
│3 4  │0 0  │
├─────┼─────┤
│0 1 2│1 2 0│
│0 3 4│3 4 0│
└─────┴─────┘
	0 1 ∘.{⍵↓[⍺](0<⍵)⌽[⍺]0,[⍺] A} ¯1 1
┌───┬───┐
│0 0│3 4│
│1 2│0 0│
├───┼───┤
│0 1│2 0│
│0 3│4 0│
└───┴───┘

Now instead of edges having all faces selected, only faces that are towards the respective adjacent chunks for each side are selected (with the cost of being slightly less faster).

I noticed a dramatic speedup and reduction of video memory instantly when I changed to this line of code, one that surprised me. In APL’s side, the amount of vertices per chunk on average dropped by 5 times. In the GPU’s side, XCode Metal Debugger listed that a scene with a view distance of 12 that took 261 megabytes of video memory went down to 72 megabytes. Additionally, the amount of vertices went down from 31.4 million vertices to 6.2 million vertices and render time went down from 11.2 milliseconds to 2.14 milliseconds.

Suffice to say, I switched to this line of code and found it neat that only changing one line caused this improvement.

All in all, I can’t help but look back after having done this.

Looking at my commit history, it looks like I added it to my codebase at around December 29th 2025:

↑mask∘{¯1 1 ⌽[⍵] ¨⊂⍺}¨ 0 1 2
exposed ← ∊,/,{⍪∊edges∨mask∧mask⍲⍵}¨x

(If you compare this with the Game of Life code, you can see where the influence comes in more strongly).

Adám Brudzewsky offered suggestions on my APL code and it was later modified on January 6th 2026:

x ← 0 1 2∘.{⍵⌽[⍺]solid}¯1 1
exposed ← ∊↑[0]{edges∨solid>⍵}¨x

On January 31st, I decided to merge these two steps together:

exposed←↑[0]{edges∨solid>⍵}¨0 1 2∘.{⍵⌽[⍺]solid}¯1 1

This line lasted until now, with me even including it DYNA26, but now I will have to say goodbye to it. I would not be able to come up with the current solution when I wrote the original line, so that shows how well I have been learning APL.

I cannot help but feel a tinge of sentimentality towards it, seeing its history. The first few lines of a classical Japanese poem float in my mind:

Although its scent still lingers on

the form of a flower has scattered away

For whom will the glory

of this world remain unchanged?²

Can’t think of another language where one line of code made me write an entire post.