computerhistory's History of LISP

History of LISP (software collection committee) edited by Paul McJones. Abstract:

The goal of this project is to locate source code, design documents, and other materials concerning the original LISP I/1.5 system, and as many of its follow-ons as possible. LISP was one of the earliest high-level programming languages and introduced many ideas such as garbage collection, recursive functions, symbolic expressions, and dynamic type-checking. This is a pilot project of the Computer History Museum's Software Collection Committee to develop expertise in the collection, preservation, and presentation of historic software. Comments, suggestions, and donations of additional materials are greatly appreciated.

I ran across this page by accident while googling for "lisp assembler lap" because I'd recently learned LAP was the standard acronym for lisp assembly program (ie a lisp based assember), which also described what I was currently trying to do. It's funny how often a new idea is just the Nth repetition of many old ideas. :-)

Anyway, this page links a wealth of interesting material on early Lisp implementations. (Unfortunately a number of the PDF documents don't open on my current machine, so I can't read several of the items I find most interesting, including everything L. Peter Deutsch authored.)

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

Can't open PDF docs?

I can open them, using Foxit Reader - can't recommend it highly enough, not bloated like Adobe Reader: http://www.foxitsoftware.com

Henry Baker on creative destruction

I ran across another article, by Henry Baker, which seems partly about the history of Lisp and partly about how to improve and version old languages for new livelihood (which sometimes seems a minor subtheme in some LtU threads), and for both these reasons I thought this a good place to add a link for folks into that sort of thing.

Critique of DIN Kernel Lisp Definition Version 1.2 (circa 1992)

One sentence was italicized by Baker in the introduction (and I agreed with the italics!) and this one sentence is what made me decide to link the the paper here:

All progress is a process of creative destruction, wherein the hardest, but most important, decisions involve what must be pruned in order to free up the resources needed for new, more vigorous growth.

In other words, an important part of improving things is deciding what to forget that impeded progress.

Re inability to open PDF documents

Rys,

If you'll let me know the identity of specific PDFs that cause you problems, I'll check them and convert them, if appropriate, to an older version of PDF (the versions of PDF natively written by Acrobat 6.0 and 7.0 may not yet be supported by all PDF viewers).

(See http://community.computerhistory.org/scc/projects/LISP/ for my email address.)

much thanks!

I need a block of time to check them again, say before Monday, but your offer is very gracious and kind! I still can't get used to the internet Heisenberg effect where taking notice of something can change it. :-) I'll email a list later; I hope your address here doesn't draw spam.

reading PDFs

hi there,

try googling a PDF link by using "type:PDF whatever subject" -- this will get you the link in google. Google also has a view as HTML for most PDFs -- you can then view the PDF as HTML.

Hope it helps.

BR,
~A

limited PDF availability

anjanb: try googling a PDF link by using "type:PDF whatever subject"

I was excited about this, but results for 'type:PDF "Peter Deutsch" lisp' were very slim, for two reasons I expect. For example, hits for that search included papers from ACM available for a price only. If Google made them available as html, it would subvert sales of PDFs from ACM, so I assume the ACM website has annotations telling Google not to do this.

The other reason is the technical difficulty in OCR (optical character recognition). Several computer history papers (see link in the OP) are scans of varying quality, so I suppose the PDFs are wrappers for some postscript based raster representation. (I tend to get "not a valid postscript document" error messages after a PDF reader opens them; the free eval copy of Foxit Reader for Linux does succeed in display, but doesn't include print capability.)

Google would have to OCR the scans to make them available as html; I'm not surprised if they are not yet aggressive about making that transformation free for PDF.

Cross Assembly

An early way to generate code for a microcomputer was cross assembly. Usually a Basic program run on something like a PDP- that produced a paper tape for the micro. Edit; or you could enter the op codes with switches.

Wait, It Gets Better!

Rys David McCusker: I ran across this page by accident while googling for "lisp assembler lap" because I'd recently learned LAP was the standard acronym for lisp assembly program (ie a lisp based assember), which also described what I was currently trying to do. It's funny how often a new idea is just the Nth repetition of many old ideas. :-)

I regret that I can't find the reference at the moment, but I have it on good authority that the assembler for Guy Steele's Scheme compiler, RABBIT, was called LAPIN. :-)

Even better

IIRC Steele wrote that LAPIN was the MACLISP assembler function -- it was RABBIT that was the pun.

Rys, you might perhaps like Miasma, my x86 Scheme assembler. (Only version 0.1 had a LAP-ish assembler; I didn't need that feature in the later overhaul.)

good puns; good assemblers

Thanks Paul, that's a really good pun. :-) But darn, I think it's funnier given Rabbit first, then Lapin. I love to hear what the greats were doing and thinking.

Darius Bacon: you might perhaps like Miasma, my x86 Scheme assembler. (Only version 0.1 had a LAP-ish assembler; I didn't need that feature in the later overhaul.)

Cool; I expect to look, but the LAP for gyp might not be very similar since Miasma is Scheme to C or Python. My aim is to assume only C++ (say gcc) for C/C++ to gyp, so I'll write the LAP in a kernel for the gyp runtime running the LAP natively as a spec for VM byte code. I want to delay as long as possible any effort to broaden my base of technology pyramid down to native code, since it's optimization and absorbs much time as a pyramid bottom broadens.

(I hesitate to discuss what I'm doing more than as motivation for finding the cool page in the OP. I've been bitten too many times by bad effects of discussing vapor. But there's an aspect to planning things like this that can inform other folks writing new VMs and languages, because the way to bootstrap can include a lot of interesting choices. Even so, I don't see how to describe my plans without it sounding like evangelism, which I don't want.)

Incidentally, you have a great name that I envy. (My subconscious keeps telling me, "Sir, I have Francis Bacon version 2.0 on the line; shall I put him on?" I have trouble turning off a humor channel in the back of my mind, and the name Bacon keys a time traveling character I enjoy.)

Francis Bacon version 2.0

Heh, Zooko said something similar once -- thanks. I'll email you about the VM project.