9.2. Interfaces to Restarts
Prev | Chapter 9. Conditions | Next

## 9.2. Interfaces to Restarts [sec_9-1-4-2-2]

Macro `RESTART-CASE`. In `(`RESTART-CASE` `form` {`restart-clause`}*)`, the argument list can also be specified after the keyword/value pairs instead of before them, i.e., each `restart-clause` can be either `(`restart-name` `EXT:*ARGS*` {`keyword-value-pair`}* {`form`}*)` or `(`restart-name` {`keyword-value-pair`}* `EXT:*ARGS*` {`form`}*)`.

Macro `EXT:WITH-RESTARTS`. The macro `EXT:WITH-RESTARTS` is like `RESTART-CASE`, except that the forms are specified after the restart clauses instead of before them, and the restarts created are not implicitly associated with any `CONDITION`. `(`EXT:WITH-RESTARTS` ({`restart-clause`}*) {`form`}*)` is therefore equivalent to `(`RESTART-CASE` (`PROGN` {`form`}*) {`restart-clause`}*)`.

Function `COMPUTE-RESTARTS`. `COMPUTE-RESTARTS` and `FIND-RESTART` behave as specified in [ANSI CL standard]: If the optional `condition` argument is non-`NIL`, only `RESTART`s associated with that `CONDITION` and `RESTART`s associated with no `CONDITION` at all are considered. Therefore the effect of associating a restart to a condition is not to activate it, but to hide it from other conditions. This makes the syntax-dependent implicit association performed by `RESTART-CASE` nearly obsolete.

| These notes document CLISP version 2.45 | Last modified: 2008-04-15

Enter your search termsSubmit search form
Webclisp.cons.orgclisp.podval.orgwww.lisp.org

Prev | Up | Next
9.1. Embedded Newlines in Condition Reports | Home | Chapter 10. Symbols