Add support for a "failure reason"

[pschachte]

A failure reason would be a string indicating the reason for a failure, akin to an error message. The failure reason would be the only "variable" that would actually be assigned by a failing computation. The failure reason could be accessed in later disjuncts to report or handle an error. In effect, this allows failure to be used as an exception mechanism. Perhaps failure_reason should be an automatic resource.

Ultimately, the failure reason should not be a string, but some kind of type class, which allows new kinds of reasons to be easily added, with appropriate methods written. Wybe doesn't currently support this, but it's also a wish list item.

[jimbxb]

One potential issue I see with failure_reason as an automatic resource is the ultimate idea of it being some type class. If two different procedures set the failure_reason resource, there's potential there to set it to two different concrete types. While we would have the same methods on these types, the name failure_reason would have two different types in the same context, which will cause some issues in type checking.

One way to solve this may be to allow the failure_reason to be given a name, say via some alternative to a use block that provides named aliases, like

use failure_reason as foo in {
    if { !may_fail_foo :: pass
    | else :: !handle_foo_failure
    }
}

use failure_reason as bar in {
    if { !may_fail_bar :: pass
    | else :: !handle_bar_failure
    }
}

This way you could associate the name foo and bar with the resource value of failure_reason and avoid the type headache mentioned above.

This also opens the rabbit hole again of generically typed resources, but I don't know if we want to go there.