ills
illsM Computing, Volume 3, number 5, November 1995, pages 27-29
Backward incompatibility... Over the past months, I have heard this term quite a lot of times. But, how often was it used appropriately?
In other words: if we make a modification to an entity, and it is possible to see whether or not that modification has been applied, the "new" situation is clearly not the same as the "old" one, but does that mean that the "new" situation is "backward incompatible"?
There are many possible definitions of this term; the one that the MDC uses is based on a checklist:
If either of these questions can be answered with "yes", there is a "backward incompatibility".
Let's look at an example outside of the realm of computers: assume that we have a car that is painted red, and we apply a modification in the sense that we paint the car blue. It is still the same car. In all aspects that define the operation and usage of a car, it is still the same; only the (outside) color has changed. Of course, there will be people who don't like the new color, as well as there will be people who didn't like the old color.
But... all the parts still fit together the same way. Even if there were something like a replacement-specification for a rear-view mirror, or more heavy duty tires, the car as a whole would not be different.
The point that I want to make is that it is possible to apply a modification that makes an entity more (or less) desirable, but still is a modification that has no impact whatsoever on that entity in terms of "compatibility".
For instance, the M[UMPS] code:
SET X=$NEXT(A(2))
gives a specific result in an implementation that behaves according to the 1990 M[UMPS] standard. In an implementation that behaves according to the 1995 (draft) M[UMPS] standard, however, the same code should produce an error (the function $NEXT is no longer supported).
This is a backward incompatibility.
And the FORTRAN code:
DO 2 K = 7, 5
WRITE 1, K
1 FORMAT (I7)
2 CONTINUE
will produce one specific result in an implementation that behaves according to the 1966 FORTRAN standard, and a specific different result in an implementation that behaves according to the 1977 FORTRAN standard (the 1966 standard insists that the loop is always executed at least once, the 1977 standard prohibits that the loop is ever executed if the loop-limits are not in logical order).
This is a backward incompatibility, and, allegedly, this specific incompatibility cost NASA dearly: it is rumored that an unmanned satellite crashed because a program depended on a loop being executed at least once. Fortunately, this accident, whether or not it happened because of this particular incompatibility, gave rise to a number of efforts of software accreditation (SEI levels in the USA, ISO 9000 internationally).
However, the M[UMPS] code:
MERGE A=B
will produce an error in an implementation that behaves according to the 1977, 1984 and 1990 M[UMPS] standards, but will produce a well-defined, specific, result in an implementation that behaves according to the 1995 (draft) M[UMPS] standard.
The addition of new functionality is (in general) not seen as "backward incompatibility".
Note: There is no MDC specified error code for "syntax error". The reason may not be obvious, but look at it this way: if there were a standardized error code for "syntax error", it would be possible to write standard M[UMPS] code that produces a specific error when code like (for example)
PICK "an apple"
is executed. If, in a future standard, the MDC would define a PICK command, then, whatever such a command would be defined to do, this specifically standardized error would no longer occur, and explicitly defined behavior would change.
Fortunately, the absence of a standard error code for "syntax error" has the effect that enhancements and additions to the language will not automatically turn into "backward incompatibilities".
Consider the M[UMPS] code:
CLOSE $IO
The standards of 1990 and earlier stated that one out of two possible results could be expected; the 1995 (draft) standard stipulates that one specific of these options is to be chosen. Backward incompatible? Well, if you're used to an implementation that had to be changed because of this re-definition, you might feel that way, but, since the original standard did not define specific behavior, this does not fall within the MDC's definition of backward incompatibility.
The MDC does feel that this re-definition greatly enhances portability, and removes a lot of confusion.
Finally, consider the M[UMPS] code:
WRITE $FNUMBER(X,"T+")
This function will produce a formatted representation of the value of X, e.g.:
| Value of X | Function value |
|---|---|
| -5 | 5- |
| 0 | 0 |
| 5 | 5+ |
The "T" indicates that any sign is to be put in a "trailing" position, and the "+" indicates that positive numbers will have a sign, as well as negative numbers.
But... how about 0 (zero)? What is the sign of zero?
The language M[UMPS] follows the common mathematical practice to see 0 as a number that is neither positive nor negative. As a result, $FNUMBER should not include a sign for a zero value when it is being formatted.
Some implementations, at one time in the past, did include a sign on zero values in this context, and, by now, most of these implementations will have corrected this behavior. From the perspective of the end-user, this is a change in behavior, but from the perspective of the language definition, no incompatibility is involved.
At one time, the MDC increased the portability limit for the lengths of strings from 255 to 510 characters, and at several occasions, the MDC has increased the minimum requirements for precision and accuracy on arithmetic operations.
These are all minimum requirements for portability. When the MDC increases such a limit, there is no backward incompatibility involved: when a program was portable before the limit-increase, it is definitely still portable after the increased limits become effective.
However, there may be some "unexpected" side-effects of a change to a portability limit. Consider for instance the check:
IF CURRENT/3=^OLDDATA(X,Y)
If the value that is stored in the database was computed as SOMETHIN/3 when the "12 digit limit" was in place, and is being compared while the "15 digit limit" is in place, the check will most likely return a "false" result, even if the values "intuitively" are the same.
This kind of behavior is generally not seen as a backward incompatibility, but as a general issue of caution in comparing values that result from floating point calculations. In any programming language, such results will be affected by internal round-off and truncation errors, and comparisons involving such numbers should always be made with enough "margin" for these artefacts.
In some cases, the language standard specifies that certain values, or certain syntax, are "reserved". When such a specification occurs, it is a clear indication that, at some time in the future, a language extension is foreseen that will utilize the syntax or values in question.
Applications that use such features before such an extension becomes official, may fall victim to the fact that they are, in fact, beta-testing an early implementation. When the final version of such a "reserved" feature becomes official, the experiences of the "testers" will probably have been incorporated in the final result, and that result may or may not be similar to the early "unofficial" versions.
Such differences are not regarded to be incompatibilities.
Looking at the MDC's track-record, I think it is fair to say that the MDC makes a honest effort to prevent backward incompatibilities. The only ones that I currently know about are:
Some of the proposals to modify the language that failed because of the resulting backward incompatibility are:
There are many more, but one gets the picture: the MDC is committed to making certain that code that currently behaves in a certain way keeps doing the same thing, unless there is a very good reason to do otherwise which has strong support from the user community.
Ed de Moel is past chairman of the MDC
and works with Jacquard Systems Research.
His experience includes developing software for research in medicine
and physics.
Over the past ten years, Ed's has mostly focused on the production
of tools for data management and analysis, and tools for the support
of day-to-day operation of medical systems.
Ed can be
reached by e-mail.