this post was submitted on 18 Mar 2024
1 points (100.0% liked)
TechTakes
1432 readers
16 users here now
Big brain tech dude got yet another clueless take over at HackerNews etc? Here's the place to vent. Orange site, VC foolishness, all welcome.
This is not debate club. Unless it’s amusing debate.
For actually-good tech, you want our NotAwfulTech community
founded 1 year ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
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-cc
from 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.