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 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