J. David Bryan wrote:
On 17 Oct 2001, at 13:32, Frank Heckenbach wrote:
I was going to say that it can input/output via files etc., but given that all files that are not mentioned in the header are internal and their contents will be gone after the program terminates, and ISO-7185 doesn't provide any other way of doing I/O, it seems indeed that such a program couldn't do much more than wasting some CPU time.
That is not strictly true. Consider that a program-level variable might be bound by the linker to a memory-mapped I/O address (specifically, in an embedded-controller application, where file I/O is less likely to be the means of affecting the environment).
Is this allowed (since it might change the meaning of the program)? Shouldn't such variables be also mentioned in the program parameter list? I think so ...
ISO 7185, 6.10 says: "The binding of the variables denoted by the program-parameters to entities external to the program shall be implementation-dependent, except if the variable possesses a file-type in which case the binding shall be implementation-defined."
After looking up implementation-dependent ("possibly differing between processors and not necessarily defined for any particular processor") and implementation-defined ("possibly differing between processors, but defined for any particular processor"), I conclude that GPC is ok in not supporting anything but files in the program parameter list, but I also gather that such variables that you talk about should be mentioned there (for a compiler that supports them; while GPC will reject them because they're not files, instead of silently compiling the program without the I/O effects).
So it still seems to me that a meaningful ISO-7185 program cannot have an empty parameter list.
Another application is where the program itself is the side-effect, i.e., test cases that are expected to trip syntax errors (and therefore are never expected to be executed).
Maybe a borderline-case of "meaningful". (Providing a compiler feature that only exists to be tested seems quite strange to me. ;-)
So, should we leave the warning (because it's pointless to write such a program)?
I do not believe so.
Warnings are appropriate for situations where the outcome may be unexpected. For example, consider two nested blocks, each containing variable declarations, and the inner variable name differs from the outer variable name only in case (e.g., "var CogEntry" and "var CoGentry"). In this case, the programmer might be surprised when the inner variable hides the outer one (due to Pascal's case insensitivity).
However, for omitted program parameters, either the program will be legal, or it will be illegal, depending on the presence of implicit uses of "input" and "output" later in the program. Regardless, there will be nothing surprising. In the former case, there can be no implicit I/O calls; in the latter case, there must be an error diagnostic during compilation.
I'd rather buy this argument, and will remove the warning if no-one objects.
Warning the programmer of something that is clearly intentional is not warranted.
However, it's not clear to me that it's always intentional -- the programmer might just have forgotten to provide the parameters. But since this will result in errors further down (unless he also forgot any I/O in his code ;-), that's alright I think ...
Frank