Re: dispatching on keywords

[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.  For efficiency concerns, I think you're
right.  Some function would be required that would guarantee the type of it's
return value, ergo:

	(read (ensure <stream> (open-file ...

Of course, (curry ensure <stream>) would have to know some way of correcting a
stream error, given only the error value.  This would allow more global error
handling via dispatch on ensure.

It might be more reasonable to have open-file call (ensure <stream> ...)
itself, and provide a lower level hook for people who want to avoid losing
that control.  I would prefer it, though, if open-file did not call ensure,
since this

   (a) leaves me more control.  If I want a version of open-file that calls
       ensure I can code it trivially.
   (b) effectively halves the number of functions that need to be provided in
       the base language.

/// 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))))

PROPOSAL:  If error values are to be included in Dylan, they should be required
to inherit from a special class heterarchy, so that method-dispatch can catch
most cascades, and 'signal' for appropriate correction.  If programmers provide
methods that work with particular errors, then no signal would need to be
made by method-dispatch.  It's probably sheer heresy to suggest that errors
not inherit from <object>, so I would also propose the existance of some base
class like <class-heterarchy-root> from which both <object> and <error> would
inherit.  The name could change, but I think the default class specialization
on a parameter needs to be left at <object> for this scheme to work.

/// I'll spare you the argument about all modern computer languages using
/// except-ions/conditions :-)

Thanks.  I don't want Dylan to turn out like COBOL, FORTRAN (on error),
PL/I or Ada either.  :-)

///      Daniel.

	-- Scot