What was the purpose of Tartan's "disable" statement?

Question

The Tartan language, designed during the process that eventually led to Ada, has a disable statement defined as follows:

A disable declaration in an inner block suppresses detection of the exceptions it names. A handler clause associates recovery code with a statement that may generate an exception (see section 4.7).
The disable declaration permits exceptions to be individually suppressed within a given scope. Should an exception occur when its detection is suppressed, the consequences are not defined. An exception must not be signalled or redeclared in a scope in which it is suppressed. Note that suppression of an exception is not an assertion that the condition that gives rise to the exception will not occur.

(Tartan reference manual, §6.4, emphasis mine)

It seems the disable statement has no other purpose than to trigger undefined behavior... what is the point of such a statement?

Answer 1

The purpose of this feature in Tartan is to satisfy the Ironman requirement 10G:

10G. Suppressing Exceptions. It shall be possible to suppress individually the detection of exceptions for software error situations. Should such a situation occur when its detection is suppressed, the consequences will be unpredictable

The "Strawman", "Woodenman", "Tinman" and "Ironman" versions of the Department of Defense Requirements for High Order Computer Programming Languages were released in sequence as part of that Ada development process. As the abstract of the Tartan paper notes, minimally satisfying all of the Ironman requirements was the primary goal of that language design.

In fact, the specification statement is exactly in the terms of the subsequent Steelman requirements, which had recently become available:

10G. Suppressing Exceptions. It shall be possible during translation to suppress individually the execution time detection of exceptions within a given scope. The language shall not guarantee the integrity of the values produced when a suppressed exception occurs. [Note that suppression of an exception is not an assertion that the corresponding error will not occur.]

---

The reason those requirements specified that detection of exceptional conditions should be able to be locally disabled was that the run-time costs of validating them could be significant on typical period hardware, such as requiring range checks on every access to a variable. This is explicit in requirement 10B:

10B. Error Situations. The errors detectable during execution shall include exceeding the specified range of an array subscript, exceeding the specified range of a variable, exceeding the implemented range of a variable, [...elided...]. [Note that some are very expensive to detect unless aided by special hardware, and consequently their detection will often be suppressed (see 10G).]

Thus a program could opt to avoid incurring these checks for a portion of the code where the performance cost of detecting them was unacceptable, either because that error was known not to occur or because the implementation's behaviour was acceptable in the cases where it did. This also made it into the final Ada definition in the form of the Suppress pragma, for the same reasons.

---

• _{Department of Defense Requirements for High Order Computer Programming Languages, "Ironman". 14 January 1977. ADA100403. (alternative archive.org version)}
• _{Department of Defense Requirements for High Order Computer Programming Languages, "Steelman". 1 June 1978. ADA059444. (alternative wikisource text copy)}

Answer 2

In Tartan, and some other languages at that time, error reporting mechanisms are also used for trivial things like reaching EOF and integer overflow. This isn't very clear in the reference manual, but could be seen in the examples in section 4.7:

read(file,x) { on EOF -> goto Exit }
x := x+1 { on Overflow -> x := 0 }

The following is my speculation. If they happen unexpectedly, and no check is done, the code could be faulty. But if it never happens, doing the check would have some performance cost. So it might be helpful to give the user the control to turn it on and off.

It is a small detail that modern languages seem to not care about. Programmers seem never need it, unless they want the code to be extra safe, in which case they never turn it off. And most importantly, it doesn't seem easy to make user-defined exceptions take advantage like this, so it could only be a special case if supported.

Answer 3

Although "performance reasons", as described in other answers, seems like an adequate explanation for why it would make sense to turn off error checks, I think it's also important to recognize that our modern understanding of "undefined behavior" has evolved a lot over time. My guess is that, at the time this was written (1978), it would have been understood to mean "whatever the implementation happens to do is fine, and whatever values happen to come out are fine". That is, I think it would have been closer to what we now would called "unspecified" or "implementation defined" behavior, rather than today's "nasal demons" definition of undefined behavior.

Even if the latter was technically a possible reading back then, probably nobody would read it that way, because it would have been fairly academic before the advent of today's hyper-aggressive optimizing compilers.