Advent of Computing - Episode 185 - Is EMUL-8ion a Form of Flattery?

Episode Date: July 6, 2026

EMUL-8 is a fascinating programming language. It's described in just one paper from 1977. It's a mix of features from APL, LISP, ALGOL, and SNOBOL. And, I think, it's a wonderful window into how counterculture and home computing collided.

It's finally summer here at the central office. That means one thing. It's backpacking season. I will stand by the fact that Northern California has some of the best hiking trails you're ever going to find. If you're willing to go a little out of your way, then you can see some truly stunning sights. I really like backpacking and hiking because it can force you to see things from a different

perspective. Sometimes it takes a while, but you will see different things if you give you. yourself the chance. In fact, this episode is a little late expressly because of this phenomenon. I just got back from one of my favorite trails. It's around this peak called Salmon Mountain, which is the high point in my home county. I was hiking out to camp by an alpine lake that's in the shadow of the summit. The trail brings you up the mountain via its north ridge before dropping you down into a high valley. Now, I've seen the mountain many times. I've made it up to the summit twice, so it's not a new site to me. But yesterday, something finally clicked. The North

Ridge of Salmon Mountain is used as part of the county line between Humboldt and Trinity counties. I've known that fact forever, but I hadn't noticed how stark that line actually is. Humboldt is home of the Redwood Forests. The county is known for its lush vegetation. It's literally a temperate rainforest. Most of our hills are covered in trees. Some of the forests here are so thick that you'll quickly get lost if you decide to go off trail. Just over the border to the east are the Trinity Alps, a beautiful range of rugged granite peaks. I've spent countless hours in the Alps and the coastal forests, hiking both sides of the divide. But I've never noticed how stark that divide is. If you manage to get out to the North Ridge of Salmon Summit, you'll see it for yourself.

One side of the mountain is covered in trees. The other is nearly bare granite. The delineation is exactly on the county line. Like I said, I love being in the back country because it forces you to see things from different perspectives. Sometimes, to get there, you have to look at the same thing a dozen different times. Sometimes it just takes being in the right state of mind, but catching those differences fascinates me. Today, we're looking at some software that forced me to see things differently. It made me take a different perspective on something that I've been thinking about for years. Welcome back to advent of computing. I'm your host, Sean Hasse, and this is episode 185. Is emulation, a form of flattery? Before

the show starts, I have my usual plugs to place. First of all, if you haven't heard of it already, advent of computing now has an after show called Adjunct of Computing. A lot of you have already found your way over there. If you haven't, you should go give it a try. It's a slightly different format than the main show, but it picks up where the recording ends. It's great if you just want to hear a more casual conversation, filling in the gaps missed in my normal episodes. Also, August 1st and 2nd, I'm going to be at VCF West in beautiful, well, in extant Mountain View, California at the Computer History Museum. The schedule's out, and it looks like I'm speaking early on Sunday morning about some weird Unix versions and derivatives. So come out and support the podcast and support VCF, which is a fantastic event no matter where you catch it.

Now, to the episode itself. My hook into this topic is, well, let's just say it was fate. After my APL episode, I was sitting down for a break. I was flipping through the pages of proceedings of the first West Coast Computer Fair on the cruise for my next topic. I figured it would be fun to do something micro next. It could help me stay out of the 40s, maybe a little longer. I found myself reading about this operating system called MOS 8, E-M-O-S-8.

It claimed to run on the Intel 80-80 and be compatible with C-P-M, Intel's PLM, and this thing called Emul-8, E-M-U-L-8, which is described in another paper. Luckily, that paper is in the same proceedings volume. Now, you know me, that immediately struck my fancy. an operating system that's compatible with a pile of things that runs on small hardware. Of course I'd be interested. Where this went off the rails was Imul8. So, get this.

Imul 8 is a high-level programming language that's meant to run on Emos 8. The two are tied at the hip. The language, you see, has diatic and monadic functions. I said I'd be on the lookout for APL after last episode, and, well, I guess my senses must have been tingling. But that's not what makes Emulate interesting to me. At least, the APL connection is just part of it. Emulate is a true amalgamation of languages.

It has some aspects of LISP, specifically in how it talks about data and stores information and memory. Its syntax is modeled on Algal and Pascal. It even name drops bliss. This really got me because it's so different than papers on other languages. The West Coast Computer Fair wasn't exactly an academic conference, so folk are writing in a very different voice. Usually languages don't wear their influences on their sleeves like this. You have to decode where ideas are coming from.

Both emulate, those connections are explicit. There's also the more specific case here. APL and LISP both sound connected, right? Their functional programming languages built around arrays as their primary data type. But those two languages are unrelated, completely different. Yet, emulate draws ideas from both. That's really cool. So in this episode, we're seeing just what I can dig up about this odd programming language and its operating system.

Along the way, we're going to examine how languages influence each other, how time makes strange bedfellows, and just what is the difference between a language and an operating system. Who made this marvelous software? I think that has to be our starting point. Both of these articles were written by one man, and he even gives us. us a short bio. Quote, Bob Wallace wears several microcomputer hats in the Seattle area. He is a founder, past newsletter editor, and current secretary of the Northwest Computer Club.

In addition, he is publications manager for the retail computer store. He orders all their books and magazines. Finally, he is a graduate student in computer science at the University of Washington. In his spare time, he consults for New World Computer Service. Inc. does event logistics for ComNet and tries to get his computer running. He is 27 and single, end quote. I feel just from that like I know a Bob Wallace. I have, at certain times in my life, been a Bob Wallace, perhaps. What's more important is that this short bio gives us a few lines of inquiry. Why did Wallace come up with this wacky idea for a language and an operating

system? Could his past works or editing lead us to the answer? And is Wallace still single? Luckily, I can answer some of those questions. Wallace does end up getting married in 1984. Now, we can move on to the less pressing matters. Wallace became obsessed with computers at a young age. According to Ed Lazowska, who went to college with Wallace, his obsession started at 12. Apparently that year Wallace decided he would become a computer programmer. Wallace would do his undergrad work at Brown University in 1967. It was there that his worldview would be forever changed. There was this wild project going on at Brown in this time period.

It was called HES. It was one of the first attempts to implement computer hypertext. The project was headed by Andy Van Dam and Ted Nelson. Nelson, of course, is the one to coin the term hypertext in the first place. Van Dam is one of the first people to attempt to implement it in binary. The two didn't always see eye-to-eye on a lot of the details. Nelson eventually left the project. Van Damme then used the lessons learned.

from HES to create a larger system called Fress. That's where Wallace really comes into the picture. He had been blown away by the hypertexting graphics work already underway of Brown. With Fress, he had the opportunity to contribute, and contribute he did. Wallace would design large portions of Fress, to quote Fandam.

Much of it, when he was tripping on acid and God knows what else he was ingesting at the time, This was the 60s. I knew my students were doing drugs, and there was nothing I could do about it, and as long as they performed, I was not about to tell them how to live their lives." This should set the stage pretty well, right? Wallace is sitting at this huge confluence of ideas. Brown, and especially the hypertext group, were working off a new playbook. The central idea was that computers could be used by non-programmers, in fact, should be used by anyone. Hypertext was just a tool for that. HES and Fress as systems allowed for non-linear associations

of data, for links between ideas. In the most pure form, that's something like a grand database of all information in the world, that a human could navigate with a few simple touches. In a more practical form, Fress became something like a super text editor. Students at Brown used that software to write and typeset papers and even books. It was used to organize data and lesson plans and classes. It was a useful tool built on some big ideas. And Wallace was getting exposed to and codifying these ideas while on LSD. And this isn't just an edgy tangent.

The counterculture of the 60s is directly connected to many of the liberatory ideas around computing. If you want the full story, I'd recommend reading up on Lee Felsenstein. He recently published an autobiography, which, sadly, I haven't finished reading yet. Sorry, Lee, but I have had a chance to hear a few of his talks about this period. The gist is that the home computer movement grew up around the counterculture of the late 1960s and early 70s. The two were tied at the hip. Felsenstein was heavily involved in the Homebrew Computer Club. That's the scene that Apple and many other giants of industry would emerge from.

The club was organized in the same way as protest and mutual aid organizations that Felsenstein had been part of at UC Berkeley. A programmer working on code that Ted Nelson himself had disdain for while tripping on acid, well, that's par for the course. It's not a wild one-off story. It's one piece of the larger digital scene in this period. When Wallace graduated from Brown, he moved out to Seattle. Apparently, the trip was done in an old bread van. Now, let me be clear here.

As far as I can tell, Wallace wasn't connected to Felstonstein or the Homebrew Computer Club. Although, I bet he did read some of Felstonstein's articles back in the day. So there is probably some influence, but I think it's more that things were just in the air back then. It's the historical context that I talk so much about. Once in Seattle, Wallace would start organizing. His bio says it all. He wore many hats. While wearing one of those hats, he founded the Northwest Computer Club. You'll see this sometimes called the Northwest Computer Society.

But it appears that club was the word used in this period. Wallace founded the club in 1976. The first meetings were at his house in Seattle, but it soon outgrew the space. By the end of the year, he held meetings twice a month at the Pacific Science Center, just a few blocks from the waterfront in Seattle. According to Dr. Dobbs Journal, the club avoided a near disaster. Quote, The Seattle area almost had three clubs start independently of one another in January.

Fortunately, however, they were organized. discovered each other and joined forces, end quote. Again, there was something in the air. There wasn't a single flashpoint here, but this also puts me in a bit of a bind. You see, clubs often issue newsletters, and the Northwest Computer Club was no exception. Newsletters are a treasure trove of information,

but that's the thing. Newsletters are, well, let's just say, they're rarely fossilized. It can be pretty hard to track down old newsletters, which really burns me here because supposedly the first issue of the club's newsletter had a full history of the club's founding. I found some magazines that have reprints of articles from the newsletter and a handful of full scans of newsletter issues,

but not that precious first issue. One of those scanned issues we have is from 1977. At that point, Wallace is working as editor and publishing a column called Bob's Bits, which is general news about the club and ramblings about the computer scene. What keeps surprising me is just how much Wallace is doing in this period. In addition to editing this newsletter and club activities, he's holding down a job, earning a graduate degree, and writing a lot. I can find short articles from Wallace in a pile of magazines.

The commonality is, almost always, the idea of digital community. Wallace is championing ways to connect people with computers. Some of this is for computer nerds. In 75, he tried to spin up this thing called Com Index. It was, to quote, a global directory of groups and people interested in the use of computers as a community communications tool and a list of papers, articles, and other information available for copying costs. The Comindex will also try to include other areas of alternative computer use, such as

access to hardware, simulation of systems, creativity and graphics and games, computers and education, and social slash political research, end quote. This all really resonates with me because it points out an issue with traditional narratives around computing history. Often when we're talking about the microcomputer era, we're focused around Silicon Valley and the Bay Area in California. That's where the Homebrew Computer Club is. It's where Apple comes out of.

It's where Xerox Park is located and SRI. It's the cradle of all these ideas that align really closely with what becomes home computing later on. But that's just one concentration. of nerds. I feel like there's such an emphasis on Silicon Valley because that ends up becoming a big industrial center. But the emphasis is dangerous because it can act as a bubble. Luckily, it's easy to pop. Mitz, the company behind the Altair 8800 is based in New Mexico. Microsoft is based in Seattle. Sometimes I see those mentioned as special exceptions approve the

rule, but that's not the case. They're pointing to something larger that's often forgotten. The simple fact is there were other centers of digital fanaticism. There were clubs all over the country. You just have to scrape below the surface. Taken in that context, the rise of home computing really is like a revolution. A new identity is being formed. The face of computing is really changing in a very definite way. It's not 100% part of the counterculture, but it's a near neighbor. Thelsenstein makes some good points,

and one of those is that to understand the home computing revolution, you have to understand the counterculture of the 60s and 70s. Anyway, I promised software, and we're getting there. I'm setting the stage here because I actually have some neat sourcing. So get this. In 1977, the first West Coast Computer Fair was announced. It was set to be held April 15th through 17th in San Francisco. Jim Warren, self-proclaimed fair chair being, explains the rationale like this,

quote, Home and hobby computing developments are racing along at such a pace that they make even the prodigious progress taking place in the field of electronics and computer science and engineering appear to be leisurely motion. In the brief two-and-a-half-year history of personal computing, we have seen it grow from an obscure hobby involving perhaps a few hundred home computers to the current situation in which there are possibly 50,000 or more general-purpose digital computers and private ownership or personal use. End quote. It was time to bring all the freaks,

nerds, dreamers, and visionaries together. so a space was rented in the San Francisco Civic Auditorium. A date was set. Newsletters and club meetings around the country spread the information. And, most importantly for us, this left a paper trail a mile wide. Warren explains that a proceedings of was planned from the beginning. These non-academic papers would be published, talks would be given, the community would be rounded up and handed a nice paperback book.

and our main man Bob Wallace was ready to get swept up in the excitement. From the Silicon Gulch Gazette, quote, Washington Staters organizing tour group to attend computer fair. Bob Wallace of Seattle's Retail Computer Store and the Northwest Computer Club is the prime mover behind organizing a tour group for the Northwest to attend the first West Coast Computer Fair in San Francisco, April 15th through 17. Such a group should offer significant savings in transportation costs for those attending the fair from the area of the country."

So that April, Wallace loaded up and headed south for the fair. I can't figure out who all carpooled with him. The first proceedings has one other author from Washington, but they could be of no relation. Whatever the case, Wallace was California bound. And, word to the wise, if you do the same trance, if you do the same trillions, trip, take the 101 all the way to San Francisco, not the five. The 101 is much prettier. I can only hope Wallace took the same route. So what does an intrepid young programmer and organizer show off at the first West Coast Computer Fair? Why, a totally new operating system and

totally new programming language? I know, that seems like a bit of a jump. And, well, it is. is. Wallace presents two papers at the fair. They cover the language Imul 8 and the operating system Emos 8. And I can already hear Joe in my ear. But Sean, what's the difference between a language and an operating system? And I swear, we're going to get there. This is the first paper trail about these programs. And it's also the last. This appears to have been a blip about a cool project that Wallace had been tinkering with. What's more, these aren't about real programs, not in a physical sense. Wallace describes them as quote-unquote paper designs. So we're looking at two articles about some theoretical software. That said, there is a lot more detail here

than you might expect. Wallace started out this project as just an operating system, MOS 8. He describes his design goals as modularity, extensibility, and conviviality. Sounds very, very smart, but what does that even mean? And more importantly, what does that mean in the context of 1977? Modularity is a pretty technical design goal. Imagine, if you will, a module. It's a little box that you plug in that provide some cool new feature. At WidgetCo, for instance, we provide do-nothing modules. When you plug them in, they spin and whine. But you only really need some spinning parts part of the time. Modules are handy because they're a way to deal with this. When you need the module, you plug it in. When you don't, like, say, you get sick of the whining, you unplug it. The software modules work in

roughly the same way, but they have some code to bind them off instead of a plug. This ends up being very useful, especially for small computers. MOS 8 is supposed to be targeted at the Intel 8080, which doesn't support all that much memory. By using modules, you can get the most out of your RAM. Let's say you want to use a printer. Under a modular operating system, you would only load your printer module when it was time to print, then you could unload it when the print job was over. That means that when you're, say, actually editing a file, you aren't wasting memory on that printer module.

That could allow you to do things like have a more sophisticated text editor, you know, since you have extra RAM, or allow your text editor to work on larger files, since again you have extra space to work with. We've seen things like modularity before here on the podcast. RSX11 itself from the early 70s is a modular operating system. It was developed at deck and had the ability to load and unload modules as it ran. So this isn't an entirely new concept.

But RSX11 did this in a pretty clunky way. You had to do everything numerically and you had to pre-defined slots in memory to load modules into. Wallace proposed something more streamlined. In MOS 8, modules are all named. In fact, everything in the system is named. They're managed by this thing called the Global Name List. This is a handy list of all the resources that the machine has stored in memory. It gives each resource's name, what kind of resource it is and where it lives in RAM. The name list paired with the ability to allocate new chunks of memory makes MOS 8 a pretty slick little setup. This means you can load modules off disk as they're needed. In other words, you can expand the capabilities of MOS 8 in real time.

That's the second design goal right there, extensibility. MOS 8 can be changed and upgraded as needed. If the user needs a new feature, they can get a new module for it. If the user needs to change how something works, well, they can just change and reload a module. And that leads us to design goal the third, conviviality. This word, more than anything, is a bit of a tell. It shows up in a lot of articles in this period, and even in other articles from the West Coast Computer Fair. In fact, Belsenstein and Nelson used the term in this very same volume. It's got to be important, right?

But what does it mean? In the sense Wallace uses it, conviviality means something like human-centric design. Quote, MOS 8 is convivial, in that it offers a set of facilities to the user who is free to use them, modify them, or build in new components. It is intended that source code always be distributed and be very well documented both at the program level and with a principles of operation manual, end quote. Convivial software is flexible and adaptable by the user. It can be used as a tool of expression and freedom. Early hypertech systems, for instance, are often described as convivial software systems. Those systems would start out as just a blank page that a user could then express themselves at.

But conviviality has some more specific connotations to it. It's often said that the term conviviality is coined by Ivan Illich in his 1973 book Tools for Conviviality. It's coined when he adds ITY to the end of the existing word convivial. That's my nitpick. I think it's better termed that he adopted the word in 73. Anyway, tools for conviviality became a very popular book in this period. This was especially true in counterculture circles that were rapidly becoming digital. Illich's book isn't about computers. It's about fighting against the harms of post-industrial society. I need to read the book myself. It's

definitely, now, near the top of my reading list. I've been working off of a very good article in the damaged Earth catalog that puts Illich's book into the context of the period. The core argument that Illich makes is that tools used by industry aren't convivial. They're used to extend what humans can do, but in the wrong ways. These tools are used to extract profits more efficiently from humans. Illich counters these tools with convivial tools, things that allow humans to better express themselves or give humans more freedom.

The phrase often used here is, quote unquote, responsibly limited tools, as in tools meant for freedom of expression, not for extracting profit from labor. It's an argument about a shift in priorities and how the priorities of post-industrial society are pointed in the wrong direction. This idea was picked up by the growing home computer scene. Computers in their earlier incarnation could definitely be seen as industrial tools. But with the advent of the microprocessor, there is the possibility of using this technology more convivially.

Systems like community memory, HES, press, and many others had already shown that large industrial computers, and these industrial tools could be used as convivial tools, that they could be used to better aid in human expression. So imagine what would happen if a whole computer could become a personal tool instead of just a slice of a mainframe. By calling MOS 8 convivial, Wallace is placing it in this larger context. It's an operating system that can be a blank sheet, waiting for a user to expand it, to grow it into a personal tool for any pursuit. Those are some big ideals to enshrine in software. This, to my mind, is also why MOS 8 is planned to be compatible with two other operating systems. CPM is the

biggest operating system of the period. PLM is, well, it's one of those language operating system hybrids. It's used in this period also, but not to the same extent as CPM. By making MOS 8 compatible, that meant users had more choice in what they ran on their computer. You can run CPM software, but you can also do a lot more. You have more options, more power, more freedom. That sounds in line with conviviality. It's also very different from other compatible systems, like Unix compatible systems in this period. Here, compatibility isn't about market share or money. MOS 8's compatibility is about freedom and choice.

There's also a bit of a rhyme going on here between CPM and Emos8. Compatibility is planned to be pretty simple, since CPM itself is very simple. All CPM really does is offer a few system calls that applications used to control disk drives and print to the screen. MOS 8 just has those same system calls. Simple. The rhyme, however, is in modularity. In the 70s, there was still a wild amount of variability between different microcomputers.

Even in two systems that both used an Intel 8080 processor, there would be huge differences in their architecture. One machine might do traditional serial I.O. for a terminal, another might support memory-mapped graphics in a video display. Discs could be controlled in different ways. There wasn't really standardization. CPM solved this problem with the BIOS. If you're a PC-officionado, then you may already know that name.

It stands for the same thing here. Basic input output system. The CPM BIOS is a module that provides hardware drivers for your computer. that smooths over everything weird about differences in early 8-bit hardware. If you want CPM to run on a new machine, you just write up a BIOS module. Ideologically, that's pretty similar to what Wallace is proposing. It's just that MOS 8 is doing something more general purpose than what CPM did. There's one more aspect of MOS 8 that I have to bring up before we move on.

That's its user interface. Wallace is flexible about just about every part of the system except its interface. He does hedge that it's technically possible to use a teletype, but MS8 really needs a video display module to shine, as in the computer needs a CRT. This is actually pretty new stuff for the period. It was most common for computers in the first half of the 70s to use a teletecta. type or other kind of terminal as their interface.

The VDM1, likely the first thing like a graphics card for a microcomputer, had only been released in 1975. So the idea of using an interactive CRT with a microcomputer was two years old, if that. Why does this matter to Wallace? Well, it's all about interactivity. On a terminal, you have limited interactivity. The computer sends text to print and you send keystrokes back to the computer. You usually can't erase text unless you're using something like a fancy glass terminal, but even then, your interface is limited.

A VDM allows you to erase text or move text or even scroll around on the screen. While working at Brown, Wallace would have worked with mainframe machines that had interfaces that allowed for this same kind of functionality. so he knew firsthand how important this kind of technology was for interactivity. MOS 8's default interface uses this to break the screen into two windows. The lower window is called the command window, the upper one is called the display window. Quote, the command window is used for operating system commands and error messages, and the display window is used for text being edited. User programs can use either.

As text records are written in a window, it expands at the expense of the other window. The other window may be left with a minimum of one line. There may be a line of dashes separating the two windows. Records are scrolled off the top of a window when new records are added to a full window or the other window expands, end quote. My analysis here is, that's darn cool. Wallace is actively looking for a way to make a more interactive experience. What he lands on is actually similar to a larger system like NLS, where you have a region for

entering commands and a region for displaying data. Or even later systems like Microsoft Multiplan, where you have a bar for entering commands and then a window for showing what you're working with. Now, there is one other aspect to MOS 8's interface. That's the actual commands themselves. As Wallace explains, he started out simple, but that soon changed. As MOS 8 became more sophisticated, he realized he needed something almost as complex as a programming language to manage everything. That spun off into its own design called Emul 8.

So what is this language like? I guess we should start with how it's connected to MOS 8. The memory management and modular aspect of both of these systems is core here. Both Emos and Emiol use name lists and a shared memory allocator. In Emos 8, the global name list is used for things like modules. Emul 8 uses name lists, including local lists, for variables as well as modules and other executable forms of code. That's a cool symmetry.

This is kind of the first connection point, and is where languages and operating systems usually blend together. A language deals primarily in variables. Those variables have to live somewhere in memory, so you effectively need a way to allocate memory to program. Memory allocation is, more often than not, something that an operating system does for you. We can see that in C, a very popular language, very explicitly. The actual language itself is small. It's super simple and doesn't do a whole lot.

Most of what it's known for, including things as basic as the functions malloc and print F, are part of C's standard library. That's a library that traditionally, may, calls out to Unix. It's the glue that ties C to an operating system. Emulate is a little different here. It's not that it has some connector that ties it to MOS 8. Rather, they are specified to use the same memory allocation system. The connection is direct. There's also an ideological throughline. Emulates design goals are explicitly stated as modularity, extensibility and conviviality. I mean, it's basically an offshoot of M.O.Sate at the end of the day, right?

After my deep dive into APL, I think I have a good idea of what the language looks like. That's not to say I know how to program the language, but I know a lot about it. There are a few diagnostic fingerprints. One is the lingo. If a language calls functions diatic or monact, then it might be related to APL. Another sign is infix notation for functions, as in you call a function with an argument to either side of the function's name.

That's relatively unique to APL syntax. There are also more ideological things about APL that show up in other languages. But that gets a little fuzzy around the edges. APL's functions all operate on anything you give them, be it a single value, a list of values, or even higher order constructs. The term for that is called orthogonality. A small set of functions all have to find behavior for any inputs. Now, here's the kicker.

This is the fuzzy part. Orthogonality isn't just an APL thing. It's a programming thing in general. The term really comes into use with the development and really the refinement of algal. That language isn't related to APL. So while orthogonality is a crucial part of APL, it's not entirely usable as a fingerprint.

If we're just talking big picture, then we can say that if a language has monads and diads, operates on lists of all kinds, and lives and dies by composing functions, it may have been influenced by APL. tracking the influence of Lisp is equally tricky. Lisp's syntax is super diagnostic here. If a language uses reverse Polish notation,

as in the function comes first followed by a list of arguments, and it's studded with parentheses, then it's likely connected to Lisp, but that's just one level of things. Lisp is another one of these languages that straddles a language and an operating. system. The language is built around working with lists of data. To do that, you need a way to manage memory. You need a very specific type of memory allocator, you know, one of the core features of an

operating system. LISP is finicky about how it handles memory. That makes for a pretty good fingerprint. Again, we can come at this fingerprint in terms of, well, in terms of terms. LISP breaks text and data down into atoms. That's its word for a token, a representable chunk of text or information. Any word in a pile of Lisp code is called an atom. Data is stored in memory as a list of cons cells. Those cells have two parts, car and CDR, sometimes called car and coulder. The first, Carr, points to data that con cells hold.

The second, Kudder, points to the next cons cell in the list. Note that this is very simple, but also very specific. Again, as with APL, this feature isn't totally unique to Lisp. The more common name for this setup is a singly linked list. That gets used in many places that aren't related to LIS. So to show clear lineage, we need a little extra connective tissue. Linked lists are assigned, but not foldproof. The emulate paper uses terms like monadic, diatic, and atom when describing itself.

That, plus some of the implementation details, Tell Me Wallace was very interested in both APL and Lisp. That should make good sense, right? I mean, theoretically. APL and LISP are both languages that deal in functions and lists. APL has a really neat way to deal with functions, and LISP has a really smart way to deal with lists. So why not just kind of push those two ideas together and get something pretty slick? That's basically what Wallace is doing.

At least, that's part of emulate. emulate. Emulate isn't a perfect fusion. Rather, Wallace is taking heavy influence from these two languages. He uses atoms by name. Quote, an atom is a variable name, perhaps with a prefix, a constant, a command with its arguments, which are also atoms, or an expression in parentheses, end quote. That lines up fairly closely with how Lisp describes atoms. Furthermore, lists are composed of what are almost identical matches for cons cells.

Now, there is some subtlety here. Classically speaking, a con cell is only two addresses. An emulate list element is two addresses plus an 8-bit type code. That's a slight deviation. It makes this more like a fancy linked list. but the fact that Wallace is using the name Adam and a linked list makes the Lisp connection pretty clear. While I'm here, this is also how name lists work.

A name list is just a normal list that has a specific type code. It's neat to me that the memory allocation used in Emul 8 is actually just exactly the same as what's used in Emosate. Again, there's a deep connection between the language and operating system here. What I want to make clear is how subtle this influences. It's not that ML8 is full of parentheses and uses every same word in the Lisp lexicon. Wallace is borrowing a few ideas from the older language. And even there, he's making changes. The type field is just eight bits, but that feels super specific to me.

If I can wax poetic and truly no one can stop me, it feels like a solution that Wallace worked for. I can totally see him designing memory management for MOS8 and starting from what he knew about Lisp. He would have been taught it in school in his graduate program. The memory design of Lisp is clean, proven, and very well known. But he runs into the problem of data types. Lisp doesn't have data types, but he wants Imula 8 to support a few different types. So he adds in a flag field. That feels like such a natural progression to me.

It's what I would have done in his shoes. The APL influence is also somewhat subtle. The big hint is that Wallace gives us monads and dyads. They work almost the same as an APL. They don't use crazy characters, and they don't fully line up with APL's function set, but they're used in a similar way. There are also some functional ideas present.

For example, any emulate expression will evaluate to a value. Everything returns something. That's a building block of functional programming since it allows you to chain expressions together to make larger expressions, to make programs. For example, assignment is a function. That's another thing that, while not strictly diagnostic, is one of these building blocks. Again, note this kind of subtlety.

Wallace is using ideas from APL and its relatives, but not making an APL clone. That said, he does name check APL. Now, I gotta do a little setup to get to that. So, Emulate has this concept of current value. It's a magic variable called CV that's always available. When an expression evaluates, its output goes into CV. You can also use CV in expressions explicitly. Wallace tries to explain this by saying it's similar to an accumulator register in a computer,

but that's not entirely correct. CV is more like the default variable. If you just type out of value, it's loaded into. to CV. Wallace gives the example of typing something like plus one to add directly to CV. It's a neat setup that lets you do a lot of shorthand. You can even load variable names into CV and use that like a pointer. It's less like an accumulator register and closer to some of Snowball 4's features. I don't want to go super deep into that because I can misremember Snowball features all day long. The short explanation is that Snowball has all these ways to get intermediate values and set the default

places for data to go. During a pattern match, you can reference where you are in the string you're matching, for instance, or see what string the interpreter is currently looking at. Now, I promise the APL name check. While talking about CV, Wallace gets to this point, quote, Most interpreters do much the same thing except they have operator precedents. For example, they do all multiplication before any addition. Imulate does everything strictly left to right. APL, by the way, does everything strictly right to left, end quote. It's a bit to unpack there.

First of all, let's close the whole CV thread. Wallace is essentially saying that CV exposes how his interpreter for emulate works. CV is an internal thing that emulate uses that the programmer can hijack. That's primitive, it's scrappy, and I kind of like it. Second is that emulate doesn't do smart math. It's a pain to implement operator precedence, you know, Pimdas. So why not just say screw it? After all, APL does the same thing. Just, well, in reverse. I think this is another really clear influence.

Wallace probably saw that APL got away with ignoring Pimdos, so why couldn't he? And it worked out for him. The TadMath police never arrested Bob Wallace after all. Seriously, though, this is another one of those choices that I can really feel. The code for doing PIMDOS is annoying, and it takes up memory space. space that could be used for something more important, like the global name list. Wallace obviously knew APL to some extent. He knew that APL got away with its own special precedents,

but he didn't like how APL handled it. So Wallace introduced his own math precedents that he preferred. At least, that's the read I get. It's clear to see that there is influence from APL here, But emulate is very much not an APL-like language. For one thing, it's not functional. It's imperative. Well, kind of.

Here we come to another gray area. Emulate syntax is very similar to algal, meaning you have lines of code that are organized into blocks. You even get multi-line control structures like loops and ifs and whatnot. Sure, each line is supposed to evaluate to some value, but you still have to write out steps to make a practical program. But remember the roots of emulate. It's a command language for an operating system that got a little too complex. It's still supposed to be used as a command line interface for Emos8. That means, theoretically, that most emulate programs will be a single line long.

To operate MOS 8, a user has to write single-line emulate expressions. You can also write up a longer program, but that's a separate task. In many ways, this is very similar to APL's workspaces or basic interfaces of the time. I point this out because of the whole not quite functional nature of emulate. Expressions return values, so you can chain them like you would in a functional language. That's neat in a very pure sense. It's also useful. If you're writing one-liners and emulate, you can chain expressions.

You can actually command the operating system to do very complex things by chaining commands. If you're a true computer user, then this should ring some bells. That sounds a lot like how you use Unix. You know, my day job. In Unix and Linux, it's very common to take the output of one program and throw that to the input of another. You can build up very complex one-liners by doing this. If it were ever built, then you could use MOS 8 in a very similar way. That's the power of having a little bit of functional DNA in your language.

Again, Wallace is taking ideas from languages, not languages in their entirety. There's the subtlety to it. This is exactly why tracing influence between languages can be so difficult. You will very rarely run into a source that just says, Hello, this is my APL fanfic that I wrote a compiler for. That's not how humans talk. More often, you're left to guess at why a language designer made a choice. What I love about Wallace's papers is that he's so candid.

Let me hit you with just another example. Imulate is supposed to have classes. Well, kind of. In theory, quote, classes are not fully defined yet, but will be a subset of simula classes. End quote.

Yeah, we'll have classes. How will they work? Well, kind of like simula, I guess. Simula here being another very popular language in this period. Jokes aside, though, I think this tells us a lot about Wallace. He's not just some idealistic grad student. He is well-read, well-researched, and conversant with other languages.

Amulate isn't just his design for an ideal language. It's kind of like his review of the best parts of a bunch of different languages. To me, that's really interesting. It's a very period commentary. He liked the memory management of Lisp, some of the functional parts of APL, the syntax of Algole and Pascal and the classes of simula. It's pretty rare to find that kind of language review outside of rigid academic articles.

Reading Wallace from that angle, I can almost feel like I'm having a beer with a colleague and chatting about work. I'm going to close this out by putting this all together and talking a little bit about how this has changed a perspective of mine. We've talked about the operating system, we've talked about the language, but what do we get when they meet? Remember the windowed interface that I talked about?

So get this. The whole point of that setup is to write and edit, emulate code. You type one-liners to execute in the command window. The display window can be used to run a number of programs. Wallace specifically mentions that it's used to run a text editor, you know, for editing your emulate code. Pair that up with the fact that Emos 8 can run emulate programs directly. The interpreter is part of the operating system.

Your tools and modules can be written in emulate itself. Maybe you see where I'm headed with this, but then again, maybe not. Have you ever heard of Temple OS? It's a more recent operating system written by one Terry A. Date. Now, Davis was a bit of a controversial figure. I think I'm just going to leave it at that. I have a soft spot forum because I was on the OS development forums when he was still posting. That was back when his project was called Lus Thos. Terry did something really interesting in Temple OS. It's all written in a custom language,

originally called C++, but later renamed to Holy C. The language is just in time compiled, meaning the code gets compiled right as it's used. That means that you can actually edit the very code of the operating system itself while it's running. The next time that code is called up, your edits are seen, compiled, and executed. That's conviviality. You can literally reshape how the entire system works while it's still running. Everything is stored a source code except a few crucial bindings. everything's open, ready for you to inspect and adapt. It's the ultimate tool for digital expression.

I think if it were ever completed, MOS8 would have been similar to Temple OS in that regard. This isn't just a new phenomenon. There is historical precedence for this idea. In 73, around the time Wallace was at Brown University, Xerox was cooking up a wild machine. It was called the alto and was a fusion of computer, language, and operating system. The most important environment for the alto was called small talk. This environment itself was written in the language small talk. So you could, in real time, modify the code that actually ran all your programs. You could shape the alto to your whims.

That, again, is conviviality. This even shows up in more mundane places, or at least more well-known, and this is what kind of warped my head. Ever heard of Unix? By the time it breached the walls of Bell Labs, Unix is written entirely in C. That's a new custom language developed just for writing Unix and Unix products. It's compiled, so no real-time editing exactly, but Unix shipped as a new custom-language. has source code. It was fully open. Any user had access to every line of Unix's code. That meant you could shape Unix to your will, and many people did. Now, Unix wasn't meant to run on microcomputers.

It was meant for minis that had multiple users. The relationship to power is a little different here. But still, I'd say this is a pretty convivial system. At least, it has a similar type of responsibly limited tool. All this is to say that MOS 8, despite seeming odd at first, does fit on a pretty well-worn path, a path that leads directly into the modern day. We may not be using completely convivial machines in the 21st century, but we can still see parts of that philosophy at play. All right, thus ends our look into MOS8 and emulate.

I will say, I really like these. papers. I know it's not the most impactful piece of computing history, but I really enjoy being able to zero in on such a moment in time. So, whatever happened to Bob Wallace, we started with him, so I think it's only fair to end here. This is where I have to pull back the curtain. When I first started researching this episode, one of my big questions was, who is Bob Wallace? What helped me find more resources on Bob was actually an obituary. Wallace led a truly incredible and wide-reaching life. Months after visiting the West Coast Computer Fair, he was hired by Microsoft. He was employee number nine, but Microsoft wasn't the best fit for Bob. After a few years of work there,

he left to found his own company called Quicksoft, where he essentially created the idea of shareware. You know, software that's freely distributed with the request that if you can, you kick some money back to the author. It's a mode of distribution that shaped the 80s and 90s computer scene. Wallace also had a wild third act. In the 90s, Bob and his wife started a foundation to fund research into psychedelics and to promote harm reduction. The line about Bob, Bob writing early hypertext software on LSD? That's not a throwaway story. That was part of who Bob was.

The obituary I found was on Aeroid.org, a repository of information on drugs, their research, and their responsible use. I know that I say I really like a lot of the people I cover on advent of computing, but that's especially true of Bob Wallace. He was a dreamer in the most pure sense of the world. word. I think we can really see that in microcosm in these very obscure papers on a language and an operating system. It's a small point in time, but it's one that I think really helps us get a feel of the period in 1977. Thanks for listening to Advent of Computing. If you like the show,

go listen to Adjunctive Computing, the official after show. You can help fund the show at patreon.com. You can find links to everything in advent ofcomputing.com, and as always, have a great rest of your day.