A case for using procedure calls for I/O
Wahhab Baldwin · ACM SIGPLAN Notices · 1989
In the May, 1989 issue of Sigplan Notices Ronald Fischer takes issue with the idea of using procedure calls for handling input and output [3].The statement is made that the language should be more concerned with what has to be done with when I/O is required rather than how.The idea is that the programmer should not have to waste his time with I/O, but rather should be able to concentrate on the subject at hand.It is implied that this cannot be done using procedure calls.The examples that are used are all from Pascal, or are "Pascalish," as the author states.My feeling is that the problems the author cites are real, but that they are not inherent in the idea of using procedure calls for I/O.Most of the problems are inherent in the approach to I/O that is used in Pascal and most modern languages.It is noted that the languages Pascal and C use I/O "procedure calls" which require that a variable number of parameters, and that the procedures themselves, therefore, cannot be written in the respective language.In the case of Pascal, this is true.However, I currently use Borland's Turbo C which does allow the use of a variable number of parameters [I].It would not be difficult to write the procedure "printf" in this language.In addition, I have recently designed a strongly typed language which I call the animate programming language which allows a variable number of parameters also [2].That point, however, evades the issue, since this issue is only mentioned in the article.The main thrust was that the procedure syntax was inappropriate for the implementation of a simple I/O interface for a language.A suggested improvement is made by an example of a "PANEL" programming language.If the "PANEL" language as described in the article were implemented, then the PANEL's would be nothing more than specialized procedure calls, and a language could define them as such.The article does suggest the use of a different parameter class than Pascal, namely the "out" class, which is for output only parameters.Perhaps this suggests a reasonable extention to the Pascal language.About 1978, when I was working for Boeing Computer Company, I was given the assignment of designing and implementing a terminal interface.At that time the situation was complicated by the widespread use of printing terminals as well as CRT's.The interface I designed (in fortran) was able to handle both types of terminals with ease, and might be used as a model for designing I/O procedures for a programming language.The model that was presented was a message model similar to the screen model used in the "PANEL" system described in the article.Rather than referring to a screen, or panel, the transaction was refered to as a message.I am not sure that this system was ever documented.A transaction was begun with a call to "message" procedure.There was one argument which identified the message, or screen, to be output.(The implementation used an integer due to the restrictions of the language, but any type of identifier could have been used.)This would display the message (screen).The message that was displayed was one of three messages depending on the level of the user--the novice level, the average level, and the expert level.All of this was below the level of the programmer, who would not have concerned himself with where the message was on the screen or what level of expertise the user desired.