Why these original FORTRAN quirks?
in [Fortran]
|
From: Gary Scott on 21 Oct 2006 12:07 Richard Steiner wrote: > Here in alt.folklore.computers, > nospam(a)see.signature (Richard Maine) spake unto us, saying: > > >><jmfbahciv(a)aol.com> wrote: >> >> >>>Yes that is a problem. One way to avoid that is to design >>>your naming procedures to ensure exlclusivity. This is not >>>difficult. >> >>It wasn't so easy in the days of 6-character name length limits. It was >>hard enough to do comprehensible names without special conventions for >>uniqueness. > > > Not that hard, actually. You simply adopt a logical naming procedure > for variables and source files. > > We used to (and still) assume that all 6-character identifiers were > external in nature (that is, were DEFINEs or PARAMETERs located in an > external file (named SOMETHING-F) which was later INCLUDED by programs > that wanted to use that set of definitions. > > All local variables were either five characters or one character (the > latter was reserved for local loop counters only and was usually I, J, > K, etc.). > > For external parameters/defines, we tend to use the USAS convention of > using the first two characters for the filename and the last four for > the variable itself. This works well because USAS freespace files tend > to have two-character names. > > Thus, the length of the file AP would be something like APLGTH or maybe > APFLEN, an IATA city code stored in AP would be APCITY, etc. We try to > be fairly consistent across different files in our applications, so a > record length is always xxLGTH regardless of file, etc. > > At NWA, using a non-USAS environment, we tended to use the following > conventions: > > (1) The first two characters were always the two-character application > code (e.g., "WX" for weather, "GW" for Gross Weights, etc.). > > (2) The third letter tended to be unique for each file the define or > parameter was being used for. > > This way, one knew that "WXSxxx" was always a define of a data element > inside the Weather Station File, "WXGxxx" was always a define of a data > element inside the Weather Grid file, etc. Thus, the length of the > Weather Grid file would be WXGLEN, the time stored for a METAR in the > WX Station file might be WXSTIM and its text might be WXSTXT, etc. > > 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. It used to be common to name OS/macro/JCL commands with two letter mnemonics: CO for copy, PR for print, ED for edit. You quickly run into the situation where the same two "obvious" characters could mean multiple things. -- Gary Scott mailto:garylscott(a)sbcglobal dot net Fortran Library: http://www.fortranlib.com Support the Original G95 Project: http://www.g95.org -OR- Support the GNU GFortran Project: http://gcc.gnu.org/fortran/index.html Why are there two? God only knows. If you want to do the impossible, don't hire an expert because he knows it can't be done. -- Henry Ford
From: Terence on 21 Oct 2006 19:13 Short comment on Gary's note on:- > >>It wasn't so easy in the days of 6-character name length limits. > > 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. My memory is that at least one of the earlier Fortran compilers I worked with allowed SIX-letter variable names only in the main program. And FIVE-letter names as variables in subroutines and functions. Although I learned Fortran in the early sixties, I seem to think this rule caught my attention working with IBM main-frames compilers, Hewlett-Packard and Modcomp minicomputers (and their fortran compilers) all at the same time in the seventies . So maybe one of these had the quirk and I learned to play safe. So to this day I have the fixed habit of using FIVE letters only for variables (and fixed format). And surely a suffix ".f" (which I saw as advice to someone in this forum) is equivalent to the normal ".for" to indicate a fixed-format program to an F90 compiler ?
From: Dan Nagle on 21 Oct 2006 19:59 Hell0, Terence wrote: <snip> > And surely a suffix ".f" (which I saw as advice to someone in this > forum) is equivalent to the normal ".for" to indicate a fixed-format > program to an F90 compiler ? Any such convention is compiler-specific, although your statement is not a bad generalization. Most compilers have switches to control the assumed source format. -- Cheers! Dan Nagle Purple Sage Computing Solutions, Inc.
From: Brian Inglis on 21 Oct 2006 22:08 On Fri, 20 Oct 2006 21:46:05 +0000 (UTC) in alt.folklore.computers, glen herrmannsfeldt <gah(a)seniti.ugcs.caltech.edu> wrote: >In comp.lang.fortran Brian Inglis <Brian.Inglis(a)systematicsw.invalid> wrote: >(snip on structure expressions) > >> C89 says: >> "6.3.16.1 Simple Assignment >> Constraints > >> -- the left operand has a qualified or unqualified version of a >> structure or union type compatible with the type of the right;" > >> so structures and unions can be passed as arguments to and returned as >> results from functions and assigned e.g. >> struct t v1, v2 = { 0 }; v1 = f( v2 ); >> is valid. > >But nothing more than that. > >You can't use a struct with any other operators. >You can't assign a scalar expression, or even a constant to >a struct. > >v1=0; >v1=v2+1; >v1=v2+v2; And what would these operators mean applied to a struct? You need C++, but it's not intuitively obvious what those operators would mean, so using member functions with meaningful names would be more obvious e.g. zero_stuff, inc_stuff, add_stuff. The first one, if an initialization, could be done similarly to the static const below, like v2 above, or: static const struct t t_init = { 0 }; v1 = t_init; >Anything other than v1=v2; or v1=f(v2); doesn't work (at least in C90). There is member reference and operation. ;^> -- Thanks. Take care, Brian Inglis Calgary, Alberta, Canada Brian.Inglis(a)CSi.com (Brian[dot]Inglis{at}SystematicSW[dot]ab[dot]ca) fake address use address above to reply
From: Richard Maine on 21 Oct 2006 22:44
Terence <tbwright(a)cantv.net> wrote: > My memory is that at least one of the earlier Fortran compilers I > worked with allowed SIX-letter variable names only in the main program. > And FIVE-letter names as variables in subroutines and functions. The Fortran 66 "basic language" standard had a 5-character limit (on everything). I don't recall using any such compilers myself, but the existance of that standard suggests that such things probably existed. There were actually two "Fortran 66" standards with separate numbers, although people referring to Fortran 66 almost invariably mean the other one. I hadn't even realized there were two until a few years ago. Well, that few years is probably half a decade or so by now. > And surely a suffix ".f" (which I saw as advice to someone in this > forum) is equivalent to the normal ".for" to indicate a fixed-format > program to an F90 compiler ? Not so "surely". Such suffix conventions are compiler-specific. There is a moderately common convention, but far from universal. Windows compilers tend to be a bit different from others, though with some overlap. Some compilers don't use suffix conventions at all. So while it might be the case, it is not "surely" so. -- Richard Maine | Good judgement comes from experience; email: last name at domain . net | experience comes from bad judgement. domain: summertriangle | -- Mark Twain |