While I don't think I'm getting my planner software into chaosnet
today (in some TZ) I would like to share a little I have learned
about historical lisp documentation.

In my quest to get rolling with chaosnet, I opened the chinual 4e
in links2 as normal

(available at

https://tumbleweed.nu/r/lm-3/uv/chinual4th.html

)

And did some /chaosnet<ret><ret><ret>

Without stumbling on a chaosnet walkthrough yet, I got caught up
reading the description of how lisp's INTERN had been extended
relating to nested namespaces in the lispm.

I've kind of taken for granted that common lisp 2e is the way it
is based on careful thought, argument and compromise but I think
taking this for granted is basically a mistake. So even if your
focus is packaging ready deployment focused unix applications,
knowing both what at an implementation level INTERN is doing and
why, and the define-package evolution both demystifies rituals
and lets us learn from and about our peers (through history no
less).

The lispm hardware was made to receive patches, which is why
after fossil cloning the MIT-CADR and ./m -s ing it, the first
thing to do is ask it to patch itself into a new band and change
to that band.

This is why even in the context of the lispm, the chinual 4e is
a historical document. ams pointed me to following the ~mailing
list through time:

https://tumbleweed.nu/lm-3/history.html

and follow release notes and discussions between Greenblatt and
RMS and everyone as new functionalities were released or made
experimentally, or deprecated/removed. Such as the introduction
of #'INTERSECTION, #'SET-DIFFERENCE and many CL functions taken
for granted today.

This is also true for interlisp's cache of history relevant to
its interlisp-medley revival. I had found interlisp difficult
to fathom, since while it was clearly different to something,
what it was different to was clearly different to unix.

So it is hard to understand interlisp without being familiar
with the maclisp..lispm tradition, which is the thing interlisp
being less mainstream in some sense, had the capacity to be
different to (= better than).

My broken metaphor: Imagine the lispm as gentoo and interlisp
as funtoo, but instead of gentoo reabsorbing funtoo's tech
changes, the lispm and d machines continued to diverge,
eventually becoming the FPGA OS / portable virtual machine
MIT-CADR, and the interlisp medley portable maiko virtual
machine / javascript interlisp virtual machine.

It would be hard to understand how and why funtoo people are
different to gentoo without understanding how they both came
to be the way they are and why. Though as I said, interlisp
and lispm lisp continued wildly diverging rather than having
a technological reconciliation as gentoo and funtoo did (I
believe.).

*One way interlisp and zetalisp's divergence continued was
that with the lispm involvement developing common lisp 1e,
basically zetalisp extended itself towards the common lisp
standard, resulting in them seeming almost exactly the same
out of the box, but interlisp worked like this:

Well, EXECs (interlisp processes/repl windows/programs) now
can be opened as interlisp EXECs with the interlisp idioms,
or XCL common lisp EXECs as a watery native portability for
other lisp traditions' programs.

This meant that interlisp focused its novelty into the bits
that differentiated interlisp EXECs from XCL EXECs. So while
the lispm and common lisp focused on common core mechanics,
interlisp focused on conversational lisp and DWIM customise-
able advanced after-READ processing, and making its graphics
idioms fundamental to its lisp and community packages.

As Simon Brooke (on the mastodon, or web) pointed out, the
result was that Genera (a commercial fork of the lispm OS)
looks dated, and you can't legally get it anyway, interlisp
looks somewhere between bleeding edge and avante garde. Its
problem that seeing high level (performance costly) features
as intrinsic to the complete programming system meant slow
performance aged into a priceless vintage as microcomputer
performance caught up.

In contrast the low spec and everything-you-need nature of
the MIT-CADR make it a drop-in and familiar replacement for
Common Lisp, Emacs, Tmux, ... libtk, whatever in ways that
its fundamental fundamentals nature leaves accessible to us
downstream of its development.

Further, the MIT-CADR's low spec requirements and design
choices mean that MIT-CADR on FPGAs (+ VGA, + PS/2s, +
ethernet) are an emerging candidate for just replacing the
apparently inescapable handful of CPU vendors.

tl;dr

Complete conversational, DWIMified, graphics-fundamental
programming system,
with javascript or C unix VM:
interlisp medley

Drop-in common lisp (mostly) development with integrated
familiar emacs, without having MIT hacker labs innovations
washed out by worse-is-better,
with self-contained FPGA or C VM:
MIT-CADR lispm.