🚀 go-pugleaf

From: Daniel L. Weinreb <dlw at MIT-AI>
Peter Deutsch is completely correct about the Lisp Machine.
Local naming is done with virtual addresses, which are
meaningful throughout a single Lisp Machine and only within
that machine.  Files are handled in the traditional way (like
Unix, not like Multics): you read and write them in a stream-
oriented way.  A Lisp Machine file system can be local or
remote, but in either case it acts the same way: the file
system is completely divorced from the Lisp World.  To edit
a file you read it in, making a copy (in a different format)
inside the Lisp World.  While you are editing the file, it is
represented in terms of Lisp data structure (a linked list of
structures representing text lines, plus other stuff, as it
happens).

Users never really deal with the virtual addresses in a numeric
way, of course.  All permanent storage is in the file system;
Lisp objects all vanish when the machine is "cold booted", and
there is no attempt whatsoever to preserve the integruity of
Lisp objects across various system failures.  I am not saying
that this is the way all systems should be (it probably isn't),
but that's how the Lisp Machine works now.  It solves a lot of
problems (integruity, sharing, allocation, checkpointing) in
ways that are narrow and restricted but well-understood and
simple.

And, by the way, capabilities are NOT just pointers.  By
"capability", most people mean a name for an object on
which there is a strictly limited set of allowed operations,
controlled by a set of access control rules that are very
powerful and allow advanced access control structures such
as protected subsystems.  Lisp does NOT have this, and
Hydra does, and that is one of the main things Hydra is
about.

I am told by people I respect that both the System 38 and
the Honeywell NSA have botched the basic principles of how
to do a capability system.  I do not know the details; I'm
just passing on rumors.

I was one of the architects of the Amber operating system for
the LLL S-1 computer, which also has capabilities, in its own
way.  I think we followed a lot of the basic principles well,
but our capabilities are very different from Hydra's in the
way they fit into the system.  They do serve as the basic
naming facility for the kernel interface, and they do have
powerful access control facilities, allowing protected
subsystems.  Amber doesn't have garbage collection but we
don't think this is an important problem.  Basic memory
management/file access in Amber is most similar to Multics. 
In Amber, you acquire a capability to a segment, and then
you initiate the segment, which causes it to appear in your
address space.  (The S-1 is a large-scale computer being
developed at Livermore Labs.  Amber has been almost all
designed, and lots of it has been coded and tested.  Jeff
Broughton was the inventor of the current capability scheme
and is in charge of Amber development.)