To "pre-teach" my son CS, I created a (highly) simplified code-to-bytecode-to-machine stack for a language called "irony", and (extremely simple) OS, called "pathos". (Hacker ethos: Hundreds of lines of code just to cache out a bad pun! :-)
The files "compiler.py" and "virtual_hardware.py" are the primary irony modules. Irony supports recursion, including mutual recursion, but nothing fancy. There's no lexer, so you need to put spaces between tokens. (Being a native Lisper, I hate lexers!)
compiler.py takes Irony source to byte code, and has a byte-code interpreter. virtual_hardware.py take the same byte code, but emulates actual hardware.
These are designed to go with an exercise where the student add FOR LOOP capability. Given the well-designed base, this is extremely simple, but requires understanding each step of the stack. ("compiler_for" and "virtual_hardware_for" are the solutions; The idea, of course, is not to give these to the student!)
(You'd think that it ought be the other way round: Start with for loops and then ask the student to add recursion, but it's much harder to add recursion than loops, so I put recursion into the base, and then ask the student to add for loops.)
The files "pathos.py" (which imports "irony.py") is a simple OS whose goal is to create, edit, compile, and run programs written in Irony. ("irony.py" is a combined version of compiler.py and virtual_hardware.py, but leaves out the byte code interpreter.) The "comp" and "exec" commands in pathos compile (to byte code) and then execute the reuslting byte code (basically assembly) on the emulated hardware. (See "pathos_demo.log".)
Everything here was written in about 5 total hours using a combination of chatbots. This wasn't as easy as I'd hoped. As many folks who use LLMs to assist in coding discover, they are bad at keeping track of even marginally complex or large projects, and don't deal well with conceptually twisty programming concepts. They were basically incapable of implementing recursion correctly, or generalizing to the desired level, and they kept losing their place in the series of steps. Eventually they would just seemingly lose track entirely and be unable to fix what turned out to be trivial errors, at which point I had to clear the decks entirely, reload the latest versions of the code base we were working on, and then re-explain the project and what to do next. In the end I had to give them nearly step-by-step guidance to get it right, and the way I wanted it to be, to be understandable and teachable. That said, to their credit, once I had the compiler and hardware emulator the understandable and teachable way I wanted it, I could feed those to the LLM and it was able to understand the code and make reasonable changes. For example, the entire FOR LOOP extension was done completely by Claude. I get that "pros" don't do it this way, but it's slightly fun trying to talk a chatbot into doing one's bidding, and being emacs-based, I don't have a magical code assistant built into my code editor. (I haven't even looked -- has someone already done that?)
Operating systems being conceptually simpler than programming languages, PATHOS was easier for the LLMs, and was almost entirely written by Claude, although based on several paragraph of detailed spec. And Claude was able to plug Irony into PATHOS (that is, create comp and exec commands) first try!
However, I then asked it to create a help command that simply listed all the other commands, which was nearly a trivial task, and it failed over and over, until I did one of those resets described above, and then it worked. (The attention model is just the wrong model of working and short term memory! Mark my words! [Yes, I do get my own meta-joke.])
I also asked the LLMs to make presentations. Those are here essentially "as is" and you'll see that although these are a reasonable start, they definitely aren't complete teaching materials.
Holy S! How did I not know about this?! (I curate ElizaGen.org … where this is immediately going! DM me if you want cred by your rn on the elizagen news post; my rn and landline deets are in my hn about.)
Clarification: These papers are different enough that I don’t feel like I double dipped by posting both in HN, also the new pub is ... well, new. (Also, thank you for reminding me that I need to update the arXiv entry since it’s not been published!)
Not saying there was any double-dipping. Only pointing others to related discussion. (I myself added copies of both papers to my Zotero library—which isn't something I would have done if I thought they were duplicates.)
SHRDLU was written in Lisp, albeit a pre-CL list. So it was quite easy to bring up by writing macros that make CL work like older Lisps. We did the same thing with Bernie Cosell's ELIZA:
Although IPL is a direct Lisp predecessor, it can't be easily mapped to Lisp. Indeed, Lisp and IPL-V were contemporaneous for about 5 years, but Lisp was so much simpler and more elegant that it rapidly supplanted IPL. As a result, Ed Feigenbaum and I are probably the only living person who know IPL (and I only barely know it as I just learned it in the past few months!), whereas Lisp has been essentially endemic for 60 years! (I'm hoping I'm wrong that Ed and I are the only folks who know IPL. If you know of a native IPL speaker who I could talk to, I'd love you to DM me!)
Re: Why do you need the old code if you implement your own interpreter anyway?
Several reasons. First, we don't need it, we want it -- it's a nice-to-have not a need-to-have.
It's nice to have for many reasons, none of them huge, but together they vie towards having it if we can find it:
1. What we're after is running the old AIs, not having IPL-V. We don't intend to write any new IPL code. The old AIs just happen to be written in IPL.
2. We can run the code without having to reformat it. There are numerous annoying nuances when recreating a very old language, not the least of which is the importance of card columns, which is annoying to "wrap parens around".
3. If we bother to write an emulator anyway, we can test our emulator against the real thing.
4. IPL-V being Lisp's conceptual machine code (one version of it, anyway), it should be easy to do so, so there's that as an engineering experiment.
5. Writing anything in Lisp is fun so it's an excuse to take a break from ... well, from pretty much anything else on my agenda, most of which do not require Lisp programming (although I often manage to squeeze some in anyway. :-)
Interesting. Having the old compiler and an emulator is certainly helpful, but of course also yet another complexity. From my experience, it's very useful to have some decently large programs in the target language, the output of which are known. Thanks for the document, I will talke a look at it.
Excellent point. We have many decently large programs. In fact, we have pretty much the jackpot. Ed Feigenbaum famously wrote EPAM, one of the first simulators of human memory. Not only is the program extensively documented in numerous published papers and reports, and not only is entire the code online (https://purl.stanford.edu/vq775jv4844) but if you look at that code, it's actually a compiler output, so it shows us how pretty much every type of IPL-V instruction compiles!
Short answer: Lisp and IPL were competitors for the list&symbol-processing community of early AI. IPL invented a lot of what Lisp implemented in nicer syntax -- in effect, Lisp was an HLL for IPL. Lisp (obviously) won and now we're (ironically) emulating IPL in Lisp in order to emulate Lisp's underlying machine in the HLL that sits on top of that machine. (Actually - ironically^2 - SLIP won ... see below.)
Longer answer: This whole corner of language development was full of ironies. SLIP (Weizenbaum's approach to list processing) was a plug-in for Fortran (originally) and shortly thereafter, MAD. Just as Lisp wiped out IPL, it also wiped out SLIP. Ironically, today we do what Weizenbaum envisioned: Write in powerful general HLLs and add in specialized packages for things like list processing. So, in the end, SLIP won!
Overlapping. Some are the same, but the earlier team was Lisp hackers instead of MAD-Slip & FAP hackers, which makes sense and is almost a non-overlapping set of individuals IRL :-)
This has been picked up by a bunch of tech news sites. On Gizmodo someone wrote: “Hello World. OMG what the fuck happened while I was asleep?!!” Which is funny enough, but of course the next comment in response is: “How does that make you feel?” :-)
