[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: dispatching on keywords
- To: firstname.lastname@example.org, email@example.com, firstname.lastname@example.org, ranson@LANNION.cnet.fr
- Subject: Re: dispatching on keywords
- From: email@example.com (Scot Dyer)
- Date: Tue, 17 Nov 92 09:17:47 PST
- Cc: firstname.lastname@example.org
/// 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,
(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. :-)