[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
- To: Baldwin at YALE
- Subject: Status Returns
- From: Jonathan Rees <Rees at YALE>
- Date: Thu ,24 Jun 82 14:39:00 EDT
- Cc: T-Discussion at YALE
Well, there's already OPEN and MAYBE-OPEN, the first of which errs if
it can't return a valid stream, the second of which is supposed to always
return something without erring. Perhaps the thing to do is to make
MAYBE-OPEN return some sort of status indicator. Right now it probably
just returns () if it doesn't win.
(a) What is a "status indicator"? Is it a symbol? Is it an object which
is the value of some variable?
(b) To what extent can this be made system-independent? I'm sure
that e.g. Unix and VMS have many conditions which correspond to conditions
on the Apollo.
(c) Why is OPEN special? Will it be necessary for every such routine,
e.g. RENAME-FILE or DELETE-FILE, to come in two flavors? What about READC
I would suggest that OPEN really is different, and that it makes sense
for there to be both OPEN and MAYBE-OPEN, because MAYBE-OPEN is so
useful. I'm probably wrong. But having two versions of everything
is clearly wrong. Maybe OPEN should just be defined to return () if
the file wasn't found, and either return () or err if there was some
other problem, and we can eliminate MAYBE-OPEN. I don't know;
having OPEN always return something that answers true to STREAM? is
a nice property to preserve.
I guess I think that status returns are kind of weird. Often you DO
want the system to raise an exceptional condition and handle it in an
"ordinary" way (e.g. print an error message, and either abort, or avoid
proceeding until the problem has been fixed). I agree that the notation
can be quite awkward but I don't think that has to be the case. Not yet
implemented in T are objects called "conditions" and ways to bind
condition-handlers to them. E.g.
(LAMBDA (PATHNAME ERROR-SUBTYPE)
Note that the exception handler is pretty close to the place where you
need it, and you get all that nice lexical environment. You can pretty
easily do a throw to get where you need to go.
Compare this with
(LET ((PROBE (MAYBE-OPEN PATHNAME)))
(COND ((NULL? PROBE)...)
((EQ? PROBE FILE-IS-LOCKED) ...)
((STREAM? PROBE) ...)))
I don't know. The second may be more concise, but I'm not sure
it's cleaner, and I'm not sure you want to bother checking to make sure
you won on EVERY system-interface call. This could be pretty tedious
with things like READC (you already need to check for *EOF*).
Kent worked on this last summer; I'll provide more details on proposed
syntax and features for conditions in the future. In any case it's not
implemented yet. For now you might want to use Nat's DEFINE-APOLLO
stuff directly; talk with him.