Cleaning out the "deadwood" in the Lisp code

[masinter]

The software has a lot of "deadwood": things that were put there to accommodate some situation that is no longer there.
@waywardmonkeys has been leading the careful cleaning of the C code for Maiko.

But I think we need a similar effort for the Lisp code. This discussion topic is to start the planning for how to proceed.
Here are (in no particular order) some things that need cleaning:

• The code for FONTSAVAILABLE and FONTCREATE
• The DSK handler (emulating case insensitive, TENEX compatible file versioning
• Most of the network code
• The loadup process,
• Anything that uses \MACHINETYPE as a variable
• All the functions (Re)defined by a MOVD (MAIKO.MOVDs)
• All the code for handling virtual memory (the paging management was in Lisp)

What to do about the documentation of how things were.
*

[masinter]

I have been playing in a system where I loaded all of full.sysout's source code
(FOR X IN SYSFILES DO (LOAD X 'PROP))
and then

. ANALYZE ANY ON ANY IN SYSFILES

and fixing (or working around) problems as they arise.
Latest problem is the STREAM datatype declaration

[nbriggs]

Cool. The STREAM datatype is shared between the Lisp code and the C code, I think. There are actually a number of datatypes (including STREAM) where the C code accesses things directly from the Lisp datatype. The implication of which is that if the Lisp structure changes the C structure must be fixed to stay in sync, and there are at least two variants -- big and little endian (on the C side)