dispatching on keywords

[birkholz@crl.dec.com]

   Date: Tue, 17 Nov 92 09:17:47 PST
   From: dyer@eagle.sharebase.com (Scot Dyer)

   /// I'm not sure error values are such a good idea, even in a functional
   /// language.  Expanding on your example, consider:
   /// 
   ///    (read (open-file ...
   /// 
   /// With error values, read can get a stream argument or an error value,
   /// and so must check at run time.  With non-local exits and conditions,
   /// you can assert that open-file returns a stream, and the compiler will
   /// optimize type checking. Or alternatively, you can write your own
   /// open-file-or-return-error-value, which makes conditions more powerful
   /// than error values.

   It is correct that un-anticipated exception values will 'cascade'
   in this kind of a scheme.  This is handy in that it produces a
   back-trace which it is simple to build a browser to view.

It is _not_ handy in that it produces something that could be _mistaken_
for a backtrace.  Why throw away the stack in order to generate something
that looks like the stack but from which you can't continue?

   /// Another common argument against error values is that usually, you don't
   /// know locally what to do about the error. You miss the larger picture,
   /// and it's better to exit to a higher-level function that will have a
   /// better idea about what to do.

   This is a good argument.  Sometimes one wants errors handled transparently,
   I'll admit to that, but having that be the _only_ way can make life harder
   when you just want to define a simple function like

	   (define-method file-exists? (file-name)
		   (not (error? (open-file file-name))))

This is a situation where the context of an error happens to be
unimportant.  I don't think it justifies throwing away potentially relevant
information (i.e. pop the stack) by default, for errors you weren't
expecting -- errors for which any relevant information may be crucial.  It
_should_ take a few more keystrokes to abandon the error context in this
situation.

Matt Birkholz						Cambridge Research Lab
birkholz@crl.dec.com		<DARWIN><		Digital Equipment Corp.