Is the definition of ABORT supposed to be recursive?  The semantics of
that are very unclear.  Shouldn't it be unrolling exception handlers?

>>>>> On 15 Oct 1999 18:52:25 -0700, Per Bothner <xxxxxx@bothner.com> said:

> To my:
>> * Why do we need a new condition type, disjoint from other Scheme
>> values, with 5 new operations, some of which are quite non-trivial?
>>[...]
> Shriram Krishnamurthi <xxxxxx@cs.rice.edu> responded:
>> All of this is also true of continuations.

I'm 100% with Per on this one.  The exception stuff all looks very
nice.  But the condition stuff seems completely arbitrary and
unnecessary.

I really don't understand Shriram's comment either.  Unless I'm being
particularly slow today, I don't think there are 5 procedures and 1
new data type associated with continuations - by my count there's 1
procedure and 0 new data types... so I don't see how the antecedent of
``all of this'' can be construed to be true of continuations.

As far as I can see the only purpose of the conditions is to hide
implementation for built-in exceptions.  This seems like a rather
heavy-handed approach to solve a pretty light-weight problem.

Are conditions eq? or equal? ?  It seems to be unnecessarily
complicated to see if an exception is the one you were expecting.
It's so much more convenient if you simply use a normal scheme value
(most likely a symbol).  Interestingly, the examples for
HANDLE-EXCEPTIONS (quite rightly) use simple scheme values rather than
making condition values.  If this was done for pedagogical reasons
(because it was simpler to explain), doesn't that make a compelling
reason for using them in programs too?

../Dave