On the subject of missing "output" as a program parameter, or in the more general case, where the program header has no parameters at all (assuming of course "input" and "output" are neither explicitly nor implicitly used), Peter Grogono (in his book 'Programming in Pascal') says words to the effect of :
It is legal to omit the parameters from the program header, provided neither "input" or "output" is used, however, a program which provides no input or output is generally not very useful.
The above has an element of humour in it, but makes it quite clear that it is perfectly legal to omit "input" and/or "output" from the program header if these are not used. Note that the above is not an exact quote, just from memory, however, I could spend a bit of time to locate the exact text, if required.
On the subject of standards, please see below ...
Joe.
-----Original Message----- From: J. David Bryan [SMTP:dbryan@bcpl.net] Sent: Wednesday, October 17, 2001 6:04 AM To: GNU Pascal List Subject: Re: compiler bug
On 16 Oct 2001, at 20:34, Frank Heckenbach wrote:
I don't see a big difference between `--standard-pascal' and `--iso-pascal'....
I don't either, except it removes the possibly misleading word "standard" (implying that "standard-pascal" is standardized or preferred, whereas "extended-pascal" is not -- I hope I now take Joe's point correctly :-).
[Joe da Silva]
Yes, you do! :-)
I find that awareness of the Extended Pascal Standard is unsatisfactory, and in promoting Pascal, we need to improve this. IMHO, we should avoid any inference that ISO-7185 is the only standard, likewise any inference that Extended Pascal is non-standard.
(EP is also ISO).
Hence the suggestion of "--iso-extended-pascal". The title pages of the respective standards say, "Pascal" and "Extended Pascal," so my suggestion
incorporated those titles in the switch names.
So if anything, I'd tend to `--classic-pascal' or so.
"Classic Pascal" is meaningless to me (it's actually more suggestive of some variant with proprietary extensions, as the ISO standard was never "classic" in the sense that it was the version that everyone used; GPC is the first Pascal compiler I've used -- and I've used many -- that provides
a strict ISO 7185 option).
[Joe da Silva]
"Classic" is a perfect description of ISO-7185 (thanks, Prospero), since it corresponds exactly (well, with just one change, suggested by Wirth) to the language originally defined in the 'User Manual and Report' published by Jensen and Wirth, in 1974.
An alternative description would be "minimalist", but "classic" sounds much nicer! <g>
I'm happy with "--standard-pascal" and "--extended-pascal" if everyone else is.
And every user who uses the option would have to change it ...
Which may be the best argument for leaving it alone.
-- Dave
da Silva, Joe wrote:
On the subject of missing "output" as a program parameter, or in the more general case, where the program header has no parameters at all (assuming of course "input" and "output" are neither explicitly nor implicitly used), Peter Grogono (in his book 'Programming in Pascal') says words to the effect of :
It is legal to omit the parameters from the program header, provided neither "input" or "output" is used, however, a program which provides no input or output is generally not very useful.
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.
So, should we leave the warning (because it's pointless to write such a program)?
The above has an element of humour in it, but makes it quite clear that it is perfectly legal to omit "input" and/or "output" from the program header if these are not used. Note that the above is not an exact quote, just from memory, however, I could spend a bit of time to locate the exact text, if required.
Now that you said it, ISTR having read this somewhere, too ...
"Classic" is a perfect description of ISO-7185 (thanks, Prospero), since it corresponds exactly (well, with just one change, suggested by Wirth) to the language originally defined in the 'User Manual and Report' published by Jensen and Wirth, in 1974.
What is this one change, BTW?
Frank
Frank Heckenbach wrote:
da Silva, Joe wrote:
On the subject of missing "output" as a program parameter, or in the more general case, where the program header has no parameters at all (assuming of course "input" and "output" are neither explicitly nor implicitly used), Peter Grogono (in his book 'Programming in Pascal') says words to the effect of :
It is legal to omit the parameters from the program header, provided neither "input" or "output" is used, however, a program which provides no input or output is generally not very useful.
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.
So, should we leave the warning (because it's pointless to write such a program)?
The above has an element of humour in it, but makes it quite clear that it is perfectly legal to omit "input" and/or "output" from the program header if these are not used. Note that the above is not an exact quote, just from memory, however, I could spend a bit of time to locate the exact text, if required.
Now that you said it, ISTR having read this somewhere, too ...
"Classic" is a perfect description of ISO-7185 (thanks, Prospero), since it corresponds exactly (well, with just one change, suggested by Wirth) to the language originally defined in the 'User Manual and Report' published by Jensen and Wirth, in 1974.What is this one change, BTW?
Conformant arrays. Also some tightening up. The existance of any change was a big battle between the US and the world, circa 1980, resulting in level 0 and level 1 as a compromise. OTHERWISE was in the earlier drafts too.
CBFalconer wrote:
"Classic" is a perfect description of ISO-7185 (thanks, Prospero), since it corresponds exactly (well, with just one change, suggested by Wirth) to the language originally defined in the 'User Manual and Report' published by Jensen and Wirth, in 1974.What is this one change, BTW?
Conformant arrays. Also some tightening up. The existance of any change was a big battle between the US and the world, circa 1980, resulting in level 0 and level 1 as a compromise. OTHERWISE was in the earlier drafts too.
Conformant arrays are the only difference between 7185 level 0 and 1, aren't they? So level 0 is completely equivalent to original Wirth Pascal? Or did Wirth Pascal contain `otherwise'?
Frank
Frank Heckenbach wrote:
CBFalconer wrote:
"Classic" is a perfect description of ISO-7185 (thanks, Prospero), since it corresponds exactly (well, with just one change, suggested by Wirth) to the language originally defined in the 'User Manual and Report' published by Jensen and Wirth, in 1974.
What is this one change, BTW?
Conformant arrays. Also some tightening up. The existance of any change was a big battle between the US and the world, circa 1980, resulting in level 0 and level 1 as a compromise. OTHERWISE was in the earlier drafts too.
Conformant arrays are the only difference between 7185 level 0 and 1, aren't they? So level 0 is completely equivalent to original Wirth Pascal? Or did Wirth Pascal contain `otherwise'?
Yes, AFAIK. OTHERWISE was a proposed extension, not in J&W. I had put it in, and refused to take it out. However, I did go through some gyrations to make it not be a reserved word. Andy Mickel was the moving spirit behind everything (Pascal News). Does anyone know what happened to him? In those days (70s) the competition was Fortran, not C.
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).
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).
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.
Warning the programmer of something that is clearly intentional is not warranted.
-- Dave
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
On 18 Oct 2001, at 1:08, Frank Heckenbach wrote:
Is this allowed...
I don't believe that you will find anything in the standard that mandates that variables be mapped specifically to memory locations and not, e.g., to I/O devices. Such a mapping surely is the function of the external environment and therefore won't appear in the standard.
My point simply is that there may be mechanisms for a conforming program without program parameters to affect the external environment. Assuming that a syntactically correct Pascal program cannot have any useful effect and therefore should be rejected by GPC is unwarranted.
...(since it might change the meaning of the program)?
ISO 7185, section 5.2, "Compliance, Programs" says, in part:
"The requirements for conforming programs and compliant processors do not require that the results produced by a conforming program are always the same when processed by a compliant processor."
(...though this is a note and therefore not normative.)
Shouldn't such variables be also mentioned in the program parameter list? I think so ...
Such variables may be mentioned in the program-parameter-list, but I disagree that the standard requires that they be mentioned there.
ISO 7185, 6.10 says: "The binding of the variables denoted by the program-parameters....
This describes the requirements for any such variables mentioned in the program-parameter-list but does not say that any variable that might be bound to an external entity by the environment *must* be mentioned there (i.e., this section defines one such binding method but does not prohibit other, unspecified methods that might be present in the external environment).
...I conclude that GPC is ok in not supporting anything but files in the program parameter list...
I agree.
...but I also gather that such variables that you talk about should be mentioned there...
I disagree, unless the standard has some explicit restriction on how such variables are allocated to physical storage by the external environment (I couldn't find such a restriction).
So it still seems to me that a meaningful ISO-7185 program cannot have an empty parameter list.
Perhaps we're arguing to no purpose here. Do you agree that GPC should not reject a syntactically legal program that doesn't specify a program- parameter-list? If so, then my argument is irrelevant to this point.
Maybe a borderline-case of "meaningful". (Providing a compiler feature that only exists to be tested seems quite strange to me. ;-)
Then the whole GNU "autoconf" mechanism must seem strange to you! ;-)
As another example, the GPC test suite should test to ensure that legal Pascal programs are processed correctly, but also that illegal Pascal programs are caught and reported, yes? In that case, a test program such as:
program casetest;
var mixedcase, MixedCase : integer;
begin end.
exists to ensure that the Pascal compiler is case-insensitive (a syntax error is expected) and therefore would be meaningful without any program parameters. Requiring this program to have "(output)" in the program header would be pointless.
(By the way, gpc-20010924 does *not* catch this error!)
However, it's not clear to me that it's always intentional -- the programmer might just have forgotten to provide the parameters.
True.
But since this will result in errors further down (unless he also forgot any I/O in his code ;-), that's alright I think ...
Right!
-- Dave
J. David Bryan wrote:
On 18 Oct 2001, at 1:08, Frank Heckenbach wrote:
Is this allowed...
I don't believe that you will find anything in the standard that mandates that variables be mapped specifically to memory locations and not, e.g., to I/O devices. Such a mapping surely is the function of the external environment and therefore won't appear in the standard.
So, the following program would be allowed to output 0, according to the standard (because i might be mapped to an I/O address that happens to always yield 0)? I strongly doubt it? If anything, I can only imagine that a program parameter mentioning of i could warrant such a behaviour.
program Foo (Output);
var i: Integer;
begin i := 42; WriteLn (i) end.
My point simply is that there may be mechanisms for a conforming program without program parameters to affect the external environment. Assuming that a syntactically correct Pascal program cannot have any useful effect and therefore should be rejected by GPC is unwarranted.
Agreed.
...(since it might change the meaning of the program)?
ISO 7185, section 5.2, "Compliance, Programs" says, in part:
"The requirements for conforming programs and compliant processors do not require that the results produced by a conforming program are always the same when processed by a compliant processor."
(...though this is a note and therefore not normative.)
Yes, but some things (like that the program above should write 42, possibly preceded by a number of spaces) are guaranteed, I think.
ISO 7185, 6.10 says: "The binding of the variables denoted by the program-parameters....
This describes the requirements for any such variables mentioned in the program-parameter-list but does not say that any variable that might be bound to an external entity by the environment *must* be mentioned there (i.e., this section defines one such binding method but does not prohibit other, unspecified methods that might be present in the external environment).
This would, in the utmost consequence, mean that any valid Pascal program can do anything, and the standard could be reduced to a syntax diagram.
...but I also gather that such variables that you talk about should be mentioned there...
I disagree, unless the standard has some explicit restriction on how such variables are allocated to physical storage by the external environment (I couldn't find such a restriction).
It's not mainly about the allocation on physical storage (if a variable is allocated in a file, transparently read and written, that's probably ok), but about (intended) side-effects of seemingly "innocent" variables.
Perhaps we're arguing to no purpose here. Do you agree that GPC should not reject a syntactically legal program that doesn't specify a program- parameter-list? If so, then my argument is irrelevant to this point.
Yes.
Maybe a borderline-case of "meaningful". (Providing a compiler feature that only exists to be tested seems quite strange to me. ;-)
Then the whole GNU "autoconf" mechanism must seem strange to you! ;-)
I don't think it uses any shell, gcc or whatever features specifically developed for autoconf. -- I didn't mean writing a program only to test a compiler feature seems strange, but introducing a compiler feature that makes sense only for such programs would seem strange.
As another example, the GPC test suite should test to ensure that legal Pascal programs are processed correctly, but also that illegal Pascal programs are caught and reported, yes? In that case, a test program such as:
program casetest;
var mixedcase, MixedCase : integer;begin end.
exists to ensure that the Pascal compiler is case-insensitive (a syntax error is expected) and therefore would be meaningful without any program parameters. Requiring this program to have "(output)" in the program header would be pointless.
It was a warning only, anyway, just like the program might produce a warning about unused variables. The test should ignore these warnings (`-w' for GPC).
(By the way, gpc-20010924 does *not* catch this error!)
(dave1.pas)
Frank
On 19 Oct 2001, at 1:33, Frank Heckenbach wrote:
So, the following program would be allowed to output 0, according to the standard (because i might be mapped to an I/O address that happens to always yield 0)? I strongly doubt it?
Well, you've caught me without my copy of the standard at hand :-), but as I recall, there is a requirement that operations on integers must follow the rules of integer math. I can't check whether assignment is one of those operations listed, but it seems reasonable. So, no, the program you cited wouldn't be a conforming program (pending confirmation from the standard).
But how could the compiler possibly enforce this? Binding to RAM vs. a mapped I/O port (or to ROM) would be done at link time, so must the compiler issue a warning for the "var" statement that variables must be bound to RAM? How else can we disallow such a program?
Moreover, if that I/O address was fully read/write, then the program would be a conforming program (because integer rules would be obeyed), and yet it would still have side-effects without program parameters. That's the only point I was attempting to make.
Yes, but some things (like that the program above should write 42, possibly preceded by a number of spaces) are guaranteed, I think.
Unfortunately, what you and I think has no bearing on the matter. Only what the standard "thinks" is important! ;-) Cite a passage from the standard that states that main program block-level variables may not be bound to external entities, and I will concede your point happily.
This would, in the utmost consequence, mean that any valid Pascal program can do anything, and the standard could be reduced to a syntax diagram.
No, because there are certain semantic requirements in the standard that must be obeyed by conforming programs. However, where the standard is silent, we cannot infer some specific behavior.
It's not mainly about the allocation on physical storage (if a variable is allocated in a file, transparently read and written, that's probably ok), but about (intended) side-effects of seemingly "innocent" variables.
Cite where in the standard such side-effects are expressly prohibited, and I will agree with you. However, if the standard makes no mention of such side effects, we cannot infer that they are prohibited. For example, the standard makes no mention of whether the program code must be executed from ROM or RAM; does that prohibit one or the other?
(By the way, gpc-20010924 does *not* catch this error!)
(dave1.pas)
Thanks!
-- Dave
J. David Bryan wrote:
On 19 Oct 2001, at 1:33, Frank Heckenbach wrote:
So, the following program would be allowed to output 0, according to the standard (because i might be mapped to an I/O address that happens to always yield 0)? I strongly doubt it?
Well, you've caught me without my copy of the standard at hand :-), but as I recall, there is a requirement that operations on integers must follow the rules of integer math. I can't check whether assignment is one of those operations listed, but it seems reasonable. So, no, the program you cited wouldn't be a conforming program (pending confirmation from the standard).
I hope so.
But how could the compiler possibly enforce this? Binding to RAM vs. a mapped I/O port (or to ROM) would be done at link time, so must the compiler issue a warning for the "var" statement that variables must be bound to RAM? How else can we disallow such a program?
I think a "processor" according to the standard includes the compiler as well as the linker. Whether in practice a compiler alone (such as GPC) that might be used in conjunction with various linkers could be 100% conforming, is another question (and the answer is probably no, without making some requirements on the linker and forbidding the user of linker scripts etc.).
Yes, but some things (like that the program above should write 42, possibly preceded by a number of spaces) are guaranteed, I think.
Unfortunately, what you and I think has no bearing on the matter. Only what the standard "thinks" is important! ;-) Cite a passage from the standard that states that main program block-level variables may not be bound to external entities, and I will concede your point happily.
I'm just packing my bags and will be gone for the weekend, but I'll look when I'm back ...
Frank
On 19 Oct 2001, at 23:56, Frank Heckenbach wrote:
I think a "processor" according to the standard includes the compiler as well as the linker.
Right. ISO 7185, section 3.5:
"A system or mechanism that accepts a program as input, prepares it for execution, and executes the process so defined with data to produce results."
The linker would fall under the mechanism that "prepares it for execution."
I'm just packing my bags and will be gone for the weekend, but I'll look when I'm back ...
I believe that ultimately the question must be, "Does the standard prohibit or otherwise constrain a certain behavior?" If not, then it must be allowed, regardless of how abnormal or unusual such behavior may seem to be.
-- Dave
"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).
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).
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.
Warning the programmer of something that is clearly intentional is not warranted.
I don't consider such hiding an error. The fact that an outer block has an unaccessible identifier is a fact of life in such a case, and comes directly from scope rules. I have often done it deliberately, in order to protect the (relatively) global variable.
I am continuously having to replace the address in replies. Once more, what is the consensus on having a "reply-to: gpc@gnu.de" header in the lists output?
On 17 Oct 2001, at 22:02, CBFalconer wrote:
I don't consider such hiding an error.
I believe that you miss my point, which is not that such hiding is erroneous, nor that such hiding is undesirable, but rather that when the programmer defines two variables that __differ only in case__ in Pascal, it is likely to be a programming mistake. This is especially true if the programmer has more familiarity with languages that are case-sensitive than with Pascal.
If the programmer does this:
var CoGentry : integer; [...] CogEntry : integer;
...the compiler will produce a diagnostic because of the duplicate variable definition. However, with:
var CoGentry : integer;
procedure p; var CogEntry : integer;
procedure q; begin [...] CoGentry := 1; [...] end;
...no diagnostic is produced (because the program is legal), but the main block variable "CoGentry" is *not* assigned the value 1 as the programmer clearly intended.
It is in this latter case that a warning would be appropriate.
-- Dave
J. David Bryan wrote:
It is in this latter case that a warning would be appropriate.
I agree. Currently that's hard to do since GPC forgets about the case as soon as it parses an identifer, but this will be changed in the future (in order to preserve the case in error messages etc.), and then such a warning (optional) seems easy to implement.
Frank
On 17 Oct 2001, at 10:32, da Silva, Joe wrote:
...Peter Grogono (in his book 'Programming in Pascal') says words to the effect of....
Regrettably, though, books are not proof but at best only supporting evidence. Grinding through the standard is the only way to be sure.
Grogono also notes in section 7.1, "Sequential files," that:
"Some Pascal systems also insist that the standard file 'output' is mentioned in the program heading even if the program contains no call to write, so that there is a destination for error messages."
-- Dave
-
CBFalconer -
da Silva, Joe -
Frank Heckenbach -
J. David Bryan