[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: more srfi-12 rationale?
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 <per@xxxxxxxxxxx> 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 <shriram@xxxxxxxxxxx> 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
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?