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) ----------------------------------------------------------------------
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
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
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 <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