Feel like you want to sneer about something but you don’t quite have a snappy post in you? Go forth and be mid!
Any awful.systems sub may be subsneered in this subthread, techtakes or no.
If your sneer seems higher quality than you thought, feel free to cut’n’paste it into its own post, there’s no quota here and the bar really isn’t that high
The post Xitter web has spawned soo many “esoteric” right wing freaks, but there’s no appropriate sneer-space for them. I’m talking redscare-ish, reality challenged “culture critics” who write about everything but understand nothing. I’m talking about reply-guys who make the same 6 tweets about the same 3 subjects. They’re inescapable at this point, yet I don’t see them mocked (as much as they should be)
Like, there was one dude a while back who insisted that women couldn’t be surgeons because they didn’t believe in the moon or in stars? I think each and every one of these guys is uniquely fucked up and if I can’t escape them, I would love to sneer at them.
can you please talk more about your lambda calculus projects?
sure! there was a little bit about it in the first stubsack and I posted a bit more about it in this thread on masto (with some links to papers I’ve been reading too, if you’d like to dig into the details on anything)
overall what I’m working on is a hardware implementation of a Krivine machine, which uses Tromp’s prefix code bitstream representation of binary lambda calculus as its machine language and his monadic IO model to establish a runtime environment. it isn’t likely to be a very efficient machine by anyone’s standard, but I really like working with BLC as a pure (and powerful) form of computational math, and there’s something pleasant about the way it reduces down to a HDL representation (via the Amaranth HDL in this case). there’s a few subprojects I’ve been working on as part of this:
I’ve been working on some of this on paper as a sleep aid for a while, but I’m finally starting on what’s feeling like a solid HDL implementation. let me know if you want more details on any of it! some of the more far off stuff is really just a mental sketch, but writing it out will at least help me figure out what ideas still make sense when they’re explained to someone else
for anyone who’s fucking lost reading the above (I can’t blame ya), lambda calculus is the mathematical basis behind functional programming. this is a fun introduction. the only things you can do in lambda calculus are define functions, name variables, and apply functions to other functions or variables (which substitutes the variables for whatever they’re being applied to and eliminates the function). that’s all you need to represent every possible computer program, which is amazing
a Krivine machine is a machine for doing what the alligators in that intro are doing, automatically — that is, reducing down lambda functions until they can’t be reduced anymore and produce a final value. that process is computation, so a Krivine machine is a (rather strange) computer
I have a scattered interest in lambda calculus too so I’d love to follow this project. Tromp’s BLC definitely hits a sweet spot of complexity/size when it comes to describing computation in a way that’s deeply satisfying.
Have you looked into interaction nets/other optimal beta-reduction schemes (there’s a project out there called HVM)? Probably way too high level for now though. I am fascinated by the possibility of these algorithms making church-representations more asymptotically efficient (or even balanced ternary)
exactly! it’s such a cool way to write a program, and it’s so much more satisfying than writing assembly for a von Neumann (or any load/store) machine. have you checked out LambdaLisp? it’s one of my inspirations for this project — it’s amazing that you can build a working Lisp interpreter out of BLC, and understanding how that was done taught me so much about Lisp’s relationship with lambda calculus.
I plan to release my HDL as a collaborative project once I’ve got enough done to share out. currently I’ve got the HDL finished for the combinational circuit that makes bitstream BLC processing efficient with word-oriented memory hardware, and I’m doing debugging on the buffer that grabs words from memory and offsets them if they represent a term that isn’t word-aligned (which is a pretty simple circuit so I’m surprised I’ve managed to implement so many bugs). there’s quite a bit left to go! IO is still a sticking point — I know how I want to do it, but I can’t quite imagine how memory and runtime state will look after the machine reads or writes a bit.
that seems awesome! I really like that it can do auto-parallelization, and I want to check out how it optimizes lambda terms. for now my machine model is a pretty straightforward Krivine machine with some inspiration taken from the Next 700 Krivine Machines paper, which seems likely to yield a machine that can be implemented as circuitry. that paper decomposes Krivine-like machine models down into combinators, which can be seen as opcodes, microinstructions, or (in my case) operations that that need to be performed on memory during a particular machine state.
once I’ve got the basic machine defined, I’d like to come back to something like HVM as a higher performance lambda calculus machine and see what can be adopted. one of their memory invariants in particular (the guarantee that each closure is only used once) maps really well to my mental model of what I imagine a hardware parallel lambda calculus machine would be like
I found LambdaLisp from your mastodon post and was immediately intrigued. I’m going to try and run it to get a better understanding of how the IO system works, and maybe even cook up my own BLC interpreter to run it! The hardware stuff is definitely out of my depth, but this may be a great chance to learn.
that’s a great idea! the only BLC VMs I know of are written in a very obscure style (Tromp’s especially — his first interpreter was an entry into the International Obfuscated C Code Contest and he only posted the (relatively) unobfuscated one later) and I think there’s plenty of room for something written to be more comprehensible. I’m also not aware of any VM that implements
call-ccfrom Krivine’s original paper, which has interesting applications. and of course, all the Krivine machines I know are relatively slow and very memory-inefficient — but there’s low hanging fruit here that can make things better.one thing I might take on is implementing a visual krivine machine — something with a GUI that shows its current state and a graph of all the closures in memory. that would be a big boon for my current work, and I might see if I could graft something like that onto the simulation testbench for my HDL implementation.