Inits opening stuff

[Richard L. Bryan <RLB at MIT-MC>]

    Date: 27 February 1980 08:23-EST
    From: Brian G. Schunck <BGS at MIT-AI>
    ...
    That's okay for init files, but what about general loads?
    The problem yesterday was caused by a user doing
      (LOAD '((DSK FOO) JUNK DATA))
    several times until he got his small, trivial file of test
    data setup correctly for his application.  The LOAD never
    did a CLOSE after reading in the file, and the computation
    never got anywhere close to doing a GC, which would have
    forced closing. ...

It seems clear that LOAD should have no use for its channel after it exits.
Error breaks, *RSET traps, etc., due to the LOAD should have INFILE available,
but that's all still within the context of the LOAD.  Hence, the LOAD 
internals should be "in" an UNWIND-PROTECT-like "construct" to make sure
LOAD's channel got closed.  See KMP's IOTA.
   If the luser insists on reLOADing from inside his error breaks, there's
little that can be done about it, but in the common (^G) case, this would
fix it.
   An alternative, but harder to implement, way would be for gc to treat a
"space" of I/O channels sort of the way it treats list space, etc., with
respect to gcmin/gcmax.  If no ALLOC for IOCHAN space were done to increase
the number of chans avbl past an initial default (3 tty + 2 dsk?) then 
GC-OVERFLOW would run on IOCHAN space ...