gyro@cymbal.reasoning.COM (Scott Layson Burson) (04/30/91)
Date: 27 Apr 91 18:15:28 GMT
From: Pete Harlan <harlan@copper.ucs.indiana.edu>
Returning an error is conceptually simpler, I think. I'd personally
like to see the routine take a success and failure continuation, but
the world seems to not want primitive Scheme procedures to take
continuations.
I am absolutely in agreement with Chris that dynamically bound
exceptions, a la Common Lisp or any of several other languages, are a
superior method of error handling than returning error values. I've
written large systems in both styles, and to me, the difference is
beyond argument. Chris summarizes the reasons for this very well, and I
have nothing to add.
However, I also agree with Pete here that passing explicit failure
continuations (the success continuation should surely be the implicit
one) would be more Scheme-ish than either of those two approaches, i.e.,
maybe a little avant garde, maybe no one yet knows what it would really
be like to program in that style, but aren't Schemers just the kind of
people who would want to find out?
At this juncture, seems to me, we could make the following change to the
language: for each builtin function, define another version of it with a
funny-looking name ("%CAR" or whatever) that takes explicit continuation
arguments for each of its various failure cases. Then specify that
implementations shall provide at least one variable, perhaps *DEBUGGER*,
whose value may be passed for any such continuation argument to cause
the failure action to be whatever the implementation does by default in
that case. So the implementation is required to behave as if it
contained the following definition:
(define (car x) (%car x *debugger*))
There would be a lot of work to do to define what all the various
failure continuations are and what arguments they should take (and are
they allowed to be just functions rather than continuations so that they
return to the error context, and so on), but it seems to me this would
be work well worth doing (and that it would largely overlap the work
that would be required to define all the conditions that might be
signalled etc., were we to take that approach).
-- Scott
Gyro@Reasoning.COM