Why these original FORTRAN quirks?
in [Fortran]
|
From: Richard Steiner on 22 Oct 2006 03:59 Here in alt.folklore.computers, Gary Scott <garylscott(a)sbcglobal.net> spake unto us, saying: >Richard Steiner wrote: > >> I've worked with the 6-character limit since 1988, and I still find it >> easier to read the variable names in those older FORTRAN programs than >> I do in the newer C++ code I have to support because the FORTRAN folks >> were *far* more disciplined in their variable naming conventions. > >I tend to agree in that I never had much difficulty with 6 character >names because there was considerable discipline used in the naming >conventions we used. However, moderately increasing the lengths beyond >6 does provide a modest improvement in readability and you can still use >a disciplined approach to your naming convention with increased >flexibility. Yes, I could see 10 or 12 characters being quite useful, but things get tedious to type quite quickly. :-( Even eight (8) characters would be an improvement, though. -- -Rich Steiner >>>---> http://www.visi.com/~rsteiner >>>---> Mableton, GA USA Mainframe/Unix bit twiddler by day, OS/2+Linux+DOS hobbyist by night. WARNING: I've seen FIELDATA FORTRAN V and I know how to use it! The Theorem Theorem: If If, Then Then.
From: Brooks Moses on 22 Oct 2006 04:32 glen herrmannsfeldt wrote: > Similarly, > > A=B+C > > now seems obvious for arrays, but not structures. Again, structures > containing elements where the + operator makes sense could easily > have this operation added. type polar_complex real :: angle, magnitude end type With arrays, elementwise addition is virtually always the right thing to do for A=B+C. With structs, it's only occasionally the right thing to do, even if it's possible. I think a reasonable goal for default meanings of operators is that they should generally do no harm. A default to elementwise addition, is, I think, likely to do as much harm as good. For cases where elementwise addition doesn't make semantic sense, I'd much rather have the compiler tell me "you haven't implemented that operator yet" than give me some default that isn't what I expect at all. - Brooks -- The "bmoses-nospam" address is valid; no unmunging needed.
From: Brooks Moses on 22 Oct 2006 04:37 Richard Steiner wrote: > Here in alt.folklore.computers, > Gary Scott <garylscott(a)sbcglobal.net> spake unto us, saying: >>I tend to agree in that I never had much difficulty with 6 character >>names because there was considerable discipline used in the naming >>conventions we used. However, moderately increasing the lengths beyond >>6 does provide a modest improvement in readability and you can still use >>a disciplined approach to your naming convention with increased >>flexibility. > > Yes, I could see 10 or 12 characters being quite useful, but things get > tedious to type quite quickly. :-( > > Even eight (8) characters would be an improvement, though. Well, there isn't any need to speak of that in the counterfactual tense. Fortran 95 allows up to 31 characters. :) - Brooks -- The "bmoses-nospam" address is valid; no unmunging needed.
From: glen herrmannsfeldt on 22 Oct 2006 05:38 Brooks Moses wrote: (snip) > type polar_complex > real :: angle, magnitude > end type > With arrays, elementwise addition is virtually always the right thing to > do for A=B+C. With structs, it's only occasionally the right thing to > do, even if it's possible. It would take some study to see what fraction it made sense for, and what fraction it didn't. Even in this case, assigning 0 isn't bad. > I think a reasonable goal for default meanings of operators is that they > should generally do no harm. A default to elementwise addition, is, I > think, likely to do as much harm as good. For cases where elementwise > addition doesn't make semantic sense, I'd much rather have the compiler > tell me "you haven't implemented that operator yet" than give me some > default that isn't what I expect at all. For mathematicians, elementwise multiplication doesn't make sense, but many languages supply it. BASIC is the only one I know that supplies matrix multiply but not elementwise multiply. If you would rather have new operators added instead of reusing the existing operators, I won't argue against it. I am only suggesting that in some cases structure expressions make sense as elementwise expressions, and it is convenient for the language to allow for them. As for generally doing no harm, I think you would have to exclude all floating point arithmetic operations, as they tend to do harm more often than one would like. -- glen
From: Terence on 22 Oct 2006 06:31
Returning to the original question:- glen herrmannsfeldt noted: Ancient_Hacker <grg2(a)comcast.net> wrote: > > Anybody have any idea why good old FORTRAN had these quirks: > > >>>> (1) three-way arithmetic IF > As I understand it, a three way branch instruction on the 704. Many early IBM Computers used a Compare Arithmetic Register to Memory instruction which set status latches. This instruction is really identical to a Subtract instruction but does not save the result in the arithmetic register. So in a pseudo language we would have:- COMPARE REGISTER TO ADDRESS BRANCH ON NEGATIVE TO ADDRESS BRANCH ON ZERO TO ADDRESS (optional) BRANCH TO ADDRESS (or else fall through). Where you replace these concepts with the corresponding machine instruction. This matches almost all of the early IBM machines I worked with except the different-concept 1620. And the three-way Arithmetic IF very well suited this instruction structure. Bachus's group were after all, trying to replace the arduous hand-coding of programs with something more intuitive than what assembler offered, and the intent was to make efficient use of the IBM computers expected to use the compiler design. |