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