Tom Schneider wrote:
Thanks Frank. Would the following modification just leave the names alone properly?
Yes, but it would leave them alone like the compiler stores them, i.e. first letter capitalized, the rest lower-case. That might not be what you want. It is planned to change this as soon as we've got the qualified identifiers working (before that, doing so would cause name space conflicts with libc).
Also, since I haven't gotten around to applying patches like this, what would the command line be?
Change into the right directory and do `patch < patchfile'. You might need GNU patch (haven't tried Solaris' patch, so I don't know if it works with unified diffs, but after my recent experiences with other Solaris tools, I doubt it...), and take care of the directory which is the most common source of problems with patch (note the `-p' option to patch). Afterwards, of course, recompile and reinstall.
Frank
Frank:
Would the following modification just leave the names alone properly?
Yes, but it would leave them alone like the compiler stores them, i.e. first letter capitalized, the rest lower-case. That might not be what you want.
Definitely not!! This is silly because file names are case sensitive in Unix. Why not just leave the file names alone???????
It is planned to change this as soon as we've got the qualified identifiers working (before that, doing so would cause name space conflicts with libc).
I don't know what this means, but I'm puzzled why it is such a big deal. Names have scope in Pascal. So why can't all names in the code have the scope of the code and then there should be no way that there would be name space conflicts?! Why isn't this obvious to compiler writers?
Thanks for the instructions on using patch (it's simple!) but I realized that it is not good way to go because a version I provide to people would be quickly out of date, or I would be forced to keep patching the latest version (and eventually the patch would not work of course).
So either the option for simple file names goes into gpc or the molecular biologists using my programs won't use gpc. (p2c does work for people; gpc might be simpler if the name thing can be straightened out.)
(Do you really enjoy typing all the file names all the time??)
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/
Tom Schneider wrote:
Yes, but it would leave them alone like the compiler stores them, i.e. first letter capitalized, the rest lower-case. That might not be what you want.
Definitely not!! This is silly because file names are case sensitive in Unix. Why not just leave the file names alone???????
Pascal is case insensitive according to the ISO standards and to all the other de-facto standards I have heard of. For this reason it *must not* alter the behaviour of a program if you change the case of a letter in the source (except in string constants).
Since Unix file names are case sensitive and Pascal identifiers are case insensitive, it is silly to construct a compiler that maps Pascal identifiers to Unix file names without a well-defined case mangling. One can capitalize everything, or only the first character, or put everything to lower case. I think that the latter option is the most acceptable one.
BTW, how do other compilers handle file names with extensions? How do I read a file `foo.dat' from a Pascal file when the file name is derived from the identifiers in the program header?
It is planned to change this as soon as we've got the qualified identifiers working (before that, doing so would cause name space conflicts with libc).
I don't know what this means, but I'm puzzled why it is such a big deal. Names have scope in Pascal. So why can't all names in the code have the scope of the code and then there should be no way that there would be name space conflicts?! Why isn't this obvious to compiler writers?
These scopes are nothing that comes from itself; we have to write them. The linker has its name space. If we do not want our Pascal names to conflict with, say, the libc, we must feed the linker with names that cannot conflict. One way to do this is capitalization of the first letter which is not done in most C libraries. A better way will be introduced together with qualified identifiers, as Frank already pointed out.
Thanks for the instructions on using patch (it's simple!) but I realized that it is not good way to go because a version I provide to people would be quickly out of date, or I would be forced to keep patching the latest version (and eventually the patch would not work of course).
We can introduce this patch into GPC as an option (as you suggested initially), but it will put the file names to lowercase (or do some other well-defined case mangling). Leaving the case alone would violate the Pascal standards.
Is there really more than one compiler that derives the file name - including the case - from the Pascal identifiers in the header? How do those compilers deal with file name extensions?
(Do you really enjoy typing all the file names all the time??)
No. We use one of the mechanisms to specify the file name at run-time from a string.
UCSD Pascal:
reset ( MyFile, 'myfile.dat' );
Borland Pascal:
assign ( MyFile, 'myfile.dat' ); reset ( MyFile );
ISO Extended Pascal:
Var MyFile: File of whatever; B: BindingType;
unbind ( MyFile ); B:= binding ( MyFile ); B.Name:= 'myfile.dat'; bind ( MyFile, B ); reset ( MyFile );
All this works in GPC.
Greetings,
Peter
Peter:
Tom Schneider wrote:
Yes, but it would leave them alone like the compiler stores them, i.e. first letter capitalized, the rest lower-case. That might not be what you want.
Definitely not!! This is silly because file names are case sensitive in Unix. Why not just leave the file names alone???????
Pascal is case insensitive according to the ISO standards and to all the other de-facto standards I have heard of. For this reason it *must not* alter the behaviour of a program if you change the case of a letter in the source (except in string constants).
Since Unix file names are case sensitive and Pascal identifiers are case insensitive, it is silly to construct a compiler that maps Pascal identifiers to Unix file names without a well-defined case mangling. One can capitalize everything, or only the first character, or put everything to lower case. I think that the latter option is the most acceptable one.
I think so too. Lower case is the easiest to type.
BTW, how do other compilers handle file names with extensions? How do I read a file `foo.dat' from a Pascal file when the file name is derived from the identifiers in the program header?
The solaris compiler doesn't handle it:
program test(sun.down, output); var sun.down: text; begin writeln(sun.down,'Hello there!'); writeln(sun.down,'The test program has been compiled and runs ok!'); end.
gives:
Wed Sep 15 17:25:34 1999 test.p: 1 program test(sun.down, output); e 18450--------------------^--- Deleted real number 3 sun.down: text; e 18450--------^--- Deleted real number w 18610 line 5 - Unknown format radix down ignored, expecting hex or oct w 18610 line 6 - Unknown format radix down ignored, expecting hex or oct
The p2c converter also objects: "test.p", line 3: Warning: Expected a colon, found a '.' [227] test "test.p", line 5: Warning: No field called DOWN in that record [288] "test.p", line 6: Warning: No field called DOWN in that record [288]
It is planned to change this as soon as we've got the qualified identifiers working (before that, doing so would cause name space conflicts with libc).
I don't know what this means, but I'm puzzled why it is such a big deal. Names have scope in Pascal. So why can't all names in the code have the scope of the code and then there should be no way that there would be name space conflicts?! Why isn't this obvious to compiler writers?
These scopes are nothing that comes from itself; we have to write them. The linker has its name space. If we do not want our Pascal names to conflict with, say, the libc, we must feed the linker with names that cannot conflict. One way to do this is capitalization of the first letter which is not done in most C libraries. A better way will be introduced together with qualified identifiers, as Frank already pointed out.
I see (sort of). Naming all variables GPC_... seems like a good enough solution for me; I would never use a name like that so would not have a problem.
Thanks for the instructions on using patch (it's simple!) but I realized that it is not good way to go because a version I provide to people would be quickly out of date, or I would be forced to keep patching the latest version (and eventually the patch would not work of course).
We can introduce this patch into GPC as an option (as you suggested initially), but it will put the file names to lowercase (or do some other well-defined case mangling). Leaving the case alone would violate the Pascal standards.
Ok, I vote for mangling to lower case. Since I do this anyway it would be transparent for me.
Is there really more than one compiler that derives the file name - including the case - from the Pascal identifiers in the header?
Sure, p2c and the solaris compiler, which are the only ones I have available now use the file header name as given.
How do those compilers deal with file name extensions?
As the example above shows, they don't!
(Do you really enjoy typing all the file names all the time??)
No. We use one of the mechanisms to specify the file name at run-time from a string.
UCSD Pascal:
reset ( MyFile, 'myfile.dat' );Borland Pascal:
assign ( MyFile, 'myfile.dat' ); reset ( MyFile );ISO Extended Pascal:
Var MyFile: File of whatever; B: BindingType; unbind ( MyFile ); B:= binding ( MyFile ); B.Name:= 'myfile.dat'; bind ( MyFile, B ); reset ( MyFile );All this works in GPC.
Right, and I consider that to be "machine dependent" since such things are not available on all Pascal compilers. So I avoid them. (You had 3 examples, which means one does different things depending on the compiler. This would be painful to deal with all the time.)
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/
Peter Gerwinski peter@gerwinski.de el dÃa Tue, 14 Sep 1999 19:54:13 +0200, escribió:
These scopes are nothing that comes from itself; we have to write them. The linker has its name space. If we do not want our Pascal names to conflict with, say, the libc, we must feed the linker with names that cannot conflict. One way to do this is capitalization of the first letter which is not done in most C libraries. A better way will be introduced together with qualified identifiers, as Frank already pointed out.
what about feeding GPC_* to the linker ? (capitalization of the first letter will broke sooner or later, IMO) btw, FPC uses all uppercase, I think ...
Sergio
Received: (qmail 1196 invoked from network); 14 Sep 1999 05:03:42 -0000 Received: from tim.gerwinski.de (194.221.119.17) by tim.gerwinski.de with SMTP; 14 Sep 1999 05:03:42 -0000 Received: (qmail 893 invoked from network); 14 Sep 1999 04:57:44 -0000 Received: from faui45.informatik.uni-erlangen.de (root@131.188.2.45) by tim.gerwinski.de with SMTP; 14 Sep 1999 04:57:44 -0000 Received: from mi.uni-erlangen.de (root@helena.mi.uni-erlangen.de [131.188.103.20]) by faui45.informatik.uni-erlangen.de (8.9.1/8.1.49-FAU) with ESMTP id GAA26341 for frank@pascal.gnu.de; Tue, 14 Sep 1999 06:57:15 +0200 (MET DST) Received: from faui45.informatik.uni-erlangen.de (root@faui45.informatik.uni-erlangen.de [131.188.2.45]) by mi.uni-erlangen.de (8.9.1a/8.1.3-FAU) with ESMTP id GAA05514 for heckenb@mi.uni-erlangen.de; Tue, 14 Sep 1999 06:57:13 +0200 (MET DST) Received: from tim.gerwinski.de (tim.gerwinski.de [194.221.119.17]) by faui45.informatik.uni-erlangen.de (8.9.1/8.1.49-FAU) with SMTP id GAA26336 for heckenb@mi.uni-erlangen.de; Tue, 14 Sep 1999 06:57:12 +0200 (MET DST) Received: (qmail 822 invoked by uid 28); 14 Sep 1999 04:57:04 -0000 Delivered-To: gpc@gerwinski.de Received: (qmail 809 invoked by uid 10); 14 Sep 1999 04:56:42 -0000 Received: from goedel.fjf.gnu.de (goedel.fjf.gnu.de [10.1.6.1]) by goedel.fjf.gnu.de (8.8.8/8.8.8) with ESMTP id EAA17407 for gpc@gnu.de; Tue, 14 Sep 1999 04:21:57 +0200 Date: Tue, 14 Sep 1999 04:21:57 +0200 From: Frank Heckenbach frank@g-n-u.de Message-Id: 2EC12BEF.19990914042157.FOO-43FD.frank@g-n-u.de X-Mailer: smtphack 0.3.5 by Jan Andres To: gpc@gnu.de Subject: Re: GPC on Solaris 2.6 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=iso-8859-1 Sender: owner-gpc@gnu.de Precedence: bulk
Tom Schneider wrote:
Thanks Frank. Would the following modification just leave the names alone properly?
Yes, but it would leave them alone like the compiler stores them, i.e. first letter capitalized, the rest lower-case. That might not be what you want. It is planned to change this as soon as we've got the qualified identifiers working (before that, doing so would cause name space conflicts with libc).
Also, since I haven't gotten around to applying patches like this, what would the command line be?
Change into the right directory and do `patch < patchfile'. You might need GNU patch (haven't tried Solaris' patch, so I don't know if it works with unified diffs, but after my recent experiences with other Solaris tools, I doubt it...), and take care of the directory which is the most common source of problems with patch (note the `-p' option to patch). Afterwards, of course, recompile and reinstall.
Frank
Sergio A. Kessler wrote:
what about feeding GPC_* to the linker ? (capitalization of the first letter will broke sooner or later, IMO)
I was rather thinking of something like "MyProgram_MyFunction" or "MyUnit_MyFunction". When we introduce function overloading, additional suffixes indicating the parameter types can come up.
Peter
Peter Gerwinski peter@gerwinski.de el dÃa Wed, 15 Sep 1999 22:10:16 +0200, escribió:
Sergio A. Kessler wrote:
what about feeding GPC_* to the linker ? (capitalization of the first letter will broke sooner or later, IMO)
I was rather thinking of something like "MyProgram_MyFunction" or "MyUnit_MyFunction". When we introduce function overloading, additional suffixes indicating the parameter types can come up.
"GPC_MyUnit_MyFunction" I think this will never choke with the linker...
Sergio
Sergio A. Kessler wrote:
I was rather thinking of something like "MyProgram_MyFunction" or "MyUnit_MyFunction". When we introduce function overloading, additional suffixes indicating the parameter types can come up.
"GPC_MyUnit_MyFunction" I think this will never choke with the linker...
I'd find it a little egocentric of GPC to name all user functions after himself ... ;-)
Peter
Peter Gerwinski peter@gerwinski.de el dÃa Wed, 15 Sep 1999 22:28:21 +0200, escribió:
Sergio A. Kessler wrote:
I was rather thinking of something like "MyProgram_MyFunction" or "MyUnit_MyFunction". When we introduce function overloading, additional suffixes indicating the parameter types can come up.
"GPC_MyUnit_MyFunction" I think this will never choke with the linker...
I'd find it a little egocentric of GPC to name all user functions after himself ... ;-)
I don't think so... GPC must say "this is my territory, don't bother me"
I think is a clever namespace for GPC, well deserved. egocentry of a _product_ is not bad ... If you are going tu use Peter_MyUnit_MyFunction, well maybe that can be egocentric ... :)
Sergio
-
Frank Heckenbach -
Peter Gerwinski -
Sergio A. Kessler -
Tom Schneider