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?” :-)
You want to be truly amazed, check out Newell’s IPL-V, which is a machine language for a stack machine, developed in the 1950s and used to implement the first AIs. It had every idea n Lisp except the parens.
Jeremy Braddock just (well, in October) published a scholarly yet extremely enjoyable book about The Firesign Theater, the brilliant 1970s-ERA audio improve group. Firesign often rolled technologies into their humor. In particular, the album "We're All Bozos on this Bus" has a long intricate piece that spins in and out of Lisp and ELIZA jokes (among many many others). The Firesign folks had had a demo of ELIZA, probably on a PDP-10. That would almost certainly have been Bernie Cosell's Lisp ELIZA, and we (ElizaGen.org) provided an image of the listing of that ELIZA, which appears as a figure in the book! (I'd tell you which figure and the page, but I loaned my copy of the book out. But if you are a Firesign fan, the book is, IMHO, fantastic throughout!)
Team ELIZA (and friends) are trying to make the original ~1965 MAD-SLIP ELIZA (discovered a few years ago in Jospeh Weizenbaum's MIT archives) run. A number of semi-overlapping groups are involved in this. Some have a 7090 emulator, some have a CTSS emulator on that, and some have various versions of MAD, SLIP, and the underlying FAP (IBM's Fortran Assembler) code that runs SLIP. (Yeah, I know. Go ahead and get the laughter out of your system. I did't name it!)
We (they) have this mostly under control, but for one single function, called "LETTER." that we cannot find the code for, and are having trouble divining the function of.
If you search for "LETTER." there is a single call to it on card 00386. (MAD functions all end with "."; There are several occurrences of LETTER as labels, but only one function call.) This is in the function(entry) LISTRD. (000096) [This was in the days when functions could have multiple entry points in order to conserve memory.] and is used to load an array called KNOW (indexed by I). LISTRD is an s-expression reader (but into SLIP not LISP -- see below for LISTRD documentation).
Some potentially important factoids: The 7090 had 36 bit words and packed 6, 6-bit BCD characters into each. (You can see this in line 000356 where it appears to be packing 6 close parens (BCD 34k) into a word: CARD(I)=343434343434K (K for octal). Notice cards are (were) 84 characters in width and 84/6 is 14 -- the number 14 is used in multiple places as a loop limiter, so it's apparently scanning across cards (and the minimal comments and some variable names suggest this as well).
[Unfortunately, comments were used quite sparingly in those days because you had to punch them into cards!]
Again, the only function for which we don't have code is LETTER. So, okay, Sherlock Hackers...What exactly does LETTER. do and what exactly is it doing here?
Maybe I'm misunderstanding what you mean by a card, but the 7090 used 80-column punch cards of which 72 columns could be read into the computer. (Which is why Fortran used 72-character lines.) The 7090 had a plugboard so you could select which 72 columns you wanted, but normally it would be the first 72. Why 72? Because cards were read "sideways" and 72 columns fit into two 36-bit words.
That is, cards were read row by row, not column-(character)-by-column — one ‘bit’ from every character at once. And this is the case for practically all card equipment. That surprised me a bit when I first learned it, as someone used to sequential character streams, but it makes sense in the context of pre-computer card operations, where cards and holes started and stopped counting wheels for each digit (column) at once to calculate totals.
The IBM System/360 moved to card readers that operated column-by-column, e.g. the 2501 card reader or the 2560 Multi-Function Card Machine. As you said, reading row by row makes a whole lot of sense when you have electromechanical equipment. It's amazing that they could build things like card sorters without any electronics, just a brush and solenoids.
Yeah. That's actually one of the things that makes this story so interesting: It took place exactly at the dawn of the inter(arap)net, and physically close to BBN (which was the arpanet implementor), so there was lots of sharing between MIT and BBN, in particular, McCarthy put a lisp on BBN's PDP-1, and Bernie Cosell's Lisp ELIZA, which he did from the algorithm in Wiezenbaum's CACM paper, was the one that became public, so everyone thought that ELIZA had originally been implemented in Lisp, which was wrong!
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. :-)