# How did exception handling work in the Plankalkül language?

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?

• For those interested, the original 1972 paper by Konrad Zuse can be read here. Its first half in the 1945 version is available in a more legible layout here I am not good enough in theoretical information science to really understand it, but I could not find any obvious reference to exception handling. Apr 15 at 14:35
• Have you found the Konrad Zuse Internet Archive with digitized versions of many of his handwritten and printed original writings on the Plankalkül? Looks like exception(s) = Ausnahme(n) and exception handling might be = Ausnahmebehandlung, in case you want to skim. Unfortunately it looks like a lot of the handwritten stuff is in some kind of shorthand. Apr 15 at 15:04
• Apr 17 at 20:41

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.

• I'm not sure I'd consider setting a flag on overflow (like any CPU I've ever used in the last 30 year will do) to be "exception handling", but perhaps that's a lack of imagination on my part? Apr 15 at 17:29
• This makes sense to me. At that time the most I would expect is "if some bit is set goto handler". I guess in this context "exception handling" is used to mean "you can find out that an exception happened and react". Thank you! Apr 15 at 18:35
• Getting CPUs to do that (environments, really) was a tremendous accomplishment which took some getting inspiration from solutions like Zuse’s. However, I wound treat their ubiquity now as the likely reason you see it as elementary, not any lack of imagination on your part. Apr 15 at 18:35
• @AdamHyland - You have a point. I can remember my CS102 instructor back in the 80's telling us how process load balancing algorithms (like modern consumer OS today performs) used to be considered "Artificial Intelligence". Apr 15 at 18:51

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:

1. Exactly zero
2. Very small
3. Very large

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.]
``````
• This is part of a plan for "half-logarithmic calculations". Its result value is composed of 22 bits (p. 162), the last three being sign, imaginary flag and an exception flag for the three cases you listed. Apr 15 at 17:33
• One bit, so the three exceptions are not differentiated: "Hierzu tritt das Vorzeichen, ferner die Imaginärangabe und ein Sonderzeichen für Ausnahmewerte." - In addition, there is the sign, the imaginary indication and a special character for exceptional values. Apr 15 at 17:38
• That is the danger if you are reading fast: these bits are not part of a result, but of the logarithmic number type (sort-of floating point number in the complex number system) itself. Apr 15 at 17:54
• I have to dig into the references in other answers but I suspect this is close to the answer. The “exception handling” such as it was seems to be related to how we think of exceptional values in floating point (overflow, under flow, zero). Apr 15 at 18:24
• Now I have it: In case the "exception" bit is set, the second part of the number (for regular numbers containing the exponent) will contain two bits to discern between the listed cases. Then, when these numbers are used as input values, some operations 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 on p. 176ff. This differs from a simple NaN behavior that would bail out of any further computation. Apr 15 at 18:33

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.

• An article here mentions that it had arithmetic exception handling.
– justCal
Apr 15 at 14:05
• @justCal - Good find! I'm not sure exactly what that means though. Does it just mean you can define a block to take control when the program tries to divide by 0? I suppose that could be hacked ... er ... repurposed for general-purpose exception handling, but I'd need to see more about it. Another good argument for migrating this question. Apr 15 at 14:12
• A little more depth on the language particulars here.
– justCal
Apr 15 at 14:28
• @justCal - Yeah, I've found a couple of good troves of information about it now, and am trying to digest them. I figured there wouldn't be much in English given when and where it originated. It turns out most of the information about it (and its only compiler) came much more recently, which in the CS world means its in English. Apr 15 at 14:39
• Note that the compiler published by Rojas et al. only implemented a subset of the language Apr 15 at 15:15