Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.1 6/24/83; site emory.UUCP Path: utzoo!linus!decvax!ittvax!dcdwest!sdcsvax!akgua!emory!merlin From: merlin@emory.UUCP Newsgroups: net.lang.mod2 Subject: Re: Modula-2 I/O Message-ID: <1395@emory.UUCP> Date: Sun, 9-Sep-84 22:39:02 EDT Article-I.D.: emory.1395 Posted: Sun Sep 9 22:39:02 1984 Date-Received: Sun, 16-Sep-84 08:54:15 EDT References: <3528@decwrl.UUCP> Organization: Math & Computer Science, Emory University, Atlanta Lines: 79 Michael Powell has raised some important questions in his discus- sions of modula-2 I/O. I agree with the thrust of his comments but am opposed to some of his specific remedies. I strongly support the need for a standard I/O module. It is essential for the study and promotion of the language. Such a standard should meet several criteria. It must support a comprehensive set of input/output capabilities, including, at a minimum, file and terminal oriented operations. A standard should define unambiguously the results of both successful and unsuccessful I/O requests. Reliable error-detection and error- recovery must be supported in all I/O capabilities. I feel that Wirth's "InOut.def" is an example of a reasonable approach to standardization. It encompasses most of the I/O con- structs that conventional applications require. It needs a con- siderable amount of refinement in order to qualify as a practical standard, since there are many ambiguous or ill-defined com- ponents. I am not championing "InOut.def" as the modula-2 I/O standard. It clearly is a contender and, unless someone can demonstrate how it is woefully inadequate on *functional* grounds, it appears to me to be the appropriate starting point. I must admit a strong aversion to modula-2 clones of the UNIX standard "printf" and "scanf". My grounds for objection are man- ifold. In a fundamental way this approach opposes much of what modula-2 is intended to accomplish. If the language is to enforce strong type-checking then procedure calls with "cross-coupled" parameter lists much be validated during some phase of compilation. The compiler must recognize these specially designated procedures as well as their *internal* syntactical structures. These pro- cedures become aspects of the language itself. It is not incon- ceivable to me that we may wish to consider language-defined I/O mechanisms, but I strongly suggest that this be evaluated as a language design consideration and not as an ad hoc method of in- troducing an I/O standard. There are other serious problems created by this formulation. The code generated for a program requiring, for example, only simple integer I/O may incorporate facilities for many unused I/O conversions. To the extent that the format string is itself de- fined only during program execution, all possible I/O conversions must be made available at run-time. The inability of the pro- grammer to specify only those functions requisite for her pur- poses may hamper development of a variety of systems. Moving on to other concerns. Format-string directed I/O tends to create a need for explicit control-character representation (as with C's backslash notation). The problem is that this couples the logical functioning of input-output procedures with specific characters in data strings. Representations of record, line or file terminators should be details hidden beneath appropriate procedure calls such as Wirth's "WriteLn". This allows a much more effective way to adapt to variations in system-specific control-character conventions. My other objections are more matters of personal taste. These functions exemplify an extreme control-coupled approach to argu- ment transmission that transform procedure calls into veritable input-output *vegematics*. The odd thing is that, apart from familiarity, there is very little to recommend them. Granted they do capture an image of the structure of the input or output in a compact form but only at a substantial cost. We need to act now to establish a simple reliable standard. It does not have to do everything. It is important to remember is that the language is intentionally *modular*. New solutions can be incorporated at a later time as long as we refrain from incor- porating I/O support in the language definition through elaborate compiler enhancements. Marc Merlin Emory University Atlanta, GA (akgau!emory!merlin)