Peter:
For folks on the mailing list, the issues I'm concerned with are:
1. Gpc asks for file names. I have some 200 pascal programs
http://www.lecb.ncifcrf.gov/~toms/delila/delilaprograms.html
and each uses as many as 10 file names. Typing all this is a waste of my time. No other compiler I've encountered (Sun, vax, CDC Cyber (!)) does this. So I'm suggesting that there be an option on gpc to simply use the file name given in the header line of the program.
2. When gpc asks for the file name, it capitalizes it. On Unix file names are case sensitive, so this is setting up for confusion and ambiguity. So I am suggesting that file names be left alone. No changing of case from what the user does.
...
I can't do this because it would force my 200 programs to become compiler specific. No compiler I have encountered in the past 15 years ever forced me to do this.
So all standard Pascal compilers use the same mechanism to derive the external file name from the variable name? Interesting. If so, GPC should do the same.
Well, I don't know about ALL or how standard they are. I am currently working on Sun's rather stable complier (but hey, I found bugs in it too!! ;-).
The CDC Cyber - an ancient beast running an OS called Kronos - had a really neat feature that I was sorry to see go when I went to Unix. One would type the program name followed by a series of file names:
for
program x(a,b,c,d,output);
one could type
x,1,,2,3
Kronos would:
map 1 to a use file b for b map 2 to c map 3 to d
That was rather handy and very quick to type. Such an option - in which if one didn't type anything at all one would get all file names to default - would be VERY handy.
How do they deal with inconsistent capitalization?
Sun flags it as an unidentified symbol:
program x(output); var a: integer; begin A := 5; end.
4 A := 5; E 18420---------^--- Undefined variable In program x: E 18240 A undefined on line 4
So it evidently just treats "a" and "A" as different symbols.
program x(output); var a: integer; A: char; begin a := 5; A := '!'; end.
I tried that and it compiled just fine.
Is it really that difficult to have an option to just use the name as given in the header line? [...]
The only problem is the capitalization issue; see below.
While it may be true that Pascal is supposed to be case-insensitive, it turns out that under Solaris it is case sensitive. This has already forced me to be *consistent* with the names I use, which is not unreasonable.
Yes, I am also consistent with capitalization of my Pascal sources, but the compiler must not depend on this.
This is a matter of standards. It actually scares me that one can have that second program above and not realize the situation! However, I DO like the idea of being consistent throughout the program: either A or a, but not both. I do not like the idea of the program changing the capitalization that I set.
It seems to me that you must have put a mechanism IN to capitalize the first letter. All I'm saying is that it would be best simply to remove that mechanism. It would be simpler, cleaner and never confusing.
It would make user identifiers crash with libc functions while linking.
Oy. I had this problem when I first started working with Sun. It is irritating!!! In Pascal I used to have my main procedure named ... main of course. Well that is illegal because it conflicts with the underlying C compiler! (I renamed them 'themain', ugh.) What's really annoying is that I could easily have a variable named main inside the procedure, since its scope would be protected.
*************************************************************** * SCOPE SOLUTION: * * Why can't the concept of symbol scope be applied to the * * entire program? Then there would be no conflict at all and * * Pascal names would be independent of the damn C complier * * names!!! * ***************************************************************
On the Sun compiler, this code compiles just fine:
program x(output); var a: integer; A: char; procedure x(z: char); procedure main(j: char); begin writeln(output,j); end; begin main(z); end; begin a := 5; A := '!'; x(A); end.
Though the following compiles, it fails rather weirdly:
program x(output); var a: integer; A: char; procedure main(z: char); procedure themain(j: char); begin writeln(output,j,' in themain'); end; begin writeln(output,z,' in main'); themain(z); end; begin a := 5; A := '?'; main(A); end.
gives: ----- in main in themain ---- So using the word 'main' messes up the variable transfer. If I change the name to xmain, it works ok: ---- ? in main ? in themain ----
What we could do is to keep the capitalization of the first occurrence of each identifier for use with the option you are suggesting.
My initial suggestion was that if you are going to ask for file names, the string you should give should match the name in the pascal program header. *Anything* *else* is setting up for confusion on the part of the user!
It would also be a good thing for error messages and such.
No, it would lead to confusion on operating systems like Unix which are case sensitive for file names. Just leave the names alone, don't modify them.
For public names however, we must use something that does not overlap with the name space of the C library.
See above scope suggestion.
Introducing this would be non-trivial. It would also be possible (and much easier) to put the identifier into lower case in order to derive the file name.
If you make *ANY* changes in the name, you are setting it up to cause trouble at some point. I would think that ignoring the case would be simpler.
Since the discussion is now about suggested changes to GPC, I think it's really time to move it to the GPC mailing list gpc@gnu.de. Be welcome to forward or cite my mail there.
Ok, here goes!
Hmm. Thats funny. On
http://agnes.dida.physik.uni-essen.de/~gnu-pascal/support.html#archives
it gives
gpc@hut.fi.
as the mailing list name. Which is correct?
(While we are at it, would you mind removing the periods at the ends of emails and urls on that page? They make it harder to cut and paste. Thanks.)
Thanks for your thoughts,
You're welcome.
Peter
-- Peter Gerwinski, Essen, Germany, http://home.pages.de/~Peter.Gerwinski/ Maintainer GNU Pascal - http://home.pages.de/~GNU-Pascal/ - gpc-19990118 PGP key on request - 6C 94 45 BE 28 A4 96 - 0E CC E9 12 47 25 82 75 *** Vote against SPAM! ********* http://www.politik-digital.de/spam/ ***
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 http://www.lecb.ncifcrf.gov/~toms/