Ask HN: Seeking an IPL-V Interpreter | Hacker News Reader

Ask HN: Seeking an IPL-V Interpreter

52 pointsabrax314110 comments

(Part of) the team who recently reanimated the original ELIZA (https://news.ycombinator.com/item?id=42746506) is now working to reanimate what are often considered the first AIs -- the symbolic heuristic programs built by Newell and co at RAND in the 1950. Most of these programs were written in IPL-V, the fascinating (if ugly) machine level language for a stack machine that was the first to introduce list processing, recursion, and symbolic computing, among other innovations that we take for granted today.

There were many implementations of IPL-V. According to the manual (https://bitsavers.org/pdf/rand/ipl/Information_Processing_La...) implementations existed for at least these machines: B220, CDC 1604 and G-20, Ferranti Mercury, IBM 650, 704, 709-7090, 1620, Philco 2000, UNIVAC 1105 and 1107, and the AN/FSQ-32 (whatever that was). And we know that it was also on the IBM 360 and 7094.

If you have access to a code archive for any of these machines, and can search it for the IPL-V interpreter, we would greatly appreciate it. (A print out is fine -- preferred in fact!) We are building one ourselves in (ironically) Lisp, but it would be amazing to be able to run an original stack, as we did with the 7094->CTSS->MAD stack in reanimating ELIZA.

We (obviously) open source everything we do.

You can post here, or DM me (my email is in my "HN about"). Thanks!

There are references to the IBM 7090/7094 version under IBSYS online.

In this 7094 emulator package on Github: https://github.com/Bertoid1311/B7094 (in the zipped distribution files unfortunately) I think there is a copy that is runnable? see: Docs/Bamberger-MAMOS_docs/BAMBSYSLB1_patch_for_IPLV.txt

It describes patching the available binary to make it work, with the caveat that it's unclear if the interpreter is correct/intact (but it does run the demo programs).

On the provenance of the tape: https://retrocomputingforum.com/t/umes-resurrected-sort-of/3...

Yow! This is amazing! We'll check it out asap! If this sentence was a question would I have to use a question mark instead of an exclamation point?

Why do you need the old code if you implement your own interpreter anyway? Why "(ironically) Lisp"?

Two good questions; Two different answers.

First, re "ironically":

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!

Thanks. I read about IPL for the first time in McCarthy's history of Lisp paper, but never took a closer look. I now also see the irony.

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

BTW, Re: #2: There was a proposal for a Lisp-Like IPL that used s-expressions as list representations (actually, they call it "linear"): https://apps.dtic.mil/sti/tr/pdf/AD0611841.pdf

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!

Preservation.

They seem to care about it, which is why they're doing what they're doing in the first place.

Reply on news.ycombinator.com