Volume 4, number 1, March 1996, pages 30-31

Windills
Or Else...

by Ed J.P.M. de Moel

This time, I'd like to talk about the IF command, or, rather, about the ELSE command. In many programming languages, there are IF, THEN and ELSE commands. Typically, they are tightly connected to one another, and allow for nested usage of control structures based on different conditions. In M[UMPS], however, the operation of ELSE is defined in terms of a special variable ($TEST), which in turn is defined as a status variable. The status that it represents may be the result of the most recent IF command, but also the result of a OPEN, LOCK or READ command if one of those was issued with a time-out. The language standard that was first approved by ANSI in 1990 added a stacking mechanism to the definition of $TEST in the context of extrinsic variables, extrinsic functions and argumentless DO commands.

Before the M[UMPS] language contained extrinsic functions, the only way to return values out of a subroutine was by establishing a protocol that a specific variable would contain the resulting value upon completion of that subroutine. Many users of M[UMPS] will have seen code like:

FOR I=0:0 WRITE !,Q READ X DO CHECK QUIT:$T

i.e., keep reading an answer to a question, until a correct answer has been entered. In this context, the variable Q would contain the prompt-text, the variable X would receive the user-input and the subroutine CHECK would check the answer, and leave a "true" or "false" condition in special variable $TEST that would indicate whether or not the answer that was entered was valid.

Of course, with "modern" M[UMPS], it would make more sense to write this line of code as

FOR  WRITE !,Q READ X QUIT:$$CHECK(X)

so that the subroutine has its parameter passed by value, and returns the validity check value as a function-result.

But... although it is now possible to write more modular code, we still want our "old" code to keep executing the same way it did before.

Stack as stack can

The point I am trying to get to is that there have been many requests before the MDC to change the behavior of If-Then-Else constructions, so that the behavior would become closer to what students learn nowadays in computer science classes when looking at languages like Pascal and C.

One approach that has been offered as a modification to the M[UMPS] language was to make the value of $TEST be stacked on all DO commands. The Committee discussed this approach several times over the past years, and kept running into the problem that it would not be acceptable to break a lot of existing code (like the example I showed earlier in this column). As a result, this approach was never accepted.

One other question that typically arose in such discussions was "if we are going to stack one special variable, aren't there any other ones that we would want to be stacked as well?" The only other one that really is a candidate would be $IO. And... for this variable the result was invariably the same as for $TEST: there are too many subroutines that are called for the specific purpose of selecting a new input or output device, to consider stacking the value of $IO on DO commands.

Other approaches

One other approach would be to introduce a "blocking" mechanism into the language: the "then" part would be one block of code, and an ELSE command that would follow the end of such a block would work on the same value of $TEST that was used by the "then" part. This particular approach has been discussed within the Committee for almost 5 years now, and at every new discussion, new considerations kept popping up, that showed a need for further refinement of the proposal in question. The current document that presents this approach seems to be close to a final version.

Another approach that was considered was to rename the ELSE command to become the EXCEPT command. The abbreviation would still be "E" and no code would behave any different. This approach was rejected on the basis that it did not address the basic underlying problem: to make M[UMPS] behave the way that is taught in current-day computer theory.

The remaining new approaches are to leave all existing commands as they are, and add some new features. The most viable one seems to be the suggestion to add the THEN, OTHERWISE and ENDIF commands and the special variable $CONDITION. This new set of commands would stack the value of $CONDITION when a THEN command is executed, and would use this value from the stack when an OTHERWISE command is executed, and pop it off the stack when an ENDIF command is executed.

At the next MDC meeting (March 1996), it is extremely likely that the merits of proposals along these lines will be discussed. If you wish to see more technical details about the proposals in question, feel free to request copies of the most recent documents from the MDC secretariat (the MTA will need to charge for photocopying and postage expenses). If you wish to make certain that your views will be considered at this meeting as well, please send your contribution to the MDC Secretariat before 7 February 1996, so that it can be included in the "pre-meeting mailing".

The MDC Secretariat is housed at the MTA offices:
1738 Elton Road, Suite 205
Silver Spring, Maryland 20903
Telephone: 1 (301) 431-4070
Telefax: 1 (301) 431-0017


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.