Must a restart handler be signal
-ed from within another handler, or can it be signal
-ed directly by the code where the exceptional condition was detected?
If it must be signal
-ed from within a handler, why is it so? it seems like a needless extra step.
What is the added value of a restart handler as opposed to a regular handler; if we dispensed with restart handlers altogether (but not with regular handlers)? Would it make any difference as to the power or expressibility of the language?
The following answer should be taken with a grain of salt. It is based on my understanding of the section "Conditions" in "The Dylan Reference Manual", however I have never written a single line of Dylan code and have not even read much more of the reference manual than said section.
Must a restart handler be signal-ed from within another handler, or can it be signal-ed directly by the code where the exceptional condition was detected?
A restart
is a condition
, as shown in Figure 11-6 of the reference manual. It can be signal
-ed whenever a signal
statement is syntactically valid. There is no special mechanism for installing handlers for restart
conditions as opposed to handlers for non-restart
conditions (in contrast to such languages as Common Lisp and R).
The only difference in signaling a restart
as opposed to signaling a non-restart
condition is that if a restart
handler is signal
-ed from within another handler, the rest of the handler code that lexically follows the signal
-ing will not be executed even if the restart
handler returns. In this case, the execution of the handler that signal
-ed the restart
, as well as the execution of the handlers that invoked this handler, stops and the values returned by the restart
handler become the values returned by each of these handlers. ("If the restart handler returns some values, signal returns those values and the handler that called signal also returns them. The call to signal from the signaling unit that signaled the original condition returns the same values, and the signaling unit recovers as directed by those values." Restarts/The Dylan Reference Manual).
It is not clear to me what happens if a restart
handler performs a non-local exit targeting a location inside the unit where the restart
handler was signal
-ed.
What is the added value of a restart handler as opposed to a regular handler; if we dispensed with restart handlers altogether (but not with regular handlers)? Would it make any difference as to the power or expressibility of the language?
The restart
mechanism is, in effect, a switch
statements, whose selection condition is determined dynamically by code external to the function where the switch
statement is defined. A restart
signal can be emulated by a non-restart
condition, but the restart
mechanism provides two formal facilities that otherwise would have to be established by convention in order to achieve similar functionality:
restart
handler returns after having been signal
-ed from within another handler, the rest of the code in the other handler is automatically skipped and the handler returns the values returned by the restart
handler.restart
condition can be formally identified by its type. If there weren't a restart
type, some other convention would need to be followed if it were desirable for restart
conditions to be identifiable, e.g. for the purposes of listing them in the debugger's Recovery menu ("An interactive debugger ought to offer the user the ability to signal any restart for which a restart handler is applicable and to return if the condition's recovery protocol allows it. This could, for example, be done with a menu titled "Recovery." " Recovery Protocols/The Dylan Reference Manual)