Tom Schneider wrote:
Frank Heckenbach wrote:
BTW, calling it a bug is a bit strange, anyway. In Pascal, even occurrences of an identifier referring to the same declaration can have different capitalizations; the same applies to different declarations (e.g., local vs. global) as well. Therefore, all this is an optional warning, not an error.
It is not a Pascal bug in the sense that the program will still compile correctly since Pascal accepts any capitalization. However, it is a bug in GPC in the sense that the compiler treats the variables inconsistently.
It's one thing to disagree in a discussion, but if you keep offending me (by calling an intentional decision which is not contrary to any standard a "bug" or not "legitimate"), I'll quit this discussion and might killfile you. Last warning (definitely no pun intended)!
(Again, it is a warning about *identifiers*, not about *declarations* (variables etc.).)
Especially in German it means that the word is either the beginning of a sentence or a noun, right? Are there cases in German - I bet you could find or make some! - where the meaning of the sentence changes dramatically if you were to change the case of a noun?
Yes, and there are cases (in German and probably in other languages) where even the same sentence with the same capitalization can have different meanings. Natural languages are (slightly) ambiguous. Formal languages are meant to be an improvement (in this aspect), so such comparisons are void.
FOR EXAMPLE. I am a molecular biologist, so the letters A, C, G and T have great significance. In some programs I might want to capitalize these to fit the convention in molecular biology. But in another piece of the code I may decide that 'c' is to be the name of a character read in.
In your situation, I *really* wouldn't *ever* use `c' for such a variable, in order to avoid confusion, cf. the `GotHere' example below.
Irrelevant warnings that I can't get rid of make it MUCH more difficult to locate the important warnings!
In general I agree with this statement. But it doesn't apply here.
Worse, if one of my students decides to write code, I have to worry about what they have done in modules that I'm NOT working on. Suppose I ask them to write a procedure for me and they pick a "non-standard" capitalization that doesn't match something I'm doing?
Use `-Widentifier-case-local'.
Saying that I should use external files is NOT A SOLUTION because there is no standard that all compliers use for reading such files and if I used that approach,
If you use "external files" to mean modules, and "modules" (above) to mean include files or similar, it may help to use more standard terminology.
This is why the GPC convention of capitalizing the first letter of an identifier when giving errors or warnings is painful.
Where does GPC still do so?
Frank Heckenbach wrote:
that the GPC code is not efficient.
Not really. This way, the capitalization can be checked right after a word (identifier or keyword) is recognized. When doing it after distinguishing between keywords and various kinds of declarations, there would be more places to add the checks.
You of course know the compiler guts and I don't. But what you are saying implies that the mechanisms for capitalization checking and scope checking are separated. In that sense the compiler appears not to be efficient.
Lexing and parsing are separated, as in every other compiler and interpreter in the world. Or what do you mean???
Frank Heckenbach wrote:
Because I don't see a "case sensitive interpretation" of Pascal code.
There may be other Pascal compilers which are case-sensitive, which is obviously non-standard. Our general attitude to non-standard compilers is to be at best backwards-compatible, which this warning surely makes it.
If there were (theoretically) a compiler that understood case with scope correctly, then this current design would not be compatible.
There are such compilers, e.g., every C compiler in the world. I don't recall that we plan to be compatible to them. Such a compiler obviously wouldn't be a Pascal compiler.
Frank Heckenbach wrote:
I recently recompiled a project containing some seven thousand lines of Pascal code distributed over some twenty units. A couple of years ago when it was last compiled, gpc didn't have the identifier-case checking feature. During the recent recompile, I was overwhelmed with casing complaints. Some of them were legitimate: same variable referred to by different casings.
Again, Pascal isn't concerned with the capitalization of identifiers referring to the same declaration any more than it is with that of identifiers referring to different declarations. If you consider one thing more "legitimate" than the other, that's your opinion, but please don't state it as a fact.
No, he means that some of the warnings were appropriate and some were not, according to the scope of the variable. The inappropriate ones get in the way of finding the legitimate ones.
So you substitute "legitimate" for "appropriate". Playing with words, nothing more. Next time, you might want to add "IMHO" or something, otherwise I see no reason to reply to unfounded claims.
Frank Heckenbach wrote:
Well, I was about to write "these comparisons go too far" before I read this paragraph, but now it's really too much! Emotions in a Pascal program, eh? ;-)
EMOTIONS ARE USED IN TEXT! (SorryForYelling.) Haven't you ever embedded something like that into your code?
In comments perhaps. If you do this in your program code regularly, you might want to get professional help, sorry.
Frank Heckenbach wrote:
Let's stick to Pascal based arguments, perhaps?
This is NOT a "Pascal" issue. It is a GPC issue.
Incidentally the P in GPC stands for Pascal, in case you didn't know.
I think that we all agre that in the language Pascal itself, case is not relevant. The issue here is about programmers and what happens when they attempt to use capitalization to help them understand AND DOCUMENT the code better. If the capitalization does not follow the scope rules of the identifiers, then the programmer will OFTEN have trouble.
If the assumptions of the programmer do not match the behaviour of the compiler, then the programmer will also have trouble (perhaps not as often, but sometimes in more tricky ways, see the example below).
My preferred solution is to avoid both, by using capitalization (for declarations if you will) consistently *and* avoiding different declarations having the same identifier with different capitalization. IMHO that's the only way to pretend to be case-sensitive without getting bitten. It's a little restriction, compared to a real case-sensitive language, but one I'd rather accept than getting surprising bugs.
Frank Heckenbach wrote:
You forgot:
- NamesConsistingOfMultipleWords (most frequent in my experience)
True. But using different concatenations resulting in the same identifier (such as `FooBar' and `FoobAr' -- I know there are real examples of this, I just don't have them in mind right now) is
There's the case I mentioned above:
http://www.gnu-pascal.de/crystal/gpc/en/mail7664.html [...] Got Here is quite different from Go There!
Yes, thanks for digging it out.
Frank Heckenbach wrote:
asking for trouble in a case-insensitive language. In C, you can do this and get away with it. In Pascal, sooner or later, you might use those names in the same scope and get a conflict.
No. If they are within the same scope, then there SHOULD be a conflict.
So to repeat my argument with this concrete example, here's a (made up) code fragment which shows the problems I'm referring to. Adding the `with' statement (because it makes it more comfortable to access the `Target' field twice) shadows, in the statement between, `GoThere' by `Field[Position].GotHere'. This is a tricky bug, hard to find if you don't know it.
Of course, such unintended shadowing can happen with the same capitalization as well. But in this case, the programmer can notice it, whereas a programmer who thinks case-sensitively, as you suggest, will not even understand the problem.
You might argue that a declaration-capitalization-warning will catch this case. But only if compiled on such a compiler (you mentioned using other compilers) and if enabled (it's optional as you know). Whereas the identifier-capitalization-warning can catch it even before the actual conflict arises, as soon as the two identical identifiers with different capitalization are introduced, if it's compiled just *once* with GPC and the warning enabled. So you can notice it earlier and prevent the actual conflict by renaming things (there are always choices to rename things).
program Foo;
const Max = 20;
type t = record { Target of link from this position } Target: Integer;
{ Position was already visited } GotHere: Boolean end;
var Position: Integer; Field: array [1 .. Max] of t; PositionsToTry: set of 1 .. Max;
procedure p; var NewPosition: Integer;
{ Set the current position to NewPosition. Return True if successful. } function GoThere: Boolean; begin if NewPosition in [1 .. Max] then begin Position := NewPosition; GoThere := True end else GoThere := False end;
begin
{ Try next position } NewPosition := Position + 1; if GoThere then Exit; { OK }
{ Try other positions on the list } for NewPosition in PositionsToTry do if GoThere then Exit; { OK }
{ Try target of link from current position } with Field[Position] do begin NewPosition := Target; if GoThere then Exit; { Ouch! } Target := 0 { invalidate link } end;
end;
begin end.
Frank Heckenbach wrote:
And we should divide programmers into two groups, one that does not care about capitalization and the second that cares. The first group produces lot of meaningless variation, but they are irrelevant for the discussion since they wish no warning. The second group IMHO is much more likely to associate meaning with capitalization.
So do I, yet I prefer to avoid different capitalizations of the same identifier (see above).
That's fine, but it does not suit everyone, and you apparently haven't run into a condition where there would be a conflict.
I have, and I liked to get the warning. See the example above. Even if there was no direct conflict such as the one shown above yet, you are inviting one if you use the same identifier with different capitalization for different purposes. Pretending to be case-sensitive is nice, but you have to respect the limits.
Frank Heckenbach wrote:
So is the lack of `endif', and a few other things IMHO. We can't change the fundamentals of Pascal, I'm afraid.
Agreed! But this discussion is not about changing the fundamentals of Pascal. It's about changing how GFP reacts to case inconsistency when it is requested to check for case consistency. Programmers will expect the case usage to match the scope of the variable.
Since I'm no programmer (according to your definition), I can't help you here, sorry.
Frank