[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: more srfi-12 rationale?

This page is part of the web mail archives of SRFI 12 from before July 7th, 2015. The new archives for SRFI 12 contain all messages, not just those from before July 7th, 2015.

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?