Traps, Traces, Continuations, and Program Points

[orcmid]

There are no exceptions in oMiser. Every oMisre ob has an applicative interpretation. That is, for obs p and e, obap.ap(p,e) and obap.eval(e) are admissible.

Trapping Undefined Interpretation in Traces

But not every ap(p, e) has defined behavior. This is not about failure to terminate but failure to have any means of going farther in the computation. This applies, for example, when p is a lindy. In this case, and some other similar ones, the applicative interpretation is a trace. Technically, the operation is trapped, and the result is a trace. It is the nature of traces that they are applicatively irreducible. They are trapped over and over.

This is a little like producing a null result (e.g., returning ob.NIL), except the trace provides evidence in terms of the trapped material. It is still necessary to check for those, of course, concerning the clues the trapped value provides as evidence of how an unintended result arose.

Obtaining a trace can also be intended, as a kind of symbolic confirmation of a script.

Excep;tions, Continuations and Program Points

There is no exception mechanism in the oMiser model of computation. And the prospect of traces is quite messy.

Technically, throwing an exception is not totally problematic. It just means there is no result instead of a trapped trace result. That continuation is elsewhere as if some other computation is now progressing requires more machinery, but it technically just means some case of a partial function are handled explicitly.

The additional machinery is that involved in establishing a continuation for a later exception.

Program Points for (Exception) Continuations

Peter Landin proposed Program Points as part of a general exception continuation mechanism. This depends on there being an environment that is part of the computation model. The idea is one can set a continuation at a place in evaluation for which there is an individual (the program-point) that when applied to an operand operation reverts to the point of continuation establishment and the continuation is applied to the program-point operand.

In order to handle faults, there must be a way to set program points as fault handlers for definite faults. That's to the degree that there are defined faults and an environment that handles this.

The other case is explicit application of a program point as a means of diverting to the continuation. That is like throwing an exxception as a purposive action during applicative processing. An example would be backtracking in some sort of search heuristic, as in a top-down parser.

The key to use of Program Points is that there is no continuation at the point of invocation, but only at the poiint of construction, something that need not be nearby with respect to the "flow" of operations.

The intriguing thing about Program Points at something close to the oMiser level is that functionality is preserved although some significant environmental support is required. The place where this becomes haiiry is with respect to stateful situations and whether or not they are (or even could be) "backed off."

That's why this is not a serious proposal for oMiser at this point.