This site is a static rendering of the Trac instance that was used by R7RS-WG1 for its work on R7RS-small (PDF), which was ratified in 2013. For more information, see Home.

Ticket 496: Catastrophic failure should not be acceptable

2013-07-07 03:20:44
WG1 - Core
2013-05-12 23:44:12

Göran Weinholt writes:

These paragraphs are from R6RS:

The standard libraries whose exports are described by this document are said to be safe libraries. Libraries and top-level programs that import only from safe libraries are also said to be safe.

As defined by this document, the Scheme programming language is safe in the following sense: The execution of a safe top-level program cannot go so badly wrong as to crash or to continue to execute while behaving in ways that are inconsistent with the semantics described in this document, unless an exception is raised.

Contrast that with this paragraph from R7RS-small draft 9:

For example, it is an error for a procedure to be passed an argument of a type that the procedure is not explicitly specified to handle, even though such domain errors are seldom mentioned in this report. Implementations may signal an error, extend a procedure's domain of definition to include such arguments, or fail catastrophically.

Formalising catastrophic failure as an acceptable evaluation strategy is not a good idea. I also believe it conflicts with this requirement from the WG1 charter: "Semantics compatible with interactive read/eval/print loops should be provided."

There is no reason to allow safety to trump all other concerns at all times, any more than there is reason to allow performance to do so. Not mandating safety allows implementations to trade off safety for performance for the sake of users and programs who need that performance. This can be done either by a safety setting in a single implementation, or by allowing pervasively unsafe, yet conformant, implementations to be created.


The WG decided by unanimous consent to take no action on this ticket.