Retrocomputing Stack Exchange is a question and answer site for vintage-computer hobbyists interested in restoring, preserving, and using the classic computer and gaming systems of yesteryear. It only takes a minute to sign up.
Sign up to join this community
I saw mentioned in a number of places that the Plankalkül programming language had exception handling features. However, I am unable to find a description of what that looked like. It seems that most texts about this language are in German, which I don't read (at least not well).
Does anyone have this information?
I will be citing from the 1945 version of Konrad Zuse's paper Der Plankalkül, as published by the Zuse archive in a typeset version with LaTeX.
The Plankalkül language is very modular in nature. It builds complex calculations (Rechenpläne) from nested subroutines (Unterpläne, p. 13). There are no GOTO operations; only symbolic notations of places where a subroutine must be inserted into a plan.
Konrad Zuse deemed some of these plans so elementary that he tried to write them out systematically. Among the plans handling numbers there are some which might end with the result overruning the register. Therefore, they are given a second return value in the form of a bit that indicates such an overrun has happened (p. 122):
Der volle Rechenplan einer Operation enthält mitunter außer dem eigentlichen Resultat der Operation (z.B. Summe) Ergänzungsangaben wie das Signal der Stellenüberschreitung. Diese können durch das Operationszeichen nicht wiedergegeben werden. In solchen Fällen muß Kennzeichnung der Werte durch Planzeichen bzw. Resultatzeichen (z.B. R8.10) erfolgen.
DeepL translation:
The full calculation plan of an operation sometimes contains, apart from the actual result of the operation (e.g. sum), supplementary information such as the signal of the digit overrun. These cannot be represented by the operation sign. In such cases, the values must be marked with a plan or result sign (e.g. R8.10).
(The numbering of these plans is a bit confusing, probably because the editor did not fully master LaTeX typesetting.)
A summation might, for example, be written as (p.126, P8.64)
R( V, V ) ⇒ ( R, R )
V | 0 1 0 1
A | 8 8 8 0
with the second R value being annotated as Aussage: ”Stellenerhöhung“ (statement: position increase).
These signals might be undestood as exception handling, but also simply as an indication that the position increase (Erhöhung der Stellenzahl), described as P.9.26 on p. 145, must happen. This is then written out in a variation of the summation operation:
V +V ⇒ R
V | 0 1 0
A | 1.n 1.n 1.n + 1
...with more instructions following. The details are a bit beyond me, but it seems they compute the second R₁ value indicating whether a position increase actually happened.
The next part was identified by Thomas By for his answer, but I'd like to elaborate further. Zuse introduces computing with a halblogarithmische Form, a number type that resembles a floating point number in the complex number plain (p. 161ff). It is represented with a total of 32 bits, divided into three groups:
| K0 | K1 | K2 |
|---|---|---|
| I V S | ||
| 0 1 2 | 6 5 4 3 2 1 0 | 21 20 19 ... 0 |
K3 represents values in the 0...1 range in binary notation (so the lowest value is 2^-22). K1 is the binary exponent (the highest value being 2^7 - 1). The first three bits represent imaginary (I), sign (V, German Vorzeichen) and exceptional cases (S, German Sonderzeichen für Ausnahmewerte).
In case the S bit is set the K2 part is invalidated, and the meaning of the K1 part changes, representing multiple cases according to this table:
| K0 | K1 | Meaning | short symbol |
|---|---|---|---|
| I V S | |||
| 0 1 2 | 1 2 3 4 5 | ||
| + | - + + - - | Zero | 0 |
| + | - - + - + | Very small | ≪ |
| - + | - - + + - | Very large, sign unknown, real | |∞| |
| + + | - - + + - | Very large, sign unknown, imaginary | i|∞| |
| - - + | - - - + - | Very large, negative, real | -∞ |
| - + + | - - - + - | Very large, positive, real | +∞ |
| + - + | - - - + - | Very large, negative, imaginary | -i∞ |
| + + + | - - - + - | Very large, positive, imaginary | +i∞ |
| + | + - - - - | Completely unknown | ? |
Zuse immediately mentions that the bits in K1 are not independent, so the above list of nine cases is exhaustive.
The table seems to indicate that I and V can have a third state, but it should rather be read that bits K1.2 and K1.5 invalidate the value of V, and K1.3 invalidates I.
These numbers are returned as results of computations, but can also be used as input. This way, some operations including "exceptional" values can still yield a "regular" result (like a summation with one summand being "too small"), or an exceptional result that has still a correct sign (subtraction with the second operand positive and "too large"). Algorithms for this are presented exhaustively on p. 176ff.
A paper on the reception of Zuse's Plankalkül (Katja Schunke 1998) identified the first American review of the language, a 1976 paper by Donald E. Knuth and Luis Trabb Pardo: The Early Development of Programming Languages. It tried to implement a test function f(t) = √|t| 5t^3 in 20 different languages, including the instruction to return an error code 999 meaning "too large" for some input values. They decided the PK program should return "+∞" instead of the expected error code (pp. 8-15).
In addition, I might point out that a number of plans are statements about sets or numbers (as in: "all members of the set differ from each other", p.66, P3.2). These statements might be used to decide if further operations on these sets or numbers are possible. But as far as I could see, there is no explicit notation or written-out plan that makes the positive outcome of such a statement a precondition for other computations.
From that paper somebody linked to (Der Plankalkül, pp. 162-3):
Es werden folgende Fälle als Ausnahmewerte dargestellt:
(a) Der Wert y ist genau Null (K1.2).
(b) Der Wert y ist sehr klein (K1.5)
(c) Der Wert y ist sehr gross (K1.4)
The following "exceptional values" exist:
Probably this is what the wiki page calls "exception handling" (cf. NaN).
Addition: English translations of German word Ausnahme:
exception
exceptional case
exemption
exclusion
exclusion zone
exceptions (to) pl.
disclosure [FINAN.]
sole exception
statutory exception [LAW]
law of exception
intervention exemption levels pl.
abnormal water level [TECH.]
exceptional water level [TECH.]
foreign exchange line [TELECOM.]
out-of-area subscriber's line [TELECOM.]
floating point exception [COMP.]
Programming languages routinely having direct support for exception handling is a relatively new development. Well, if you can call 3 decades plus "new" in an industry that's less than a century old. There are oodles of old languages that had no such support. Anyway, as the language was created in 1945, the concept of "exception handling" didn't really exit yet, so it didn't have it. If you needed to do that kind of thing back then, you'd usually use your languages' equivalent of "goto" to jump to a block with your exception-handling code.
However, Plankalkül's WP page doesn't mention direct support, and says this language has no "goto". That means you'd have to handle exceptional conditions with normal "if" checks. That's neither easy or natural to do of course, which is why "exception handling" became A Thing, particularly after "goto" use became stigmatized around the 1970's - '80's.
Plankalkül does appear to have had some kind of facility that some sources are calling "arithmetic exception handling". I'm trying to read up on it now. But again, any use of the term "exception handling" for features of the language is going to be us applying modern concepts retroactively, as the concept hadn't been thought up yet when the language was created.
I should also note that it appears as if no compiler for Plankalkül was created until quite recently (and of course that's just an implementation of a subset, with some language rules decisions made of the kind one never has to make until one actually tries to implement a language). This places it in the same category as Ada Lovelace's first computer programs, which largely existed only in untested design form on paper until quite recently historical computing enthusiasts have started taking a look at perhaps actually running them in real-life.
There are some references that claim Plankalkül had "Arithmetic exception handling". But the more detailed papers I was able to dig up about it don't mention any such thing. The first one was written in the 1972, so its possible the feature was in there but the author didn't yet know to look for it because he wasn't familiar with the concept, but the one written in 2000 has no such excuse.
