Frank:
... So if I want to cut and paste to search for the name in my program, it fails.
I didn't like this as well, and that's exactly why I've brought up the issue.
Oh good!
Why not take the first [occurrence] of a variable as the name to use on all output?
The first, or the most recent one, that's still a question. After some experimenting, there seem to be points for both ways. I'm implementing the latter now (though it should be easy to change). So, e.g.:
program Baz;
procedure Foo; var BaR: Integer; begin end;
begin WriteLn (bar) end.
will complain about an unknown identifier `bar', not `BaR' ...
I would strongly vote for using the first occurrence because that is the one which is the definition! If one is disciplined, then all later cases should follow the definition!
Note: only Germans like to capitalize all nouns!
I know, and that's not the reason why this rule was introduced (long ago). Rather it was to avoid asmname conflicts with libc routines etc. -- see, e.g., Pierre's mail for detailed explanations.
Oh. I think that you should either:
1. ignore the conflicts and let the user deal with them. Warn the user that a conflict has occurred.
or
2. protect the user from such conflicts so they never have to deal with them.
I want to be able to write 'vanilla flavor' Pascal programs that will work on many compilers. I have great hope that GPC is the end-all solution, but even so it is nice to allow my programs to work on other compilers. So I do not want to be forced to change variable names because of conflicts specific to the internal workings of a particular compiler. For example, the fact that I cannot name a procedure 'main' on the Sun compiler is rather obnoxious - I was forced to rename all my 'main' procedures to 'themain', and even have a tool for modifying Pascal programs to make such variable-name switches:
http://www.lecb.ncifcrf.gov/~toms/delila/worcha.html
... written in vanilla Pascal of course!
Tom
Dr. Thomas D. Schneider National Cancer Institute Laboratory of Experimental and Computational Biology Frederick, Maryland 21702-1201 toms@ncifcrf.gov permanent email: toms@alum.mit.edu (use only if first address fails) http://www.lecb.ncifcrf.gov/~toms/