This reductionist philosophy is mostly inappropriate when talking about programming language features.
Yes, from what I understand about Conditions (IANACL), they can be implemented with first class functions and dynamic variables. And dynamic variables can be implemented by passing an extra argument to every function. And function arguments can be implemented with well-named global variables. And functions can be implemented with computed gotos and a reified global stack variable.
But the point of a language is to create a common vocabulary with which programmers can think and talk to machines and each other. Try to reduce everything to a simpler form and everyone ends up reimplementing the higher level concepts in incomplete or at least incompatible ways with everyone else. There is a need for experimentation and turnover to figure out which higher level constructs are best, but this is entering the realm of language design and should not be a required part of application programming.
It's not even that, this can be (and probably is) implemented with dynamic variables (or some similar mechanism). You can also implement exceptions with setjmp and longjmp in C.
I feel the most important thing is conventions, and having a weaker model of exceptions as a convention, affects all/most code in the platform. In Java most libraries throw exceptions and so you will probably use exceptions. In C most libraries return an int return value for error/success and you'll probably use that. In Common Lisp, people use conditions.
So, what I'm trying to say, is that when considering this kind of design decisions in a language, we have to take into account how it affects the whole platform (and not just see if it is possible to implement it any other way in our particular language of choice). The same reasoning should be applied for object orientated features, scoping rules, calling conventions, multiple-value returns, lazy evaluation, macros, continuations, modules, type systems, naming conventions, etc.
And the potential need to pass way more than one, if you have 5 different error conditions which can exist in the same stack you need to come up with some sort of standard way to express that (e.g. a mapping of condition to callable). Then you need to find out how to express inheritances/overrides, and the like.
Nah, you only need one error callback with a parameter, i.e. `f(error)`. You could override this at any point using closures. We're talking almost identical code.
And you also define the recovery strategies within the function that cares about them. It makes the code much more readable.
You also continue the computation from that call-site without losing the stack. If after a particular restart is invoked, processing can continue along the chain without missing a beat.
No... we could already do that with higher-order functions. We're going backwards here, please read the previous comments, specifically from ajuc.
As stated, a higher order function gives you all of these features already. (The discriminator function I suggested would just return a bool to indicate whether or not error recovery should occuur, which is handled at the call site, in the appropriate context, with the appropriate stack).
All Condition Handling brings to the table is the ability to omit passing the callback around. All the other features were already there.
