BQN

n of whatever primitives you want, and a simple AST walker, and you've got a simple small APL interpreter. But those primitive implementations already take a good chunk of code, and adding variables/functions/nested functions/scoping/array formatting/etc adds more and more bits of independent code. Perhaps if you accept defining bits in the language in itself via a bootstrap step, BQN is a good candicate for existing small implementations - a BQN vm + minimal primitive set is ~500LoC of JS[0] (second half of the file is what you could call the native components of a stdlib), 2KLoC for first public commit of a C impl[1], both of those having the rest of the primitives being self-hosted[2], and the compiler (source text → bytecode) being self-hosted too[3]. (the C impl also used r0.bqn for even less required native primitives, but modern CBQN uses very little of even r1.bqn, having most important things native and heavily optimized) [0]: https://github.com/mlochbaum/BQN/blob/master/docs/bqn.js though earlier revisions might be more readable [1]: https://github.com/dzaima/CBQN/tree/bad822447f703a584fe7338d... [2]: https://github.com/mlochbaum/BQN/blob/master/src/r1.bqn (note that while this has syntax that looks like assigning to primitives, that's not actual BQN syntax and is transpiled away) [3]: https://github.com/mlochbaum/BQN/blob/master/src/c.bqn

operations like boolean logic, reordering arrays with selection, prefix sum, and so on, so they're not hard to read if you're used to them. There are a few tricks, which almost all are repeated patterns (e.g. PN, "partitioned-none" is common enough to be defined as a function). And fortunately, the line prefaced with "Permutation to reverse each expression: more complicated than it looks" has never needed to be debugged. Basically, when you commit to writing in an array style (you don't have to! It might be impossible!) you're taking an extreme stance in favor of visible and manipulable data. It's more work up front to design the layout of this data and figure out how to process it in the way you want, but easier to see what's happening as a result. People (who don't know APL, mostly) say "write only" but I haven't experienced it. [0] https://github.com/mlochbaum/BQN/blob/master/src/c.bqn [1] https://mlochbaum.github.io/BQN/implementation/codfns.html#i...

ions of infix & prefix ops to stack-based/RPN at the bottom of https://mlochbaum.github.io/BQN/implementation/index.html, though the code is in BQN. From that same author, parsers written in BQN, that I think should have sub-linear critical paths: Markdown: https://github.com/mlochbaum/BQN/blob/master/md.bqn XML: https://github.com/mlochbaum/bqn-libs/blob/master/xml.bqn and a compiler of BQN itself: https://github.com/mlochbaum/BQN/blob/master/src/c.bqn (outputs stack-based bytecode).

nal compiler architecture and it's easier to write and extend but feels about the same for reading and small tweaks. See also my review [3] of the denser compiler and Co-dfns. As for being read by others, short snippets are definitely fine. Taking some from the last week or so in the APL Farm, {⍵÷⍨+/|-/¯9 ¯11+.○?2⍵2⍴0} and {(⍸⍣¯1+\⎕IO,⍺)⊂[⎕IO]⍵} seemed to be easily understood. Forum links at [4]; the APL Orchard is viewable without signup and tends to have a lot of code discussion. There are APL codebases with many programmers, but they tend to be very verbose with long names. Something like the YAML parser here with no comments and single-letter names would be hard to get into. I can recognize, say, that c⌿¨⍨←(∨⍀∧∨⍀U⊖)∘(~⊢∊LF⍪WS⍨)¨c trims leading and trailing whitespace from each string in a few seconds, but in other places there are a lot of magic numbers so I get the "what" but not the "why". Eh, as I look over it things are starting to make sense, could probably get through this in an hour or so. But a lot of APLers don't have experience with the patterns used here. [0] https://github.com/Co-dfns/Co-dfns [1] https://github.com/mlochbaum/BQN/blob/master/src/c.bqn [2] https://github.com/mlochbaum/Singeli/blob/master/singeli.bqn [3] https://mlochbaum.github.io/BQN/implementation/codfns.html [4] https://aplwiki.com/wiki/Chat_rooms_and_forums

gcc -O3 -D NOTEST bench.c && ./a.out l > res/r_rh.txt gcc -O3 -D FLUXSORT -D NOTEST bench.c && ./a.out l > res/r_flux.txt gcc -O3 -D WOLFSORT -D NOTEST bench.c && ./a.out l > res/r_wolf.txt g++ -w -fpermissive -O3 -D SKACOPY -D NOTEST bench.c && ./a.out l > res/r_ska_.txt cd glide && cargo build --release && cd .. gcc -O3 -D GLIDESORT -D NOTEST bench.c -Lglide/target/release -lglide LD_LIBRARY_PATH=glide/target/release ./a.out l > res/r_glide.txt images/line.bqn res/r_{flux,wolf,ska_,glide,rh}.txt > images/rand_glide.svg

used it, but I don't think I really got it—just a weird way to organize data. And then in college I had to learn objects-only Java. Not good. But later I worked some with Node.js, and its module system was pretty nice: no name conflicts, easy to share code! Some way into BQN development, I figured out (with some help from a Common Lisp programmer) a way to add modules with an APL-y syntax, and something magic happened. I got objects[3] too! I think I've done about as much OOP in BQN as anywhere else, and I feel like I understand it a lot better now. So, this is my experience with Lisp-family features and APL. Fits like a glove, programming is easier and more fun. I mix and match array, functional, and object-oriented styles however I want. Did I lose coherence? When I translate my old J code it comes out shorter and cleaner and without exec (".) everywhere. But I still don't get why I should want the language I use to not support mutability rather than just default to immutability. Did I fail to understand something in J when I had the chance? [0] https://github.com/Co-dfns/Co-dfns [1] https://github.com/mlochbaum/BQN/blob/master/src/c.bqn [2] https://mlochbaum.github.io/BQN/implementation/codfns.html [3] https://mlochbaum.github.io/BQN/doc/oop.html