What's a condition system and why do you want one?
axisofeval.blogspot.com
axisofeval.blogspot.com
@Total_Meltdown Conditions are just that: conditions. Not necessarily errors or exceptions. Exceptions are a subset of conditions ("exceptional" is a condition). So if X is an error for your application you can unwind the stack if you want to. Or you can try to fix the error in-place without trashing the rest of whatever the program was doing. And yes, conditions allow one to establish protocols between lower and higher levels of code.
The insight of conditions is that the code that detects the error may know ways of dealing with it but only higher level code can know what should actually be done. There are other ways of dealing with this (e.g. passing delegates) but all of them are much more clumsy than this system [2].
[1] http://www.gigamonkeys.com/book/beyond-exception-handling-co...
[2] Passing delegates was mentioned as a means of passing the condition handling code, but the issue is that the code may be 20 layers down the stack. Is every called method going to pass this delegate? Wont they have some failure conditions themselves?
Edit: I realize that Java doesn't have delegates, but I would say that's a point against Java, not a point in favor of this method.
I'm not sure what you mean by delegates, but it sounds like you're saying that you don't need special syntax for conditions when you have first-class functions and simpler control-flow primitives. True, but sugar is nice sometimes; I'd often rather have a list comprehension than a pile of gotos and assignments.
As for sugar, I agree that it's nice sometimes, but I disagree with extending exception handling specifically. Exceptions are for errors, such as sending data over a closed stream, or indexing an array out of bounds. This "condition system" pattern encourages using exceptions for logic flow. Because why pass a function all the way down the call stack when you can just throw an exception to request that data from higher in the call stack, right?
Exceptions are errors, and they should be treated as such in all cases.
This sounds an awful lot like a semantic argument.
If you have resumable exceptions, and can raise an exception deep in the stack to ask higher-stack callers for more information then that's an query.
If you raise an exception in non-exceptional circumstances then that's a scoped announcement.
The mere fact that in some languages they use the same run-time hooks as exceptions is irrelevant.
Exceptions, where I first learned of them in Smalltalk derive from a prototype class that isn't named Exception, and I've seen all manner of uses of the same machinery in stack-twisting.
After all once you have full closures, and full control over your stack and context why shouldn't you use it for higher order abstractions involving the stack-context?
----
in [1], tomp [2] posted:
That's one way to look at it, and it certainly is valid, to some extent.
Another way to look at it is that exceptions are fundamentally limited, and conditions provide a whole new sea of possibilities.
His example is rather awkward and actually confuses the reader, rather than excites. The point of conditions actually is to allow flexibility without all the if statements and delegates. His final getVal() function should look like this Object getVal() { try { if (val == null) throw new NoValException(); else return val; } catch (UseValRestart r) { return r.getVal(); } } and the high-level code should handle how the value is provided (either some specific value, user input, web request, random bits, etc...). So, one only has to write the code for getVal() once and can customize it indefinitely.
----
To me non-lexical scope is quite confusing, especially if you're proposing adding it to a language (eg Java) which is otherwise lexically scoped.
IIRC lexical scope is generally preferred these days by language designers, and Common Lisp is one of the few languages which supports dynamic scope alongside lexical.
Also my2c: I'm not sure dynamic scope it's completely passé these days. In general, it is mostly the idea of "leaving control to the user instead of the used" which has been reappearing in the form of AOP and COP.
In a sense, it is also what monkey patching is about in some OO languages, being enabled by the only surviving dynamic lookup, the "self" one.
http://lambda-the-ultimate.org/node/3166 was my reference though, with at least some seeing the PL design debate as being settled in favour of lexical scope. Although some dissent in the comments there.
I was under the impression that the traditional 'catch' block has the stack unwound for it back to a frame with the same lexical scope as the associated 'try'...
Therefore, the way I understand it, the important bit is not the relationship between a try and a catch, but between the throw and the catch. You could imagine throw as a call of the function last_catch(Exception e), which is dynamically bound by one of the "parent" functions (functions below on the stack).