[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: New Lisp ?
- To: address@hidden
- Subject: Re: New Lisp ?
- From: address@hidden (Rob Warnock)
- Date: Wed, 2 Jan 2002 22:15:01 -0500 (EST)
- Followup-to: comp.lang.scheme,comp.lang.lisp,comp.lang.functional,comp.lang.dylan
- Organization: Silicon Graphics Inc., Mountain View, CA
- References: <c571739c.0112211614.24569c07@posting.google.com> <l91d2ucqplfm9auo2gi20pd74ktnl2utlp@4ax.com> <ni8f2uck3ua78ucps9kg9c4sal2g38r85v@4ax.com <okfpu4tq8z7.fsf@bellsouth.net>
- Reply-to: address@hidden
- Xref: traf.lcs.mit.edu comp.lang.scheme:38524 comp.lang.lisp:78627 comp.lang.functional:29755 comp.lang.dylan:13918
David Rush <kumo@bellsouth.net> wrote:
+---------------
| Please note: I am talking about a matter of degree here. My biggest
| beef with exception-based systems is that they end up getting used far
| too generally (for unusual code paths rather than actual failure
| handling).
+---------------
At least as I read it, Kent Pitman's 1990 survey paper on exceptions
<URL:http://world.std.com/~pitman/Papers/Exceptional-Situations-1990.html>
suggests that there's nothing wrong with using exceptions for "unusual
code paths":
It is important to recognize that this distinction between normal
and exceptional situations is in some sense contrived. Making this
distinction does not change the way programs behave; it simply
changes the way we reason about programs--hopefully for the better.
...
In some cases, there may be efficiency reasons for considering
some cases to be exceptional.
In particular, allowing some [presumably infrequent] non-error code
paths to be considered "exceptional" [and using inconspicuous flow
control primitives to access them, such as CATCH/THROW] can, in turn,
allow the "normal" code paths to be considerably simplified without
compromising program correctness.
-Rob
-----
Rob Warnock, 30-3-510 <rpw3@sgi.com>
SGI Network Engineering <http://www.meer.net/~rpw3/>
1600 Amphitheatre Pkwy. Phone: 650-933-1673
Mountain View, CA 94043 PP-ASEL-IA
[Note: aaanalyst@sgi.com and zedwatch@sgi.com aren't for humans ]