dayaml

My YAML loader[0] is a condensed example of the architecture and techniques I'm thinking of. It's a couple years old, so the code is dirty by my current standards, but the couple of times I've gone back to read it, I have found the YAML-specific concerns to be quite salient. That said, it's specifically written for an audience that is familiar with YAML detail in particular, parsing more generally, and of course APL expressions of ideas. In fact, that is a big part of what makes the code readable and maintainable: it is optimized for communicating to the expert worker not for on-boarding new developers. The latter is more appropriately handled via other means IMHO. The poster child for this style of APL is Co-dfns[0]. It's a production APL compiler and a much larger example of the code I'm talking about. The entrypoint to read is cmp/PS.a

My YAML loader[0] is where I first broke through the wall. It's still languishing in a relatively proof-of-concept state but does exhibit the basic design principles. There's also a Metamath verifier that does parallel proof verification on the GPU. It's unpublished right now because the whole thing is just a handful of handwritten code in my notebook at the moment. Hoping to get this out this month, actually. A DOOM port is bouncing around in my notes as well as a way to explore asynchronous APL. I'm also helping Aaron Hsu in his APL compiler[1] for stuff adjacent to my professional work, which I can't comment on much, unfortunately. Et hoc genus omne [0]:https://github.com/xelxebar/dayaml [1]:https://github.com/Co-dfns/Co-dfns

I totally feel you on the implementation side. The formalization used in the spec leaves a lot to be desired, and the spec devs seem to recognize this well. One of the aims of my dayaml[0] project is to explore a completely different formalization that rationalizes out the non-fundamental sharp edges. That said, there really aren't that many special cases. A lot of the them are UI features, arguably endemic to the problem space in one form or another. The deficiencies you see in the language, however, don't ring true with me. They are mostly implementation deficiencies: - Anchors are just pointers. YAML can efficiently represent generic object graphs, but if a loader copies those pointers into a billion laughs, that's an issue with the implementation decision. Usually, it comes down to assuming that YAML graphs are always trees, which wil

Hard disagree. I wrote a YAML parser in APL[0], set it aside for 8 months, and then one day decided to read through it while getting a haircut. I can happily report that the full 22 lines (with zero library deps) were very grokkable. In fact, I even found a bug and now have several ideas for a rearchitecture I'd like to work on. APL just looks unfamiliar. Don't confuse that with unreadability. IMHO, the ergonomics for expressing and communicating high-level specifications just blows other languages out of the water. And those specifications also happen to also be executable implementations with leading-edge performance to boot. Admittedly, though, the learning curve is painfully steep. I think it's worth it though. [0]:https://github.com/xelxebar/dayaml

I've been knee deep in APL for the past year, working on a YAML parser: https://github.com/xelxebar/dayaml. It's still very prototypy, but for ~30 lines of code it's surprisingly complete. The process of getting that project to where it is now really revolutionized how I think of software development in general and how I manage my dev teams at work. Our best practices and wisdom around software dev really are much more strongly tied to historical habits and tooling whims than we'd like to believe. I believe we as a community have a lot of unpicked fruits laying around if we shift focus onto the human side of Human-Computer Interfacing for a while. About K, though, Arthur Whitney sounds like such a beast, and I would love to mingle with the K community. Within the array programming circles, APL/J/BQN form one cluster and K looks like it's