Brendan Hansknecht (Apr 01 2025 at 04:02): Brendan Hansknecht (Apr 01 2025 at 04:02):After much deliberation with various parties, it has been decided that we made a mistake when moving to zig and need to rewrite the rewrite.
Fundamentally, zig just isn't as new and shiny as it used to be. I mean, it still uses a C style syntax and doesn't compile to the GPU. Writing a compiler for CPUs only leaves so much performance on the table, it isn't even worth doing.
As such, I am happy to announce that we will be rewriting the roc compiler in the co-dfns subset of APL. APL is a language optimized for data driven design and with co-dfns, it gets pulled all the way out of the 1960s and onto GPUs. This is a language with maximal mechanical sympathy and no boilerplate.
Instead of wasting, tens of lines of codes on an expensive loop to chomp some comments and basic whitespace, we can now chomp all comments and whitespace across an entire file with a trivial amount of math:
⍝ Remove comments
pos msk⌿¨⍨←⊂∧⍀¨msk∨'⍝'≠IN∘I¨pos
⍝ Remove insignificant whitespace
t pos end⌿⍨←⊂(t=0)⍲(⊢∧1⌽⊢)IN[pos]∊WS
t pos end⌿⍨←⊂(t≠0)∨(~IN[pos]∊WS)∨⊃¯1 1∧.⌽⊂IN[pos]∊alp,num,'¯⍺⍵⎕.:'
Welcome to the future! And happy April fools day!
Side note, I actually do love array programming languages and am debating writing a roc tokenizer in one just for the learning experience. I actually already made a tokenizer for monkey lang in an array language before: https://github.com/bhansconnect/monkey-bqn/blob/main/compiler.bqn
Please add any other outlandish and fun ideas below
Ray Myers (Apr 07 2025 at 23:18):Really appreciate this joke because I'm interested in nanopass compilers and co-dfns built on that paradigm - taking it to a terse APL extreme
Brendan Hansknecht (Apr 08 2025 at 00:24):I'm not sure what I think about nanopass in general (my gut feeling is that it is the wrong tradeoff for many compilers), but I have huge respect for Aaron Hsu and co-dfns.
Last updated: Jul 06 2025 at 12:14 UTC