[no subject]

[JLK@MIT-MC]

CC: (BUG lispm) at MIT-AI
I raised this issue before you came back in the LISPM mail, but since you are
thinking about documentation, I thought I would bring it up again.  We have
been completely screwed several times by less-experienced users calling OPEN
without an unwind protect.  This has, on occassion, caused MC to grind to a
complete halt when a user debugging a program on a LISPM that OPEN's a file
gets an error and he(she, actually) does this numerous times, tying up all the
disk channels on MC.  It is my assertion that OPEN should be considered a sub-primitive
only to be used by people that know what they are doing, and the standard file
primitive should be something like IOTA (I don't like that name, but just refer
to the functionality) since that is what you want 99% of the time.  Now the
options for implementing this point of view range from moderate (just documenting
things this way in the manual with warnings, etc.) to radical (renaming OPEN to %OPEN,
breaking lots of code, etc.).   At the very least the LISPM should have a standard
primitive like IOTA (implemented as a macro) which people should be encouraged
to use.  I have mentioned this to HIC a while back, and he concurs with the general
point.  Any ideas?

(Note, this was never much of a problem in Maclisp, although the issue occurs there
too, because the lifetime of LISP environments is much shorter than that on the
LISPM, and it is hard to create infinite channels -- a given job can only hack
about 12. disk channels before they get recycled.  The LISPM simply creates as
many file jobs as needed to get it the number of channels requested.  As another
point, some safeguards should be put in various places to prevent so many channels,
buffers, or whatever it is that is limited in the "file computers", but that
doesn't solve the main problem.  More frequent GC's in Maclisp also helps reclaim
file objects.)