Co-dfns

can see, the famous prime generator is not even the Eratostenes' sieve, but a simple N^2 divisor counting computation. Well, that's because you wrote a divisor function, not a seive. Arguably, the ease of typing an outer product (i.e ∘.|⍨⍳N) can tempt us into writing quadratic algorithms unnecessarily, but this is just an experience issue, IMO. If we want a seive, we can just write one directly: p⊣{ω~n×1+⍳⌊N÷p⍪←n←ω↑⍨1⌊≢ω}⍣≡1↓1+⍳N⊣p←⍬ The algorithm is O(N log log N) as expected of a naive Eratosthenes implementation. You'll need ⎕IO←0 if you want to try it out. There's also a faster seive by Roger Hui [0] in the dfns workspace as well as a family of prime number functions [1] for things more than just prime generation. [0]:https://dfns.dyalog.com/n_sieve.htm [1]:https://dfns.dyalog.com/n_pco.htm

pl. If you're interested, I'm willing to have a chat and talk more about what makes this kind of APL imminently workable, in which case there are also some personal private examples I could share as well. Feel free to reach out to the contact info on my profile here. [0]:https://github.com/xelxebar/dayaml/blob/master/Y.apln. [1]:https://github.com/Co-dfns/Co-dfns

Data-parallel style (e.g. Co-dfns[3]) Heck, APL even has lexical and dynamic scope coexisting together. IMHO, it's truly underrated as a language innovator. [0]:https://dfns.dyalog.com/c_match.htm [1]:https://github.com/Dyalog/OpenAI/blob/main/source/OpenAI.apl... [2]:https://github.com/Dyalog/HttpCommand/blob/master/source/Htt... [3]:https://github.com/Co-dfns/Co-dfns/blob/master/cmp/PS.apl

ations on the theme, tailored to the specific needs of the immediate sub-problem. As library functions, such needs tend to accrete functions and function parameters into our library methods over time, making them harder to understand and visually noisier in the code. To my eyes, the crux is that our formal language is _discovered_ not handed down from God. As I'm sure you're excruciatingly aware, that discovery process means we benefit from the flexibility to quickly iterate on the _entire architecture_ of our code, otherwise we end up with baked-in obsolete assumptions and the corresponding piles of workarounds. In my experience, the Iversonian languages provide architectural expressability and iterability _par excellence_. [0]:https://github.com/Co-dfns/Co-dfns/tree/master

yearly conferences are some of my favorites to attend. Disclaimer: I am kind of in love with APL as a greenfield development language. Feel free to email me personally if you have any questions. Address is in my HN profile. [0]:https://dyalog.com/ [1]:https://github.com/Co-dfns/Co-dfns

allocated must be space for the pointers to these arrays and other metadata, not the data of the array itself. As the data is variable-size, it can't be fully planned out at compile time, and I'm fairly sure the register allocation is done when there's not enough shape or type information to even make an attempt at data allocation. This change can only improve constant overhead for primitive calls, and won't be relevant to computations where most of the work is on large arrays. I think it's helpful for Co-dfns in a practical sense, but not too exciting as it only helps with bad cases: if this is important for a user then they'd probably end up with better performance by switching to a statically-typed language when it comes time to optimize. It does mention that "For most small array values, we will use static allocation types, which prevents the need for allocating additional space for an array above and beyond its header.", so small arrays are taken care of by register allocation. Tradeoff there between being able to fit larger arrays in this space versus wasting space for values that don't use the full header. Constant lifting within the compiler is pretty cool, I'll have to look into that.

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).

semantic density of the APL code I'm using to solve the problem is at a certain rate. I maintain a consistent density rate by choosing my variable names in such a way that they visually align with the expressivity per character of the built in primitive symbols. And > [...] idiomatic programming methods that are so concise, they can begin to be read as we read and chunk English phrases. By doing so, it becomes actually easier to just write out most algorithms, because the normal name for such an algorithm is basically as long as the algorithm itself written out. This means that I start to learn to chunk idioms as phrases and can read code directly, without the cost of name lookup indirection. I can get away with this because I've made reusability and abstraction less important (vastly so) because I can literally see every use case of every idiom on the screen at the same time. It literally would take more time to write the reusable abstraction than it would to just replace the idiomatic code in every place. [0] https://github.com/Co-dfns/Co-dfns [1] https://news.ycombinator.com/item?id=13571159

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