Frank:
I'm running
gpc version 20000707, based on 2.95.2 19991024 (release)
with
set standard = "--standard-pascal" gpc $standard \ --transparent-file-names \ --no-mixed-comments \ -O$optimization \ -Wall \ $program.p -o $program
(these are part of a script, ftp://ftp.ncifcrf.gov/pub/delila/gpcc )
I really like being able to compile original version (classic?) Pascal and I plan to switch to gpc (or p2c if gpc fails) in the future when Sun gives up on Pascal.
So you wrote:
| in the course of cleaning up GPC, I plan to drop the following | obsolete "features". | | - `--standard-pascal[-level-1]' (and the corresponding compiler | directives). GPC has `--classic-pascal[-level-1]' now to | distinguish it better from Extended Pascal (which also is a | standard). | ... | If you have any objections against removing them, please respond | soon.
So would this make it impossible for me to compile "original" or "classical" Pascal? I don't know what the [-level-1] stuff is.
Or how do I change my script
Is there a web page that describes EVERY option now?
However, I agree with Chuck Falconer that it should be easy to have the standard!
Thanks,
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/
After reading this discussion, I fear we'll have to keep the ballast of redundant options. That'll teach me not to add any redundant features, unless required for compatibility reasons ...
Some comments, anyway.
toms@ncifcrf.gov wrote:
So would this make it impossible for me to compile "original" or "classical" Pascal?
Of course not. It was only about dropping one of two equivalent options.
I don't know what the [-level-1] stuff is.
AFAIK, the only difference is conformant arrays. You might want to look into the standard. (BTW, slight mistake of me: Level 1 is the default with `--{classic,standard}-pascal', level 0 is `--{classic,standard}-pascal-level-0'.)
Is there a web page that describes EVERY option now?
What's wrong with the chapter "Invoking GPC" of the GPC manual?
BTW, starting from the next GPC release, you can also do "gpc --help -v" to get a listing of all options of the various programs (if based on gcc-2.95.*). (Up to now, one had to do "`gpc --print-prog-name=gpc1` --help".)
However, I agree with Chuck Falconer that it should be easy to have the standard!
That's so in any case (modulo the existing bugs in GPC, of course).
CBFalconer wrote:
I don't misunderstand. However the only ISO standards that exist are 7185 and 10206. The latter labels itself as being "Extended Pascal".
And the former one as being "Pascal". So following this logic, the switch should be called `--pascal' which would be maximally confusing I think. ;-)
The cost of maintaining the present directives is basically the storage of two strings in the final code, and about the same in the sources.
Plus some entries in some tables and the documentation ... You might want to check the actual sources.
The "GNU standard" does not exist as a published and criticized document in the sense that the ISO standards do, and really has no more international standing than does Microsofts VBasic.
I never claimed so. Please don't obfuscate the issue with irrelevant remarks (or did you misunderstand me after all?).
Hidebound people such as myself view with horror any changes to installed software, especially any lack of backward compatibility.
Then you better stay with GPC 2.1 forever. The code is so freighted with unnecessary redundant and/or irrelevant "features". I don't mean the support for the various standards and non-standards, but e.g., many relics from its C origins and also such options (because neither of the *options* is standard in any way nor used by any other compiler AFAIK, i.e., we have a redundant duplication of private extensions, generally a very bad sign).
In order to remain (or rather, become) maintainable, the code needs to be cleaned up substantially. Of course, these options are just a minor thing. I've just done some more serious cleanup in the preprocessor (those interested can find the details in the ChangeLog in the next version). I hope this won't affect anyone -- fortunately neither of this is standard (and most of it even wasn't Pascal ;-).
Tom Schneider wrote:
I would vote for this!! But please leave the old definitions and clarify what they are precisely using ISO numbers. That information is not in the info gpc documentation (first few pages).
Well, in a 500 page manual, not everything can be in the first few pages. But, as said above, the chapter labeled "Invoking GPC: Command Line Options supported by GNU Pascal" might be worth a look for such questions ...
Source that is valid under 7185-0 should be valid everywhere (in the best of all possible worlds, Dr. Pangloss). I want to encourage such as far as possible. Use of any extensions beyond that causes portability problems somewhere or other.
Absolutely!!
Generally yes, but in some cases it's vice versa. E.g., there's no portable way in standard (including Extended) Pascal to create a given binary file format. (For details, I refer you to my discussions with Scott Moore in the newsgroups which resulted in him admitting to using assembler code and misusing variant records for the critical parts, neither of which is standard not portable ...)
The message from Dr. Thomas Schneider mailto:toms@ncifcrf.gov is indicative of the problems that deletion would cause. He obviously does not have an info installation, or it is obsolete, or he is unaware of it.
I was aware of it but don't think to use it. I find it awkward and complex compared to web pages, man pages, help flags, xman ... Thanks for the tip.
I can't see why info should be more complex than HTML -- in fact, it's almost the same, you have pages (info nodes) with links to each other and you can navigate forth and back. But anyway, the GPC manual can also be built in HTML format (as is done, e.g., on the web page).
I write the scripts myself but prefer not to have to muck with them. We could upgrade to the latest version but I try to stick to the standard so if it is supported I don't have to keep running to stay in place. If you drop --standard.pascal that will break the copies of my compile script that other people have. This would force me to make a variant of the script that figures out the version of gpc and then calls gpc the right way so that it does not bomb! How silly.
If you assume at least GPC 2.1, you can use `--classic-pascal', anyway. And if not, you'll probably have bigger problems keeping variants of the source code to work around bugs that were present in the old versions -- unless you were very lucky and hit none of the bugs ...
Tom Verhoeff wrote:
May I propose to call the option iso7185-pascal. The same number of key strokes as classic-pascal, but, in my humble opinion, unambiguous.
No, sorry. Not yet another one. Unless we could agree on removing the two existing options (say, after GPC 2.2) in favour of the new one.
da Silva, Joe wrote:
I certainly don't object to identifying explicit ISO standards by their respective numbers, as you suggest. OTOH, we shouldn't have a myriad of ways of doing (specifying) the same thing.
As you are no doubt aware, my concern with the "--standard-pascal" flag is that it infers that there is only one standard for Pascal. This is unfortunate, since the Extended Pascal Standard is just as much a standard, yet far too few people are even aware of it!
Exactly these two points are my concerns as well.
Anyway, if there is too much resistance to dropping the ambiguous "--standard-pascal" flag, we should at least discourage it's use in the documentation. For example, we could say something like : "--standard-pascal ... synonym for --classic-pascal".
Good idea.
Frank
Frank Heckenbach wrote:
After reading this discussion, I fear we'll have to keep the ballast of redundant options. That'll teach me not to add any redundant features, unless required for compatibility reasons ...
Some comments, anyway.
... snip ...
Another course, which I am sure you will not like :-) would be to make the default ISO7185-0, and use directives to expand that. However I recognize that practically noone will agree with me.
At any rate, I feel that gpc has been around too long to change such fundamental directives. I have no problem with discouraging its use.
In some ways this reminds me of the arguments that originally led to the -0 and -1 forms of the standard, which were much more heated, and delayed its release for a long time. The only deviation from J&W permitted by a large faction was specifying parameters of procedural parameters. That group considered conformal arrays an unwarranted extension.
CBFalconer wrote:
Frank Heckenbach wrote:
After reading this discussion, I fear we'll have to keep the ballast of redundant options. That'll teach me not to add any redundant features, unless required for compatibility reasons ...
Some comments, anyway.
... snip ...
Another course, which I am sure you will not like :-) would be to make the default ISO7185-0, and use directives to expand that. However I recognize that practically noone will agree with me.
At any rate, I feel that gpc has been around too long to change such fundamental directives. I have no problem with discouraging its use.
In some ways this reminds me of the arguments that originally led to the -0 and -1 forms of the standard, which were much more heated, and delayed its release for a long time. The only deviation from J&W permitted by a large faction was specifying parameters of procedural parameters. That group considered conformal arrays an unwarranted extension.
That's quite symptomatic for the problems I have with 7185. Unwarranted, is it? Well, without them you can only write routines that handle a fixed (or limited) number of array elements. Yes, I've seen such code, and I don't like it. Granted, even with conformant arrays, you have to put a limit in the array variables (only schemata can avoid this).
Without them, you can only resort to using linked lists etc. (which often entail a severe performance penalty by adding a factor of O(n)) or you put arbitrary limits in your programs ("you can only put 32 entries in that table" etc.). That's ok for teaching programs and was typical of 1980's programs, but really should be a no-go for modern programs.
Another point is the limited I/O in 7185 (only plain file reads, no defined file naming, no seeking, i.e., if you want to modifiy one record in a typed file, you have to copy the whole thing and replace one), and the lack of modularization, i.e., if you distribute some useful routines, you can only tell users to copy them into their source which is not only ugly IMHO (makes it harder to find the real code of a program between the "library" routines) but also a maintenance hell (each time you change something in the "library", every user has to change their source to incorporate the new code).
These issues occur routinely in "real world" programs and EP addresses them (schemata, Bind, SeekRead etc., modules) -- the examples listed are not all, but among the most important ones. Therefore I really cannot support recommending 7185 as the preferred standard.
Frank
-
CBFalconer -
Frank Heckenbach -
toms＠ncifcrf.gov