Meaning of PROBE-FILE for direction output

[Jon White <JLW@SU-AI.ARPA>]

There are a couple of problems with using a non-OPENing probe for
output files, which caused the Intelisp-D development group to want
to flush the equivalent [outfilep].  One problem is the obvious one that
when the result is non-null, it can be a guarantee only for a short
interval of time [I'm assuming that even personal workstations will be
having access to shared file servers] that such a file name may be
opened for writing by the caller -- because someone else may sneak in
and open up exactly the file you want.   Another problem stems from a
possible discrepancy between the pathname completion done by the file
system when actually OPENing and when merely probing (without opening)

On the other hand, it appears as though some persons may feel as Paul
does, that using an "error" trap to do normal programming is bad practice.
A reasonable way out of this dilemma is simply to stop calling such signals
"errors", and admit signals as a first class mechanism.  Xerox's Mesa language
has an admirable signalling mechanism, although a little too baroque for
my taste.  The interface definition of any function then requires
a description of the types of input argments, the types of output values
(multple values) and an enumeration of any signals raised.

In pdp10 MacLisp days, all "signals" were raised via calling ERRORs; the
lossage with that approach is the too-limited bandwith of a single signal
(the ERROR signal).

So the "signal" approach would require the client program to actually do an OPEN
and to check for signals as well as the return value; there are numerous ways
to insure that an abort after the actual open will cause a close, but I
wonder what purpose would be served by providing a probe-file for output
operation if th client didn't actually open the file sooner or later anyhow.

-- JonL --