FLAME warning: Scheme broken on OZ today.

[GJC at MIT-MC]

You would patch Maclisp without knowing who was doing maintenance and
where the canonical sources are? Sigh...

As of now there is no Local Maclisp maintenance, and no canonical sources.
When OZ came up I was to install Maclisp here from sources on MC and XX,
but instead MARTY cleverly arranged for people outside of MIT and the LAB to
"help him out" thereby contributing to the present inconsistent mess.
However, things seemed to run anyway, so it wasn't worth hassling, considering
the amount of other work to do on other projects.

On the other hand, when I try to run SCHEME on OZ to verify examples run
in other implementations (in this case on the VAX), I don't like to end up
spending lots of time hassling MACLISP and lack of DISK SPACE on OZ.
(Who ?designed? the present disk-structure settup here anyway?
 With all those RP06's, why are we losing? Doesn't anybody GFR?)

If you have problems with Maclisp on TOPS-20, first try to get around
them by loading LISP-LEVEL stuff, and dumping out your own version using SHARE.
The mere fact that you had INTERLOCK problems with trying to patch LISP.EXE
should have told you that somebody was depending on it.

The present problem is just that the most experienced Maclisp user/implementor
people here at the labs don't find it worthwhile to fix maclisp bugs in
the MIDAS sources. Mainly because they are responsible for or depend on
stable large systems in the present versions of Maclisp, and because they 
have new implementations of lisp systems to work on.

To push forward the maclisp world for the sake of small changes is 
conterproductive, as a small time spent by inexperienced hackers
can force the spending of considerable time by experienced hackers.
This is a very expensive form of MAKE-WORK. (Real $$$ expensive too.)

-GJC

p.s. In other words. Cool it for a while in the Maclisp directory.
After the Thanksgiving break you can talk with GSB, myself, and others
about what changes are really needed.