From: Scott A. Moore
Hello,
A minor "it would be nice" request for you all.
I have been working on personally certifying the compliance of several ISO 7185 compilers this last week. You all are no doubt aware that the ISO 7185 specifies header parameters such as:
program test(input, output, file1, file2);
...
Although ISO 7185 does not specify the mechanisim, most implementors have given a means to connect the header parameter files to external, named files, including the original Wirth implementation of Pascal on the CDC 6000 computer. GPC does this as well. Here is a roundup of the compilers that I have either tested or have seen the results of testing on:
1. Irie Pascal, header parameters are automatically connected to command line parameters in order of appearance, I.e.,
program test(input, output, file1, file2);
appear on the command line:
ivm test thisfile thatfile
2. Compaq Pascal, header parameters can be connected to files by special command line syntax:
test $input=thisfile $output=thatfile
3. CDC 6000 Pascal (Wirths original), the command parameters are specified in a SCOPE operating system statement:
EXECUTE,TEST(INPUT,OUTPUT,THISFILE,THATFILE)
4. GPC, each unfufilled program parameter is prompted for:
test
Input file `File1': thisfile Input file `File2': thatfile
5. IP Pascal, header parameters are automatically connected to command line parameters in order of appearance, I.e.,
program test(input, output, file1, file2);
appear on the command line:
test thisfile thatfile
The ISO 7185 method of specifying program parameters is not much use without the (standard undefined) means of connecting them to outside parameters, so this is good.
However, I also note that GPC does not provide a means to automatically connect these files, but requires operator intervention to do this. I wonder if I could talk you guys into implementing a slight enhancement to GPC, that is completely compatible with your present methodology ?
The method of connecting program parameters to command line parameters is attractive. The FPC authors have expressed an interest in implementing it.
For GPC, to keep compatibility with your present methods, I would suggest:
If a program parameter file is present, and it can also be determined that a command line argument exists for it, then get that from the command line instead of prompting the user. This continues for as many parameters as exist in the program header.
The command line parameters (argv/argc) can either be reduced at the left to remove the program parameters used as filenames, or the command line can be left alone. There are arguments for each method.
Anyways, this would serve to further unify the operation methodologies of existing (and popular) ISO 7185 compilers, which is, I am happy to say, a growing club.
Thank you for the consideration.
Scott Moore wrote:
I have been working on personally certifying the compliance of several ISO 7185 compilers this last week. You all are no doubt aware that the ISO 7185 specifies header parameters such as:
program test(input, output, file1, file2);
...
Although ISO 7185 does not specify the mechanisim, most implementors have given a means to connect the header parameter files to external, named files, including the original Wirth implementation of Pascal on the CDC 6000 computer.
[...]
However, I also note that GPC does not provide a means to automatically connect these files, but requires operator intervention to do this. I wonder if I could talk you guys into implementing a slight enhancement to GPC, that is completely compatible with your present methodology ?
Thanks for your comments. Actually GPC supports a way, but it's not very well documented:
foo --gpc-rts=-nfile1:thisfile --gpc-rts=-nfile2:thatfile
Yes, I know, it looks strange, but that's intentional, so it doesn't easily conflict with other uses of command line parameters. (Of your examples, it might be closest to Compaq Pascal.)
For GPC, to keep compatibility with your present methods, I would suggest:
If a program parameter file is present, and it can also be determined that a command line argument exists for it, then get that from the command line instead of prompting the user. This continues for as many parameters as exist in the program header.
Altogether GPC has 6 ways (unless I'm missing some ;-) of connecting file variables to file names (the latter 3 are for program parameters, the first 3 are also for other file variables -- they can, of course, use the command line parameters, using non-standard Borland extensions ParamCount, ParamStr).
1. Additional parameter to Reset/Rewrite/...
2. Bindings (Extended Pascal)
3. `Assign' (Borland Pascal)
4. Asking the user (as you mentioned)
5. `--gpc-rts=-n...'
6. `--transparent-file-names' (compile time option, causes file names to correspond to variable names; was added on user request)
Given this, it might not matter much to add a 7th way, if it's still deemed necessary. (It should not be very difficult to implement.) I myself am neutral on this, since in my own programs I'll use the programmatic ways (#1 - #3) anyway.
Frank
----- Original Message ----- From: "Frank Heckenbach" ih8mj@fjf.gnu.de To: gpc@gnu.de Sent: Tuesday, March 23, 2004 4:45 AM Subject: Re: Minor issue: command line parameters
Scott Moore wrote:
I have been working on personally certifying the compliance of several ISO 7185 compilers this last week. You all are no doubt aware that the ISO 7185 specifies header parameters such as:
program test(input, output, file1, file2);
...
Although ISO 7185 does not specify the mechanisim, most implementors have given a means to connect the header parameter files to external, named files, including the original Wirth implementation of Pascal on the CDC 6000 computer.
[...]
However, I also note that GPC does not provide a means to automatically connect these files, but requires operator intervention to do this. I wonder if I could talk you guys into implementing a slight enhancement to GPC, that is completely compatible with your present methodology ?
Thanks for your comments. Actually GPC supports a way, but it's not very well documented:
foo --gpc-rts=-nfile1:thisfile --gpc-rts=-nfile2:thatfile
Yes, I know, it looks strange, but that's intentional, so it doesn't easily conflict with other uses of command line parameters. (Of your examples, it might be closest to Compaq Pascal.)
I'm fine with that. Even if the method is a little obscure, its automatable, which means that someone can write a script to process this any way they want. That wasn't possible with the user prompt method.
For GPC, to keep compatibility with your present methods, I would suggest:
If a program parameter file is present, and it can also be determined that a command line argument exists for it, then get that from the command line instead of prompting the user. This continues for as many parameters as exist in the program header.
Altogether GPC has 6 ways (unless I'm missing some ;-) of connecting file variables to file names (the latter 3 are for program parameters, the first 3 are also for other file variables -- they can, of course, use the command line parameters, using non-standard Borland extensions ParamCount, ParamStr).
Additional parameter to Reset/Rewrite/...
Bindings (Extended Pascal)
`Assign' (Borland Pascal)
Asking the user (as you mentioned)
`--gpc-rts=-n...'
`--transparent-file-names' (compile time option, causes file names to correspond to variable names; was added on user request)
Given this, it might not matter much to add a 7th way, if it's still deemed necessary. (It should not be very difficult to implement.) I myself am neutral on this, since in my own programs I'll use the programmatic ways (#1 - #3) anyway.
No, I'm happy. It wasn't a standards issue in any case.
Frank
-- Frank Heckenbach, frank@g-n-u.de, http://fjf.gnu.de/, 7977168E GPC To-Do list, latest features, fixed bugs: http://www.gnu-pascal.de/todo.html GPC download signing key: 51FF C1F0 1A77 C6C2 4482 4DDC 117A 9773 7F88 1707
-
Frank Heckenbach -
Scott Moore