lispm

The FOSS clone was called CMUCL. There was no Lisp Operating System for "normal" hardware at all (proprietary or not), this was the next best thing. For a good Lisp-based development system one also does not need to make it an "operating system".

CMUCL was basically licensed as public domain. It was based on the stripped down version of Lisp Machine Lisp, called Common Lisp and it ran on UNIX systems. It came with its own IDE built around an EMACS clone called Hemlock.

  (let ((a 10) (b 20) c)
    (declare (type (integer 0 *) a b c))
    (setf c (* a b))
    c)

Above is a LET expression, a variant of a lambda application.

It does not look like a function call. It looks like an operator list form, with LET as the operator. The next element is not a function call or similar, but a binding list with three variable definitions, two of them having an init value. Next to the binding list is a declaration form, with a type declaration for the local variables. Then a sequence of forms, a body, which is evaluated top down and the last value ist returned. There is a setf form, for setting a variable. The variable in the setf form is not evaluated, it will be set to the value of the second argument.

Neither LET, DECLARE, TYPE, INTEGER, or SETF are functions. They have different syntax and/or semantics from function calls.

Thus we have:

* special control flow

* a LET syntax which is not looking like a function call

* a lexical scope created by LET

* a type declaration with special syntax

* special evaluation rules, unlike evaluation of a function form

A Lisp user will need to learn that IF, WHEN, AND, ... and a lot of other operators are not functions....

> By contrast in a lisp the syntax for setting a variable looks the same as the syntax for looping and for everything else. It's all just function calls.

Not really.

Setting a variable in Lisp is not a function call. IF is also not a function call. Defining a function is also not a function call. Loop operations like DO, DOLIST, DOTIMES, ... are also not function calls. Lots of things are not function calls. Macro forms are also not function calls.

Strange, the Lisp example has a lot of syntax, even though the article claims it hasn't.

letrec, lambda, or & and are not functions in Scheme.

The UK has argued for the Brexit with red tape removal, in practice this meant less protection.

Standards are useful. To be outside a large population area of standardization and regulation only means, that nobody cares about your small-country standards and that the population gets the worst of both worlds: inferior local standards and very little influence in international standards.

The British voted for Brexit to enjoy poorer standards.

https://www.theguardian.com/environment/article/2024/may/09/...

Good luck with removing "red tape".

If you only look at the price, then you don't get the full picture.

> Common Lisp doesn't come with the ability to tap into the JVM

ABCL -> https://abcl.org

The Java interface for LispWorks : https://www.lispworks.com/documentation/lw80/lw/lw-java-ug.h...

I don't think that Emacs Lisp needs to be a "full Lisp", whatever that would be, but it would need, for example, some improvements in the structuring of large programs, since there is now a lot, and still growing, amount of code written in it. Namespaces/modules and threading would be examples for improvements.

Emacs Lisp's language design was originally designed on Maclisp. Maclisp is long dead, but other descendants of Maclisp have been standardized (like Common Lisp and ISLisp). Emacs Lisp has been improved over the years (just two examples: lexical binding and native compilation), but there would be more to do at the base language. It's the task of the users and maintainers to do so and they have their own preferences.

Obviously you are wrong, since it has been already demonstrated that it's not useless, as already the GNU Emacs example shows. It comes with a lot useful and well written software -> in Emacs Lisp -> roughly 1.5 million lines of code.

Where does the DEFCLASS stuff originally come from? Is it documented somewhere? As I understand it is from before Flavors? Flavors then replaced it or is there some deeper relationship?

One of the downsides is that implementations like SBCL have a deep integration and need things like a well performing GC implementation - to get this running on specialized game hardware is challenging. The article describes that. Getting over the hurdle of the low-level integration is difficult. The reward comes, when one gets to the point, where the rapid incremental development cycles of Common Lisp, even with connected devices, kicks in.

For the old historic Naughty Dog use case, it was a development system written in Common Lisp on an SGI and a C++ runtime with low-level Scheme code on the Playstation.

> Common Lisp also appears to be a much faster language than I would have blindly assumed.

There are two modes:

1) fast optimized code which allows for some low-level stuff to stay with Common Lisp

2) unoptimized, but natively compiled code, which enables safe (-> the runtime does not crash) interactive and incremental development -> this mode is where much of the software can run nowadays and which is still "fast enough" for many use cases

> except by most dialects of LISP, which typically use a hyphen character in identifiers and they do not use a minus character, except for the sign of numbers.

In Common Lisp, there is one character SP10 for Hyphen and Minus: https://www.lispworks.com/documentation/HyperSpec/Body/02_ac...

It is used

* in numbers as a sign -> -42

* in a conditional read macro as a minus operator -> #-ARM64(error "This is no 64bit ARM platform")

* in functions as a numeric minus operator -> (- 100 2/3) or (1- 100)

* as a global variable for the currently evaluated REPL expression -> -

* as a hyphen for symbols (incl. identifiers) -> UPDATE-INSTANCE-FOR-DIFFERENT-CLASS

Check the resume of Ken Kahn: http://toontalk.com/resume.pdf

Director Guide: https://dspace.mit.edu/bitstream/handle/1721.1/6302/AIM-482b...

Creation of Computer Animation from Story Descriptions: https://dspace.mit.edu/bitstream/handle/1721.1/16012/0720063...

The other mentioned tool was Thinglab, by Alan Borning

https://www.ijcai.org/Proceedings/77-1/Papers/085.pdf

"The Smalltalk notion of an object has been modified and extended in a number of ways. In ThingLab, objects are constructed interactively by editing and making descendants of prototypes. An abstraction hierarchy is used that allows arbitrarily many levels of both parents and descendants, with the problem of objects with several parents being handled by the technique of merging. There is no distinction between classes and instances."

"The Programming Language Aspects of ThingLab, a Constraint-Oriented Simulation Laboratory" https://dl.acm.org/doi/pdf/10.1145/357146.357147

"CLASSES VERSUS PROTOTYPES IN OBJECT-ORIENTED LANGUAGES" https://dl.acm.org/doi/pdf/10.5555/324493.324538

Available in the Browser, running in Smalltalk: https://constraints.cs.washington.edu/thinglab/

They already used PASCAL for the Lisa as its systems programming language. Most of its software at that point was written in Lisa Pascal. Apple worked with Wirth on adding/improving object-oriented programming constructs. Clascal was an extension to an already widely used Lisa Pascal and was used for an OOP framework: http://pascal.hansotten.com/apple-lisa-pascal/

I don't think there was ever a move to use Smalltalk in Apple Products, anyway. Besides a pre-product version of Apple Smalltalk 80 itself, which was available for a short time.

Eventually also PASCAL (using BEGIN/END) lost at Apple against the curly braces in C/C++/Objective C/Java/JavaScript/Swift.

> my favorite Macs are user-serviceable

Actually that ship has sailed. The M1 MacBook Air was a big step up on any prior "user serviceable" Mac. It's portable, fast, extremely efficient, light-weight, robust and totally silent. Upgrading RAM has mostly been a non-issue. The Symbolics Genera emulator on the M1 runs roughly 80 times faster than my hardware Symbolics board in my Mac IIfx. That hardware was fragile and expensive. I'm much happier now, given that this stuff runs much better.

> i don't think it's entirely accurate to describe it as 'a pascal machine'

yes

it would only be accurate, when one looks at BOTH the CPU and the microcode. The Xerox Interlisp-D machine was a Lisp Machine with the specific microcode. It was a Smalltalk machine and a Mesa machine - each with their microcode.

The original MIT Lisp machine was also microcoded, though I don't know other Microcode than the one for Lisp. The early Symbolics Lisp Machines were also microcoded, but again only for the Lisp OS, with the microcode evolving over time to support features of Common Lisp, Prolog and CLOS.

There were complaints that the Microcode on the Lisp Machines was very complex, which contributed to the death of the machines. For example here is an interview with Keith Diefendorff, who was also architect for the TI Explorer Lisp Machine. In his interview he talks about the Explorer Project and the Microcode topic: https://www.youtube.com/watch?v=9la7398ruXQ

Definitely. Interlisp and Smalltalk were early on mostly driven by research (Interlisp -> everything AI, Smalltalk -> UI research, OOP, AI) and specific early applications. The Mac UI was early on more direct manipulation oriented.

One thing to keep in mind: the UI state of the Art was fast evolving and applications under some of these systems might have UIs different from the underlying operating system. That would also be true on the Mac: HyperCard had a look&feel very different from the underlying Mac OS.

For example Xerox developed "The Analyst" in Smalltalk 80 for the CIA: http://www.bitsavers.org/pdf/xerox/xsis/XSIS_Smalltalk_Produ...

I would think that NoteCards (written by Xerox in Interlisp-D) had similar customers and that there might also be some joint UI influence.

Probably. They may have seen such a machine. But both the LISA and the Mac were very different from UI, Software and Hardware. Steve Jobs vision was eventually to get to the Dynabook (-> MacBook, iPad). LISA and the early Mac were stepping stones...

But the Xerox PARC -> Apple route is broad and is well documented. Steve Jobs got a demo of the secret Xerox stuff in exchange of some Apple stock, including the Smalltalk system (though the Smalltalk team were less then happy about it). He hired Larry Tesler. Apple was also one of the selected companies getting Smalltalk-80 access and ported it to their machines (later the Apple sources were open sourced). Steve was also interested in the office domain, desktop publishing was one of the first applications of the Mac (incl. Postscript, the Laserwriter, Adobe Pagemaker, ...).

> i do think they made noticeably (and fascinatingly) different choices not only in what they designed for their user interfaces but also what they thought of as a good user interface

Though software written originally for the Xerox Interlisp systems got ported to the MIT Lisp Machine descendants, since the hardware was more capable with more memory. For example Intellicorp KEE (Knowledge Engineering Environment) was ported. It retained much of its original UI (which included extensive graphics features and an interface builder), when running on Symbolics Genera. It looks like one is using an Xerox Interlisp UI when running it on a Symbolics. https://vimeo.com/909417132 For example at 08:30 the screen looks like an Interlisp system, even though it is Symbolics Genera.

Xerox PARC also had real MIT CADRs in their network. I remember seeing a photo, with an office, where the Xerox PARC employee had both an Interlisp workstation and (IIRC) a Symbolics. There is also a video for the IJCAI 81 (International Joint Conference on Artificial Intelligence), with demos of an Interlisp system and a MIT Lisp Machine, both demos recorded at Xerox PARC.

And all that is independent of the PERQ.

The article states (and it makes sense) that the PERQ had influence on the modern Mac, the Macs running Mac OS X and later. Since NeXT and then Apple used UNIX on a Mach Kernel, the latter came as a direct influence from CMU.

Influence on the LISA or the early Mac (before Mac OS X)? Not so much..., those were influenced directly from Xerox PARC ideas, people and technology.

Related to PERQ: The SPICE project from CMU, using PERQs, was also developing SPICE Lisp, which was influenced by the LISP stuff from MIT, including an EMACS variant, influenced by the ZWEI editor from the Lisp Machine. SPICE Lisp from the PERQ, evolved into CMU CL and later SBCL.

Like the PERQ is largely unrelated to the Smalltalk / Interlisp-D systems from Xerox, to LISA or the early Mac. It is somewhat related to the later NeXT (founded 1985, first release in 1988) -> Mach/Unix, ...

The PERQ was just in the timeline between the Alto and the LISA/Mac. But there isn't much of a relationship to the latter two and not much to the Alto. The Alto was used to write stuff like its OS in BCPL, the Office software written in Mesa, Smalltalk, Interlisp, ... but AFAIK no UNIX and no PASCAL system. The PERQ did not run Alto-Software.

Background information about the PERQ history: http://bitsavers.informatik.uni-stuttgart.de/pdf/perq/RD_Dav...

They were among the first graphical workstations: Large bitmap screen, disks, network, color option, mouse, window system, object-oriented software, fonts, gui framework, ...

Before the Apple Lisa, the SUN-1, the Mac, ...

These are Lisp Machine images/screen shots from MIT from 1980:

https://bitsavers.org/pdf/symbolics/LM-2/LM_Screen_Shots_Jun...

* a dual screen machine with a electronics design system

* Macsyma with plots

* Inspector, Window Debugger, Font Editor

* Music notation

* first tiled screen/window manager

* another electronic CAD tool

The UI was developed using Flavors, the object-oriented system for the Lisp Machine (message passing, classes&objects, multiple inheritance, mixins, ...).

Note also that Spice Lisp for The PERQ was also used to implement Hemlock, an EMACS editor.

http://www.bitsavers.org/pdf/perq/accent_S5/Accent_UsersManu...

Lisp Machines from LMI and Symbolics, too.

> Prototype-based OOP came first in SELF

Isn't prototype-based OOP roughly a decade older? -> for example "Director" from Ken Kahn is from 1976.

The built-in editor. With LispWorks I don't use GNU Emacs. I have GNU Emacs configured, so that I could use it, but I don't... I use SLIME with SBCL, but mostly because of SBCL, which is a great implementation.

I'm faster and more in the flow with the LispWorks IDE.

> You singled out SLIME

Especially the REPL of SLIME / GNU Emacs.

LispWorks provides a better REPL experience.

> Typically when using repls outside of lisps, you'd type your code into the actual repl window, while in lisp-land you typically connect your editor to the repl and program like usual, selecting stuff to evaluate and so on.

I think that's neither typical in the history of Lisp nor in other languages. For example in Mathematica and Jupyter one interacts via a Notebook interface. Smalltalk interacts via an integrated IDE. Many editors connect via LSP to language servers.

In Lisp the idea of an editor connecting to a Lisp is a bit of a historic accident. After the AI winter the Lisp development environments were no longer used.

A typical way to start Lisp from an external editor was via the editor starting a subprocess (the "inferior Lisp") and talking to it. GNU Emacs did that with IDEs for Lisp, like ILISP.

The next generation used GNU Emacs as its external development environment (instead of developing a new one in Lisp) via a network interface. SLIME was the most important one, with SWANK being the component loaded into the external Lisp, which provided a server interface.

Unfortunately the SLIME REPL itself (its read eval print loop) is not great (in general SLIME is okay to use) and other languages sadly copied the SLIME model, failing to copy various other important REPL features of Lisp. For example Clojure lacked the error handling of Lisp REPLs, which typically provide features like break loops, where one can inspect and repair errors. SLIME goes directly into a backtrace window. Thus people copied it, without knowing that there is a tradition of completely different REPL interaction. GNU Emacs is bad at multitasking, thus one REPL buffer could block the editor for a while -> multiple REPL windows were not that useful. Another way of working got lost...

Lisp and Haskell are programming languages. Lambda Calculus not.