hybl@mbph.UUCP (Albert Hybl Dept of Biophysics SM) (12/31/88)
In message-ID: <1750@devsys.oakhill.UUCP>, Steven R Weintraub, Motorola Inc. Austin, Texas--cs.utexas.edu!oakhill!devsys!steve, summarized the results of his "UGLY" code problem run on about 24 different compilers. The test problem was: > K = 0 > DO 10 I = 1,10 > IF (I.EQ.1.OR.I.EQ.5) GOTO 10 > DO 10 J = 1,10 > IF (J.EQ.3) GOTO 10 > 10 K = K + 1 > PRINT *,K > END Half of the fortran implementations produced an ERROR diagnostic; the other half gave numeric answers having the disparate values 80, 82 or 92. Steve has shown that the USENET can be used to rapidly discover ambiguities in a language standard. Discussions in this newsgroup can propose corrective language to eliminate ambiguities from the standard. The real problem is how to incorporate the new language in a standard that has been chiseled in stone? Must we wait for FORTRAN8x? :-( After our law makers write and pass laws, the laws appear in a publication of state or federal statutes. The legislature will try to correct a discovered flaw or ambiguity in a law during their next session. In rare cases, a special session may be called to tackle the problem. Ambiguities in the law can also be resolved by the courts. All new laws, recently revised laws and notes of court cases are placed in the "Cumulative Annual Pocket Part" which is placed in the back of the appropriate volume of the statutes. The purpose of the Fortran ANSI X3.9 1978 standard "is to promote portability of FORTRAN programs for use on a variety of data processing systems." The result of Steve's survey shows that not even a simple double do loop is immune to ambiguity when tested for horizontal portability. His example and others (see Fortech Forum, Vol 2 pages 5-6; Fortran Forum, Vol 4 pages 19-20 and Fortran Forum Vol 6 pages 10-11) proves that computer language standards need a "Cumulative Annual Pocket Part." Without it, the hope for a horizontally portable standard is an exercise in futility. ---------------------------------------------------------------------- Albert Hybl, PhD. Office UUCP: uunet!mimsy!mbph!hybl Department of Biophysics Home UUCP: uunet!mimsy!mbph!hybl!ah University of Maryland CoSy: ahybl School of Medicine Baltimore, MD 21201 Phone: (301) 328-7940 (Office) ----------------------------------------------------------------------
ags@s.cc.purdue.edu (Dave Seaman) (01/03/89)
In article <583@mbph.UUCP> hybl@mbph.UUCP (Albert Hybl Dept of Biophysics SM) writes: >The test problem was: > >> K = 0 >> DO 10 I = 1,10 >> IF (I.EQ.1.OR.I.EQ.5) GOTO 10 >> DO 10 J = 1,10 >> IF (J.EQ.3) GOTO 10 >> 10 K = K + 1 >> PRINT *,K >> END > >Steve has shown that the USENET can be used to rapidly discover >ambiguities in a language standard. Discussions in this newsgroup ^^^^^^^^^^^ >can propose corrective language to eliminate ambiguities from ^^^^^^^^^^^ >the standard. The real problem is how to incorporate the new >language in a standard that has been chiseled in stone? Must >we wait for FORTRAN8x? :-( [some additional remarks about ambiguity deleted] ^^^^^^^^^ We must have been following different discussions. The discussion that I followed with respect to this code example arrived at the conclusion that it is flatly and unambiguously illegal. What is confusing the issue is that the standard does not require a standard-conforming processor to refuse to compile any program that is nonstandard. The processor is permitted to compile anything it likes, and to assign any meaning that the implementor deems convenient or desirable. This is a deliberate decision on the part of the standards committee. It will not and should not change. The reason is that changing this part of the standard would make it impossible for vendors to offer extensions to the language. Ruling out extensions would be a tragic error, indeed. Without them there is unlikely to be much progress in the standard. In other words, it is permissible for a standard-conforming processor to accept the input 'Twas brillig, and the slithy toves as a legal extended Fortran program, and for the program to print the answer, "42" when executed. A second processor might cause the result, "Lewis Carroll", to be printed. A third processor might complain of syntax errors and refuse to compile the program. All three behaviors are perfectly correct. None of them is ruled out by the standard, nor should they be. There is no ambiguity. Those who would tinker with the standard should first understand what it is that the standard attempts to prescribe and what the standard deliberately refrains from prescribing. >The purpose of the Fortran ANSI X3.9 1978 standard "is to >promote portability of FORTRAN programs for use on a variety >of data processing systems." The result of Steve's survey >shows that not even a simple double do loop is immune to >ambiguity when tested for horizontal portability. ^^^^^^^^^ Why not take another survey, based on the "slithy toves" example? One processor might say, "Unable to recognize statement." Another might say, "string too long". Another might say, "invalid expression on left side of assignment statement". It is theoretically possible, but unlikely, that some processor might actually accept it as a legal program. Does all this mean that the standard is ambiguous in failing to specify a behavior for the "slithy toves" input? Nothing is immune to ambiguity when subjected to tests that that are based on faulty logic. When tested correctly, by READING THE STANDARD, the apparent ambiguity disappears completely. The program is flatly illegal, which automatically makes it clearly and unequivocally non-portable. End of portability discussion. -- Dave Seaman ags@j.cc.purdue.edu
khb%chiba@Sun.COM (Keith Bierman - Sun Tactical Engineering) (01/04/89)
In article <583@mbph.UUCP> hybl@mbph.UUCP (Albert Hybl Dept of Biophysics SM) writes: > > history deleted > >Steve has shown that the USENET can be used to rapidly discover >ambiguities in a language standard. Discussions in this newsgroup >can propose corrective language to eliminate ambiguities from >the standard. The real problem is how to incorporate the new >language in a standard that has been chiseled in stone? As mentioned by others, the standard happens to "outlaw" the code in question. > >After our law makers write and pass laws, the laws appear in a >publication of state or federal statutes. The legislature >will try to correct a discovered flaw or ambiguity in a law >during their next session. In rare cases, a special >session may be called to tackle the problem. Ambiguities in >the law can also be resolved by the courts. All new laws, >recently revised laws and notes of court cases are placed in >the "Cumulative Annual Pocket Part" which is placed in the >back of the appropriate volume of the statutes. Our ANSI comittee is similar. It sits in judgement of x3.8-1978, and this question was brought to them, and they decided that the plain meaning of the standard is that the code is WRONG. Thus compilers are allowed to do whatever they want. > >The purpose of the Fortran ANSI X3.9 1978 standard "is to >promote portability of FORTRAN programs for use on a variety >of data processing systems." The result of Steve's survey >shows that not even a simple double do loop is immune to >ambiguity when tested for horizontal portability. His example >and others (see Fortech Forum, Vol 2 pages 5-6; Fortran >Forum, Vol 4 pages 19-20 and Fortran Forum Vol 6 pages 10-11) >proves that computer language standards need a "Cumulative >Annual Pocket Part." Without it, the hope for a horizontally >portable standard is an exercise in futility. > Issues brought before the comittee can be read about in the minutes of the meetings. Subscriptions are about $150/yr. Sign up as an Observer. A condensed and cleaned up version should appear periodically, and FORTEC Forum would be a good venue. Keith H. Bierman It's Not My Fault ---- I Voted for Bill & Opus
hybl@mbph.UUCP (Albert Hybl Dept of Biophysics SM) (01/08/89)
In message <3704@s.cc.purdue.edu> ags@s.cc.purdue.edu (Dave Seaman Purdue University) writes: > In article <584@mbph.UUCP> hybl@mbph.UUCP (Albert Hybl Dept of > Biophysics SM) writes: > >I think that the committee is without real power! They > >can not enforce the standard so their panegyrist says > >'When the code is WRONG, the compilers are allowed to > >do whatever they want.' If the name FORTRAN is not a > >registered trademark, anyone can use it to sell anything. > ---------------------------------------------------------------- > > Apparently you would prefer that the committee be selective in > which parts of the standard they should enforce. In particular, > you would like for them to ignore: <***** The lines prefixed by '}' were added by me for completeness. (A.Hybl) > } 1.1 _Purpose_ } } [...] The purpose of this standard is to promote } portability of FORTRAN programs for use on a variety } of data processing systems. } } [...] } > 1.3.2. _Exclusions_. This standard does not specify: > > [...] > > (4) The results when the rules of this standard fail > to establish an interpretation. > > and: > > 1.4. _Conformance_ > > [...] > > A processor conforms to this standard if it executes > standard-conforming programs in a manner that fulfills the > interpretations prescribed herein. A standard-conforming > processor may allow additional forms and relationships > provided that such additions do not conflict with the > standard forms and relationships. [...] > > -------------------------------------------------------------------- > If you want to lobby for this part of the standard to be > changed, that is certainly your right. But to accuse the > committee of "not enforcing the standard" PRECISELY BECAUSE > THEY ARE ENFORCING THE STANDARD seems like twisted logic to me. > Sections 1.3.2.(4) and 1.4 are irreconcilable with section 1.1. The key word in section 1.1 is _portability_; the intent is to provide horizontal portability among many different machines. Sections 1.3.2.(4) and 1.4 allow implementors to _extend_ the language in any way they want--spawning a plethora of dialects. Sections 1.3.2.(4) and 1.4 are antithetical to promoting a horizontal portable language standard. I am not opposed to extending the language. However, I strongly oppose the chaotic mechanism codified in sections 1.3.2.(4) and 1.4! How do the courts interpret a contract containing such contradictory clauses? I have cross posted this message to newsgroup misc.legal. Perhaps some good soul will contribute a legal opinion on this issue. First, let me give a real example. I am currently porting some fortran code that produced the following diagnostic: Common /control/ <==== natoms ****Error: Identifier too long Section 18 states the a "symbolic name consists of one to six, alphanumeric characters, the first of which must be a letter." Checking the **X blue book, we learn that a symbolic name can be 31 characters long. My compiler strictly enforces the existing standard as you can see above. By allowing **X to market its extended compiler, the standards committee has abandoned their stated intent to provide a horizontally portable fortran language standard! They are not serving the user community. Incidentally, this is an extension that I believe should have been added to the Language Standard many, many years ago. In House Report No. 94-1746 titled "Administration of Public Law 89-306, Procurement of ADP Resources by the Federal Government," we read: "This means that a user agency may adopt Cobol but employ unique features which will impede conversion." That was written in 1976. You can replace the word Cobol with Fortran and the word "conversion" with "portage" and notice that nothing has changed over the last thirteen years. The Brooks committee added: "Only when standard high level languages are developed and their use enforced will a barrier to effective competition be eliminated." Unless section 1.3.2.(4) is deleted and section 1.4 suitably amended, any hope for having a horizontally portable fortran language standard is _ignis fatuus_. Was the Brooks report an exercise in futility? ---------------------------------------------------------------------- Albert Hybl, PhD. Office UUCP: uunet!mimsy!mbph!hybl Department of Biophysics Home UUCP: uunet!mimsy!mbph!hybl!ah University of Maryland CoSy: ahybl School of Medicine Baltimore, MD 21201 Phone: (301) 328-7940 (Office) ----------------------------------------------------------------------
chris@mimsy.UUCP (Chris Torek) (01/08/89)
(I have deleted misc.legal as that group appears irrelevant.) In article <585@mbph.UUCP> hybl@mbph.UUCP (Albert Hybl Dept of Biophysics SM) writes: >Sections 1.3.2.(4) and 1.4 are irreconcilable with section 1.1. Not so. (1.3.2.(4) and 1.4 have to do with extensions and erroneous programs, while 1.1 says that the standard is to promote portability.) >The key word in section 1.1 is _portability_; the intent is to provide >horizontal portability among many different machines. Sections >1.3.2.(4) and 1.4 allow implementors to _extend_ the language in >any way they want--spawning a plethora of dialects. No: extensions must not conflict with the standard. They may not be arbitrary. They may only make erroneous programs correct; they may not make correct programs erroneous. >... let me give a real example. I am currently porting >some fortran code that produced the following diagnostic: > Common /control/ <==== natoms > ****Error: Identifier too long This is not FORTRAN code. Had it been legal F77 code, it would say something like COMMON /CONTRO/ NATOMS >Section 18 states the a "symbolic name consists of one to six, >alphanumeric characters, the first of which must be a letter." All well and good. >Checking the **X blue book, we learn that a symbolic name can >be 31 characters long. My compiler strictly enforces the >existing standard as you can see above. By allowing **X to >market its extended compiler, the standards committee has >abandoned their stated intent to provide a horizontally >portable fortran language standard! Not at all. That someone made use of a 31-character extension does not mean that F77 programs are not portable; it merely means that someone wrote something that is not an F77 program. Perhaps the person that wrote the program you are porting did not care about portability. He may well have used system-specific subroutine libraries as well. Again, the F77 standard cannot prohibit this. All it can do is provide one collection of things which, if used without extensions, guarantees portability. Your /control/ programmer stepped outside the provided collection by using a seven-character name. That one exception alone invalidates the applicability of the entire F77 standard. >They are not serving the user community. That is possible: I myself consider the six-character limit an abomination. (It is one reason---though far from the only one---that I do not write F77 programs. It may keep me from writing ANSI C programs as well.) The F77 standard might better have served the user community by demanding a larger minimum. The user community had a chance to ask the original ANSI committee to do this (as the user community had a chance with X3J11, the C standards committee). Some probably did; but not enough, and manufacturers (and ANSI committees) seem to be extremely reluctant to change. -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163) Domain: chris@mimsy.umd.edu Path: uunet!mimsy!chris
dick@ccb.ucsf.edu (Dick Karpinski) (01/09/89)
In article <585@mbph.UUCP> hybl@mbph.UUCP (Albert Hybl Dept of Biophysics SM) writes: > >} 1.1 _Purpose_ >} >} [...] The purpose of this standard is to promote >} portability of FORTRAN programs for use on a variety >} of data processing systems. While it is not explicit here, the standard is intended to permit the construction and use of portable programs, not to require that. If your compiler accepts legal portable programs, then the standard has done its job. If you write programs which follow the standard and do not use your vendor's extensions so that you can achieve the protability that you desire, then the standard has done its job. >Sections 1.3.2.(4) and 1.4 are irreconcilable with section 1.1. Not at all. More restrictive standards would not be as respected by vendors since often they only care about porting things to their systems. Some of the better vendors provide compiler switches to demand standard conforming programs. My advice it to get one of those and require that programs be tested in that way before they are accepted as complete. This CAN ensure that programs are (mostly) portable. >I am not opposed to extending the >language. However, I strongly oppose the chaotic mechanism >codified in sections 1.3.2.(4) and 1.4! You might be surprised how often you choose order over freedom. I am. >How do the courts interpret a contract containing such >contradictory clauses? Courts try to avoid ruling on such things. If some experts testify that they are not contradictory, as I would, the court will tend to agree. Courts feel safer that way. >First, let me give a real example. I am currently porting >some fortran code that produced the following diagnostic: > Common /control/ <==== natoms > ****Error: Identifier too long >Section 18 states the a "symbolic name consists of one to six, >alphanumeric characters, the first of which must be a letter." >Checking the **X blue book, we learn that a symbolic name can >be 31 characters long. My compiler strictly enforces the >existing standard as you can see above. By allowing **X to >market its extended compiler, the standards committee has >abandoned their stated intent to provide a horizontally >portable fortran language standard! They are not serving the >user community. Incidentally, this is an extension that I believe >should have been added to the Language Standard many, many >years ago. Here you have it. You say the standard fails when it is obvious that the code you are porting was not written to the standard. The implication is that you believe that no compiler should have permitted long names until the standard permitted it. At that time, presumably, all compilers would have been required to accept long names. Not very easy to accomplish, and that would have meant that no experience with compilers accepting long names would be available to the standards committee when they decided to permit them. Sounds pretty risky to me! I like it better the way it is: those who think it wise do it. If it works out well, they come back to the standards committee and advocate it for everybody else too. Much nicer. Dick Dick Karpinski Manager of Minicomputer Services, UCSF Computer Center UUCP: ...!ucbvax!ucsfcgl!cca.ucsf!dick (415) 476-4529 (11-7) BITNET: dick@ucsfcca or dick@ucsfvm Compuserve: 70215,1277 USPS: U-76 UCSF, San Francisco, CA 94143-0704 Telemail: RKarpinski Domain: dick@cca.ucsf.edu Home (415) 658-6803 Ans 658-3797
mccalpin@loligo.cc.fsu.edu (John McCalpin) (01/09/89)
In article <585@mbph.UUCP> hybl@mbph.UUCP (Albert Hybl Dept of Biophysics SM) writes: >In message <3704@s.cc.purdue.edu> ags@s.cc.purdue.edu (Dave Seaman >Purdue University) writes: >First, let me give a real example. I am currently porting >some fortran code that produced the following diagnostic: > Common /control/ <==== natoms > ****Error: Identifier too long >Section 18 states the a "symbolic name consists of one to six, >alphanumeric characters, the first of which must be a letter." >Checking the **X blue book, we learn that a symbolic name can >be 31 characters long. My compiler strictly enforces the >existing standard as you can see above. By allowing **X to >market its extended compiler, the standards committee has >abandoned their stated intent to provide a horizontally >portable fortran language standard! God help us all if it became illegal to have extensions to Fortran! The standard *allows* you to write a portable program. In the case above, you have simply chosen not to. That is certainly not the fault of the standards committee. If you are seriously intent on portability, then badger your vendor(s) into providing a compiler option to verify ANSI compatibility --- then use it religiously. >They are not serving the user community. The obvious question is: "which user community?" The vast majority of standard-conforming programs really do work on almost all commercially available compilers. If you are not satisfied with standard Fortran, then you have the obligation to voice your opinions in a formal statement to X3J3 when Fortran-8X comes out for review again (next summer?). If you do, your opinions will be counted just like everyone else's. If you cannot get your job done with standard Fortran, but you can get it done with extensions, then be thankful that the extensions exist, and request that the standards committee make them mandatory. >Incidentally, this is an extension that I believe >should have been added to the Language Standard many, many >years ago. Agreed! P.S. You should also be thankful that your compiler gave such a clear error message in the above code segment. Most are far less helpful. For example, one of the compilers I use dumps core if the program name exceeds 6 characters.... -- ---------------------- John D. McCalpin ------------------------ Dept of Oceanography & Supercomputer Computations Research Institute mccalpin@masig1.ocean.fsu.edu mccalpin@nu.cs.fsu.edu ------------------------------------------------------------------
mwolfe@ogccse.ogc.edu (Michael Wolfe) (01/09/89)
Many compilers have a command line switch to enforce strict ANSI77 compliance. Theoretically, users who compile with this switch have all illegal, disallowed, etc. constructs flagged; since all compilers should not only accept all legal F77 but should put the same interpretation on it, programs compiled with strict ANSI77 compliance should be portable. When the original program with the ambiguous illegal GOTO was compiled, did the compilers have an ANSI77 switch and was it set? I would like to see the results with this switch set; if strict ANSI77 interpretation is enforced, then all compilers should have the same result.
d25001@mic.UUCP (Carrington Dixon) (01/10/89)
In article <585@mbph.UUCP> hybl@mbph.UUCP (Albert Hybl Dept of Biophysics SM) writes: >First, let me give a real example. I am currently porting >some fortran code that produced the following diagnostic: > Common /control/ <==== natoms > ****Error: Identifier too long >Section 18 states the a "symbolic name consists of one to six, >alphanumeric characters, the first of which must be a letter." >Checking the **X blue book, we learn that a symbolic name can >be 31 characters long. My compiler strictly enforces the the standard ... Sorry, the strongest statment you can make is that your compiler enforces more of the standard than did the previous compiler. In order to diagnose "identifier too long" it had to recognise that "control" was an identifier. The X3.9-1978 not only madates that identifiers be no more than six characters long; it also defines the character set as consisting _ONLY_ of the UPPER-CASE letters. Thus, a compiler that adhered to the standard and only to the standard would claim that this line was meaningless. There are not too many compilers left that mandate upper-case only; even the IBM mainframe compiler now allows lowercase, but a standards comforming FORTRAN progam is one that -- inter alia -- is coded in upper- case only. Carrington Dixon UUCP: { convex, killer }!mic!d25001
hybl@mbph.UUCP (Albert Hybl Dept of Biophysics SM) (01/10/89)
In message <389@loligo.cc.fsu.edu> mccalpin@loligo.cc.fsu.edu (John McCalpin, Supercomputer Computations Research Institute) writes: > God help us all if it became illegal to have extensions to Fortran! God protect us from the extension writers! What is the logic or the compelling urgency for: CLOSE(...,DISPOSE='SAVE') ? It's in the **X blue book. You can substitute DISPOSE for the standard word STATUS and the synonym SAVE in place of the standard word KEEP. True this nonsense is easily filtered out by using an editor. As long as I need to use an editor, perhaps I should distribute my programs containing control loop written as: Do_kola 20 J=1,399 ! Do_kola means "go in circles" Do_kola block 20 konec ! "End" the do_kola loop The **X vendor example is saying 'more power to you.' If they can do it, so can I! We can all personalize our source code! Why bother with a standards effort at all? Most fortran programmers probably never hear of the American National Standards Institute, inc. or ANSI X3.9-1978; they learn to use fortran from their vendor's Language Reference Manual. They work under the delusion that they are using a "STANDARD" language thinking that they are producing "PORTABLE" code so long as it compiles without errors. Little do they know that it is an exercise in futility. ---------------------------------------------------------------------- Albert Hybl, PhD. Office UUCP: uunet!mimsy!mbph!hybl Department of Biophysics Home UUCP: uunet!mimsy!mbph!hybl!ah University of Maryland CoSy: ahybl School of Medicine Baltimore, MD 21201 Phone: (301) 328-7940 (Office) ----------------------------------------------------------------------
mccalpin@loligo.cc.fsu.edu (John McCalpin) (01/10/89)
In article <586@mbph.UUCP> hybl@mbph.UUCP (Albert Hybl) writes: > >Most fortran programmers probably never hear of the American >National Standards Institute, inc. or ANSI X3.9-1978; they >learn to use fortran from their vendor's Language Reference >Manual. They work under the delusion that they are using >a "STANDARD" language thinking that they are producing "PORTABLE" >code so long as it compiles without errors. >---------------------------------------------------------------------- >Albert Hybl, PhD. Office UUCP: uunet!mimsy!mbph!hybl If a person does not know that a Fortran standard exists and that each vendor's implementation may contain non-standard features then I think it would be inappropriate to call that person a "Fortran programmer" --- though I agree that many such persons exist. At the two universities that I have worked at, the problem is largely caused by science departments which expect graduate students to be competent programmers, but which do not require any formal training in such. The problem is compounded by computer science departments which will not lower themselves to teach a graduate-level course in structured, scientific programming in the Fortran-77 language. My Control Data Fortran reference manuals clearly delimit the standard and non-standard portions of the text. All non-standard features are presented with a grey (as opposed to white) background. If a person has the energy to read the 2-3 page introduction, the purpose of this curious typesetting becomes evident, and *poof*, no more excuse for not knowing about standard and non-standard Fortran. > Little do they know that it is an exercise in futility. ^^^^^^^^^^^^^^^^^^^ That seems to be your motto for Fortran programmers. Might I suggest that a little education may be in order.... -- ---------------------- John D. McCalpin ------------------------ Dept of Oceanography & Supercomputer Computations Research Institute mccalpin@masig1.ocean.fsu.edu mccalpin@nu.cs.fsu.edu ------------------------------------------------------------------
bobal@microsoft.UUCP (Bob Allison) (01/10/89)
In article <586@mbph.UUCP> hybl@mbph.UUCP (Albert Hybl Dept of Biophysics SM) writes: > > [...] > >Most fortran programmers probably never hear of the American >National Standards Institute, inc. or ANSI X3.9-1978; they >learn to use fortran from their vendor's Language Reference >Manual. They work under the delusion that they are using >a "STANDARD" language thinking that they are producing "PORTABLE" >code so long as it compiles without errors. Little do they know >that it is an exercise in futility. > >---------------------------------------------------------------------- >Albert Hybl, PhD. Office UUCP: uunet!mimsy!mbph!hybl Don't be ridiculous. Both IBM and DEC, and a whole bunch of other vendors print their manuals in two colors, distinguishing standard features from vendor extensions. I can just see this guy reading one of these manuals saying "Gosh, I wonder if they ran out of black ink?". (BTW, I think this is an excellent feature, and users should demand it of each vendor, for C too now). I can just see this same guy using DEC SYS$ calls, or vectorizer commands on his CRAY/CDC and figuring that this stuff will work when he ports it to his PC. Portability is a very difficult problem, and I believe it is demonstrable that even the most strictly standard-conforming program is not portable (File name syntax is a traditional problem). But let's not trivialize the very real problems of portability by assuming people are idiots. At that point, no solution is possible (or even desirable). Even relative portability requires very hard work and very intelligent programming. I thought that a previous note which indicated a possible reason why there is no standard behavior for SQRT(-16.) was very good (e.g., IEEE lets you specify whether you want an exception or a NaN). Starting from there, how can we develop a solution which is amenable to different floating point methods which still attempts to provide portability? Is such a feature worth the cost? Let's try to avoid polemics and attempt to formulate some solutions instead of cursing the night. Bob Allison ("Who turned off the %$&# lights!?")
khb%chiba@Sun.COM (Keith Bierman - Sun Tactical Engineering) (01/11/89)
In article <586@mbph.UUCP> hybl@mbph.UUCP (Albert Hybl Dept of Biophysics SM) writes: > examples of vendor extentions deleted > >The **X vendor example is saying 'more power to you.' If >they can do it, so can I! We can all personalize our source >code! Why bother with a standards effort at all? Because a non-trivial number of programmers do care, and do write portable code. > >Most fortran programmers probably never hear of the American >National Standards Institute, inc. or ANSI X3.9-1978; they >learn to use fortran from their vendor's Language Reference >Manual. They work under the delusion that they are using >a "STANDARD" language thinking that they are producing "PORTABLE" >code so long as it compiles without errors. Little do they know >that it is an exercise in futility. Some vendors (specifically DEC which you are using as an example) plainly mark what is standard and what is not. If you code using the blue words in the dec manual your code is not standard complying. Furthermore there is always the /ANSI options (which does let a bit of offending code by, but not much). There are USEFUL vendor extensions which when used with caution can be employed to get orders of magnitude speedup or readability enhancement. Given your mindset, you really should check into getting an Ada compiler. Keith H. Bierman It's Not My Fault ---- I Voted for Bill & Opus
levy@ttrdc.UUCP (Daniel R. Levy) (01/11/89)
In article <207@mic.UUCP>, d25001@mic.UUCP (Carrington Dixon) writes: > The X3.9-1978 not only madates that identifiers be > no more than six characters long; it also defines the character set as > consisting _ONLY_ of the UPPER-CASE letters. Could someone please quote chapter and verse. The paper "A Portable FORTRAN 77 Compiler", by Feldman and Weinberger, seems to imply a reading of the standard that calls for a monocase alphabet but doesn't specify what case. This shows (in the UNIX f77 compiler, which resulted from Feldman and Wein- berger's work) in the mapping of uppercase identifiers to lowercase for the linker, and the fact that lowercase values are expected for parameters in statements like OPEN(UNIT=1,STATUS='scratch') and lowercase values are returned by statements like INQUIRE(UNIT=1,ACCESS=CHRSTR). For all I know this is an erroneous interpretation, but they don't seem to think so (they name the only three ways they think their compiler deviates from the standard, and case handling isn't among them). It's a pain in porting code, obviously. -- Daniel R. Levy UNIX(R) mail: att!ttbcad!levy AT&T Bell Laboratories 5555 West Touhy Avenue Any opinions expressed in the message above are Skokie, Illinois 60077 mine, and not necessarily AT&T's.
khb%chiba@Sun.COM (Keith Bierman - Sun Tactical Engineering) (01/12/89)
In article <233@microsoft.UUCP> bobal@microsoft.UUCP (Bob Allison (uunet!microsoft!bobal)) writes: >I thought that a previous note which indicated a possible reason why there >is no standard behavior for SQRT(-16.) was very good (e.g., IEEE lets >you specify whether you want an exception or a NaN). Starting from there, >how can we develop a solution which is amenable to different floating point >methods which still attempts to provide portability? Is such a feature >worth the cost? Let's try to avoid polemics and attempt to formulate >some solutions instead of cursing the night. > Earlier drafts of f88 had exception handling as part of f88. This COULD have been employed, but entailed enough complexity and implementation issues that it was discarded for f88 (probably to return in f99!). For all ieee compliant machines there is standard conforming behavior. NaN is what is returned; and exceptions can be enabled in which case standard conforming behavior is to head for the user defined exception handler. Sun, HP, MIPS, Apollo, Multiflow, Convex and many others support this important ancillary standard. Consider the following code: print*,sqrt(-16.0) end Produces (on a sun) NaN Warning: the following IEEE floating point arithmetic exception occured in this program and were never cleared: Invalid Operand; While the f77 standard does not mandate this behavior, ieee floating point standard for binary arithmetic does. Keith H. Bierman It's Not My Fault ---- I Voted for Bill & Opus
khb%chiba@Sun.COM (Keith Bierman - Sun Tactical Engineering) (01/12/89)
In article <3131@ttrdc.UUCP> levy@ttrdc.UUCP (Daniel R. Levy) writes: >In article <207@mic.UUCP>, d25001@mic.UUCP (Carrington Dixon) writes: >> The X3.9-1978 not only madates that identifiers be >> no more than six characters long; it also defines the character set as >> consisting _ONLY_ of the UPPER-CASE letters. > >Could someone please quote chapter and verse. The paper "A Portable FORTRAN >77 Compiler", by Feldman and Weinberger, seems to imply a reading of the >standard that calls for a monocase alphabet but doesn't specify what case. >This shows (in the UNIX f77 compiler, which resulted from Feldman and Wein- >berger's work) in the mapping of uppercase identifiers to lowercase for the >linker, and the fact that lowercase values are expected for parameters in >statements like OPEN(UNIT=1,STATUS='scratch') and lowercase values are >returned by statements like INQUIRE(UNIT=1,ACCESS=CHRSTR). For all I know >this is an erroneous interpretation, but they don't seem to think so (they >name the only three ways they think their compiler deviates from the standard, >and case handling isn't among them). It's a pain in porting code, obviously. >-- Happy to oblige: 3.1 _FORTRAN Character Set_ The FORTRAN character set consists of twenty six letters, ten digits, and thirteen special characters. 3.1.1 _Letters_. A _letter_ is one of the twenty six charters A B C D ... Z (* which are what are commonly referred to as upper case *) 3.1.2 _Digits_ etc I don't have a list of bugs in the Feldman & Weinberger compiler, but it was quite extensive. The base f77 compiler which they produced was, to be brutally frank, one of the worst fortran compilers I have ever used. All vendors have put lots of work in to fix it up over the years, and unix compilers are now (for the most part) quite good. -- Keith H. Bierman It's Not My Fault ---- I Voted for Bill & Opus Keith H. Bierman It's Not My Fault ---- I Voted for Bill & Opus
jlg@lanl.gov (Jim Giles) (01/13/89)
I haven't read this group for some months so I missed this discussion. But, there is nothing ambiguous about this example in the standard. > >> K = 0 >> DO 10 I = 1,10 >> 1 IF (I.EQ.1.OR.I.EQ.5) GOTO 10 >> DO 10 J = 1,10 >> IF (J.EQ.3) GOTO 10 >> 10 K = K + 1 >> PRINT *,K >> END > According to the standard: 11.10.1 Range of a DO-Loop. The range of a DO-loop consists of all the executable statements that appear following the DO statement that specifies the DO-loop, up to and including the terminal statement of the DO-loop. So, the statement labeled 10 in the above is within the range of the innermost DO-loop. Now, again the standard: 11.10.8 Transfer into the Range of a DO-Loop. Transfer of control into the Range of a DO-loop from outside the range is not permitted. So, the conditional GOTO on the statement labeled 1 is NOT standard conforming since it transfers control to a statement that is inside the range of the inner loop. Confusion on this point only arises because Do-loops are allowed to share terminal statements - probably a bad idea, but we're stuck with it now. J. Giles
d25001@mic.UUCP (Carrington Dixon) (01/13/89)
> levy@ttrdc.UUCP (Daniel R. Levy) writes: >In article <207@mic.UUCP>, d25001@mic.UUCP (Carrington Dixon) writes: >> The X3.9-1978 not only mandates that identifiers be >> no more than six characters long; it also defines the character set as >> consisting _ONLY_ of the UPPER-CASE letters. >Could someone please quote chapter and verse. The paper "A Portable FORTRAN >77 Compiler", by Feldman and Weinberger, seems to imply a reading of the >standard that calls for a monocase alphabet but doesn't specify what case. Gladly, today we take our text from Chapter Three of the Book of ANSI X3.9-1978, verses 3.1 and 3.1.1: 3.1 FORTRAN Character Set The FORTRAN character set consists of twenty-six letters, ten digits, and thirteen special characters. 3.1.1 Letters A letter is one of the twenty-six characters: A B C D E F G H I J K L M N O P Q R S T U V W X Y Z This rules out the use of two distinct cases a la C or Modula-2 pretty certainly. I would have thought that it was pretty definite about which case to use too; even though it does not use the terms upper- or lower-case in this area. It has listed the characters that it defines as letters and they are all UPPERCASE. I would be interested to learn how Feldman and Weinberger justified their contention that the standard leaves the selection of case undefined. [IMHO a standard that mandated a single case and then neglected to define which case would be _seriously_ defective. The authors of X3.9-1978 do not appear to have been negligent in this regard.] The only explicit mention of case that I found in a hurried look through the standard was in Section 1.5, Notation Used in This Standard: (1) Special characters from the FORTRAN character set, uppercase letters, and uppercase words are to be written as shown, except where otherwise noted. (2) Lowercase letters and lowercase words indicate general entities for which specific entities must be substituted in actual statements. ... >This shows (in the UNIX f77 compiler, which resulted from Feldman and Wein- >berger's work) in the mapping of uppercase identifiers to lowercase for the >linker, and the fact that lowercase values are expected for parameters in >statements like OPEN(UNIT=1,STATUS='scratch') and lowercase values are >returned by statements like INQUIRE(UNIT=1,ACCESS=CHRSTR). For all I know >this is an erroneous interpretation, but they don't seem to think so (they >name the only three ways they think their compiler deviates from the standard, >and case handling isn't among them). It's a pain in porting code, obviously. This may be more in keeping with the way that UNIXphiles like to code, but I am afraid that it is in violation of what appears (to me at least) to be the plain wording of the standard. A conforming FORTRAN compiler may _allow_ lowercase values in these instances but one that _requires_ them is not conforming as I understand the term. Incidentally, I am NOT trying to defend the use of only uppercase beyond pointing out that those who wish to abhor all that is not allowed by the standard must be prepared to forego lowercase. Lowercase may be more esthetically pleasing and easier to type, etc., but it is not X3.9-1978 conforming. Carrington Dixon UUCP: { convex, killer }!mic!d25001
hirchert@uxe.cso.uiuc.edu (01/14/89)
Daniel R. Levy(levy@ttrdc.UUCP) asks: >In article <207@mic.UUCP>, d25001@mic.UUCP (Carrington Dixon) writes: >> The X3.9-1978 not only madates that identifiers be >> no more than six characters long; it also defines the character set as >> consisting _ONLY_ of the UPPER-CASE letters. >Could someone please quote chapter and verse. Page 3-2, lines 1-3 (section 3.1.5, paragraph 2): "Except for the currency symbol, the graphics used for the forty-nine characters must be as given in 3.1.1, 3.1.2, and 3.1.4. However, the style of any graphic is not specified." The graphics given 3.1.1 are upper-case letters. Note that this does _not_ prevent a vendor from mapping linker externals to lower case. (The operation of the linker is invisible insofar as the FORTRAN standard is concerned.) Likewise, it does not prevent a FORTRAN OPEN statement from accepting lower-case keyword values (as an extension) as long as the upper-case versions are accepted, too. It _does_ mandate that the values returned by INQUIRE (other than file name) must be in upper-case. Stu Feldman's a bright guy, but this is one he got wrong.
hybl@mbph.UUCP (Albert Hybl Dept of Biophysics SM) (01/17/89)
The United States is about to spend some 4 gigabuck mapping the human
genome. This is one of the best uses for which our tax dollars
can be used. Already the knowledge gained by genetic mapping is
contributing a better understanding of emphysema, hypertension, and
many genetic diseases. Progress toward treatment and cures are
just around the corner or even in clinical trial.
The mapping project will generate long strings of 'A's, 'C's,
'G's and 'T's. Sequences can be 1 to 1 million or more nucleic acids
in length. When searching for a promoter region on a gene
or asking which restriction enzymes will cut a DNA sequence,
a researcher needs to locate the position of a short recognition
sequence on the long DNA sequence. He could, for example, use
the intrinsic INDEX function in an expression like:
J = INDEX(DNA,'CGGCCG')
At first glance FORTRAN appears to be a useful language to use for
such projects. However, because it is so full of quirkish ambiguities
and because it is no longer a portable language, using it is
engaging in an exercise in futility.
In message <3704@s.cc.purdue.edu> ags@s.cc.purdue.edu (Dave Seaman,
Purdue University) claims:
> ...THEY ARE ENFORCING THE STANDARD ...
Consider the following program:
PROGRAM FUTILE
* Repeat this program after increasing the value of K until the program fails.
PARAMETER (K=24)
CHARACTER AND(K)*1
CHARACTER DNA*(K)
EQUIVALENCE (DNA,AND)
*
DNA(K-23:K) = 'An exercise in futility!'
PRINT *,K
PRINT *,(AND(J+K-24),J=1,24)
STOP
END
What does the ANSI X3.9-1978 standard say are the maximum allowable
sizes for the character array AND(K)*1 and the character variable
DNA*(K)? Are the maximum allowable sizes the same? Does it allow
the equivalence statement? I believe that most of the standards
committee intended that values should be the same and the limit
determined by the amount of available core in the processor executing
the job. The equivalence is legal so long as the variables are legal.
Rush to you vendor's FORTRAN Language Reference Coloring Book,
what does it say and in what color does it say it? Why should
DNA*256 be LEGAL on most systems but ILLEGAL when using RM fortran on
an IBM PC/AT or the SVS fortran on an AT&T 3B1? Why is DNA*501
illegal when using CMS fortran on an IBM4341? Why is DNA*513
illegal when using FTN fortran on an UNISYS 1100? Why is DNA*1001
illegal when using **X Fortran on a VAX VMS machine? Of the compilers
that I have used, only the XLA+ fortran on an AT&T 3B2 machine
does what I think the standard specifies. DNA*750000 works!
When I increased the value of K to 1000000 and above I obtained
to following diagnostics:
(k=1000000) Ld fatal: Cannot complete output file a.out. Write error
(K=1097152) Assembly: Trouble Writing; probably out of temp-file space
Surely a FORTRAN language validation suite would have prevented such
abominable implementations of the standard. Not even the most
convoluted interpretation of sections 1.3.2.(4) and 1.4 can justify such
capriciousness. The purpose of the Fortran ANSI X3.9 1978 standard
"is to promote portability of FORTRAN programs for use on a variety
of data processing systems." Pray tell, based on the above examples how
can anyone say that the maximum length for a string variable is
predicable or portable?
Steve Weintraub has shown that the USENET can be used to rapidly
discover ambiguities in a language standard. Discussions in this
newsgroup can propose corrective language. The real problem is how
to incorporate the new language into the standard.
Clearly sections 1.3.2.(4) and part of section 1.4 MUST
be deleted! The standards making body should produce a
"Cumulative Annual Pocket Part" that is published in FORTRAN forum
and other appropriate media. There must be an adjudication
mechanism. The standards organization must have a registered
trademark for the FORTRAN Language. A Fortran Validation Suite must
be created, updated and revised annually. Before a compiler
is allowed to use the trademark, it must pass the validation tests.
Unless a Fortran Standardizing Organization is willing and able to
legally enforce the Standard, this discussion will have been nothing
but an exercise in futility.
----------------------------------------------------------------------
Albert Hybl, PhD. Office UUCP: uunet!mimsy!mbph!hybl
Department of Biophysics Home UUCP: uunet!mimsy!mbph!hybl!ah
University of Maryland CoSy: ahybl
School of Medicine
Baltimore, MD 21201 Phone: (301) 328-7940 (Office)
----------------------------------------------------------------------lipa@polya.Stanford.EDU (William J. Lipa) (01/17/89)
program tautology
while (.true.) do
type *, 'If my program uses extensions to Fortran,'
type *, 'then it is not portable and not Fortran.'
end do
endmccalpin@loligo.cc.fsu.edu (John McCalpin) (01/17/89)
In article <587@mbph.UUCP> hybl@mbph.UUCP (Albert Hybl Dept of Biophysics SM) writes: Consider the following program: >* Increase the value of K until the program fails. > PARAMETER (K=24) > CHARACTER AND(K)*1,DNA*(K) > EQUIVALENCE (DNA,AND) > DNA(K-23:K) = 'An exercise in futility!' > PRINT *,K,(AND(J+K-24),J=1,24) > END >What does the ANSI X3.9-1978 standard say are the maximum allowable >sizes for the character array AND(K)*1 and the character variable >DNA*(K)? >Albert Hybl, PhD. Office UUCP: uunet!mimsy!mbph!hybl Of course *you* are wainting in the wings with the *right* answer to this problem. What number do you suggest? It sounds like you want a number of several millions so that you can fit your genome sequences in. That is nice, except that it means that in *your* world, no standard IBM PC could ever have a valid Fortran language system, because there ain't enough core.... The problem is NOT that the standard allows machine/implementation- dependent features, but rather that the standard does not seem to require that the vendor ever tell us what these implementation-dependent features are! I, for one, would like any standard-conforming Fortran system to include a document page listing the implementation-dependent limitations, e.g.: maximum size of character string (e.g. char*K string) maximum integer value maximum and minimum floating-point values maximum array size (e.g. 64kB on old IBM PC compilers) argument range limits for ALL intrinsic math functions etc.... I am sure I am forgetting many more.... Such info, available in one place, woudl make porting of standard-conforming Fortran code much easier. -- ---------------------- John D. McCalpin ------------------------ Dept of Oceanography & Supercomputer Computations Research Institute mccalpin@masig1.ocean.fsu.edu mccalpin@nu.cs.fsu.edu ------------------------------------------------------------------
ags@s.cc.purdue.edu (Dave Seaman) (01/17/89)
In article <587@mbph.UUCP> hybl@mbph.UUCP (Albert Hybl Dept of Biophysics SM) writes: >Rush to you vendor's FORTRAN Language Reference Coloring Book, >what does it say and in what color does it say it? Old-timers may recall that around 30 years ago, a satirical work known as "The Computer Programmer's Coloring Book" was popular. On one of the pages was a picture of a stick man, with the caption: This is a FORTRANner. Color him naive. -- Dave Seaman ags@j.cc.purdue.edu
hybl@mbph.UUCP (Albert Hybl Dept of Biophysics SM) (01/19/89)
In message <454@loligo.cc.fsu.edu> mccalpin@loligo.cc.fsu.edu (John McCalpin: Supercomputer Computations Research Institute) writes: >In article <587@mbph.UUCP> hybl@mbph.UUCP (Albert Hybl >Dept of Biophysics SM) writes: Consider the following program: >>* Increase the value of K until the program fails. >> PARAMETER (K=24) >> CHARACTER AND(K)*1,DNA*(K) >> EQUIVALENCE (DNA,AND) >> DNA(K-23:K) = 'An exercise in futility!' >> PRINT *,K,(AND(J+K-24),J=1,24) >> END >>What does the ANSI X3.9-1978 standard say are the maximum allowable >>sizes for the character array AND(K)*1 and the character variable >>DNA*(K)? > >Of course *you* are waiting in the wings with the *right* answer to >this problem. What number do you suggest? I would like the maximum allowable sizes for the character array AND(K)*1 and the character variable DNA*(K) to be the same!!!.... If they were the same, then PARAMETER(K=nnnn) could be used to adapt a program to fit whatever available core the target machine may have. I think that the existence of the PARAMETER statement and the vagueness of the ANSI X3.9-1978 standard were meant to allow for processor size differences and not to give implementors a vehicle to demolish the standard. >... It sounds like you want a number >of several millions so that you can fit your genome sequences in. That >is nice, except that it means that in *your* world, no standard IBM PC >could ever have a valid Fortran language system, because there ain't >enough core.... CHARACTER AND(30000)*1 ! Is allowed on an IBM PC/RM fortran CHARACTER DNA*256 ! Is NOT--the compilation fails! Believe me, I want a portable fortran for the IBM PC, but when the implementor limits the string length of a character variable to the range 1-255, he has entered a possible winner in the FORTRAN demolition derby! I was pleased to see that the AT&T XLA+ fortran compiler do what I think the standard specifies; that is, the EQUIVALENCE (DNA,AND) statement works over the whole range of allowable AND(K)*1. As to wanting several million bytes, I'd use them if they were available; but--please give me the dynamic memory allocation routines like malloc, calloc, realloc, and free from the C language. I see no need to over utilize core, when I can process only a portion of the character string/array at a time. >... I, for one, would like any standard-conforming Fortran >system to include a document page listing the implementation-dependent >limitations, e.g.: > maximum size of character string (e.g. char*K string) maximum size of character array (e.g. CHAR*1 ARRAY(K)) > maximum integer value > maximum and minimum floating-point values > maximum array size (e.g. 64kB on old IBM PC compilers) maximum bytes per WRITE N, LIST > argument range limits for ALL intrinsic math functions > etc.... Hmmm, that sounds like an exercise in futility. ---------------------------------------------------------------------- Albert Hybl, PhD. Office UUCP: uunet!mimsy!mbph!hybl Department of Biophysics Home UUCP: uunet!mimsy!mbph!hybl!ah University of Maryland CoSy: ahybl School of Medicine Baltimore, MD 21201 Phone: (301) 328-7940 (Office) ----------------------------------------------------------------------
richard@calvin.EE.CORNELL.EDU (Richard Brittain) (01/20/89)
On our Harris HCX/UX system here, the only way to read data from a tape
into a fortran program is to pass a variable of type CHARACTER*NNN to the
library routine. Of course, the maximum size for NNN is only about 1k,
unless you hunt for the obscurely documented compiler switch which allows
it to be larger (thankfully, as large as most of our data tape records).
Now that is, to my mind, a non-intuitive use of a character variable and about
as non-portable as they come.
Richard Brittain, School of Elect. Eng., Upson Hall
Cornell University, Ithaca, NY 14853
ARPA: richard@calvin.ee.cornell.edu
UUCP: {uunet,uw-beaver,rochester,cmcl2}!cornell!calvin!richardd25001@mic.UUCP (Carrington Dixon) (01/21/89)
In article <588@mbph.UUCP> hybl@mbph.UUCP (Albert Hybl Dept of Biophysics SM) writes: > --please give me the >dynamic memory allocation routines like malloc, calloc, realloc, >and free from the C language. OK. Take them -- please !-) I do wonder, though, how you expect to use them in a standards- conforming FORTRAN program. Seriously, the only language that comes close to being defined as rigorously as you seem to desire is Ada(TM). I don't think that there is any hope of getting that kind of "thou shalt not" definition into the FORTRAN standard -- it would break too much working code and make the FORTRAN-8X flap seem like an amicable dialog between friends who agree on almost everything. I don't know enough about Ada to say if it would be a reasonable choice for your project or not, but if you really need (or just desire) a language whose standard is defined with the kind of rigor that you suggest for FORTRAN, then Ada is your only 'real world' choice. Carrington Dixon UUCP: { convex, killer }!mic!d25001
kaufman@maxzilla.Encore.COM (Lar Kaufman) (01/24/89)
In article <3728@s.cc.purdue.edu> ags@s.cc.purdue.edu (Dave Seaman) writes: >In article <587@mbph.UUCP> hybl@mbph.UUCP (Albert Hybl Dept of Biophysics SM) writes: >>Rush to you vendor's FORTRAN Language Reference Coloring Book, >>what does it say and in what color does it say it? > >Old-timers may recall that around 30 years ago, a satirical work known as "The >Computer Programmer's Coloring Book" was popular. The first Fortran manual I found that didn't put me to sleep by chapter 3 is "A FORTRAN Coloring Book" by Roger Emanuel Kaufman, MIT press, 1978. I still use it for a reference - it is remarkably useful and lucid. I am a professional technical writer, and I wish I had the opportunity to do my books as engagingly as Dr. Kaufman did this one. It is also the only textbook I have ever seen that was done entirely by hand - text, illustrations, and index. There are numerous (corny) jokes and vivid imagery which help you retain what is (let's face it) a rather dry and boring subject. This rates a special disclaimer. I am not, to my knowledge and complete confidence, related to Dr. Kaufman. The only linkage between his name and mine is that I probably wouldn't have picked up his book initially had he not had that most admirable of last names. The only drawback to this book is that it is probably out of print. However, the book also came with a money-back guarantee on the back cover: "If you do all the programming problems at the end of this book and don't learn FORTRAN in the process, you deserve your money back. *Offer VOID within or without U.S.A." -lar Lar Kaufman <= my opinions Fidonet: 1:322/470@508-534-1842 kaufman@multimax.arpa {bu-cs,decvax,necntc,talcott}!encore!kaufman