[HN Gopher] Seeking an IPL-V Interpreter
       ___________________________________________________________________
        
       Seeking an IPL-V Interpreter
        
       (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://bitsaver
       s.org/pdf/rand/ipl/Information_Processing_Language-
       V_Second_Edition_1964.pdf) 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!
        
       Author : abrax3141
       Score  : 36 points
       Date   : 2025-01-20 18:13 UTC (4 hours ago)
        
       | retrac wrote:
       | 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...
        
         | abrax3141 wrote:
         | 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?
        
       | Rochus wrote:
       | Why do you need the old code if you implement your own
       | interpreter anyway? Why "(ironically) Lisp"?
        
         | abrax3141 wrote:
         | 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!
        
           | Rochus wrote:
           | 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.
        
         | abrax3141 wrote:
         | 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. :-)
        
           | abrax3141 wrote:
           | 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
        
             | Rochus wrote:
             | 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.
        
       ___________________________________________________________________
       (page generated 2025-01-20 23:02 UTC)