Why these original FORTRAN quirks?
in [Fortran]
|
From: jmfbahciv on 19 Oct 2006 06:15 In article <1hne8p2.vgiivpx9358gN%nospam(a)see.signature>, nospam(a)see.signature (Richard E Maine) wrote: ><jmfbahciv(a)aol.com> wrote: > >> In article <1hndkwm.1gruz8s1ka6txoN%nospam(a)see.signature>, >> nospam(a)see.signature (Richard Maine) wrote: >> <snip> >> >> >If you use the name of the intrinsic for an external procedure, ... >> >> I'd chop your nine edge off. There is no excuse to do this. > >There's no excuse for not being able to forsee multiple decades into the >future? That seems a little harsh. :-( I misread the post. I thought it said that it declared an existing intrinsic as something else. I'd have colored the card red when proofing the keypunch job. > >Elsewhere in my post, I mentioned that one of the ways this comes up is >when new intrinsics are added to the language. Yes that is a problem. One way to avoid that is to design your naming procedures to ensure exlclusivity. This is not difficult. DEC had naming conventions company-wide and we taught our customers those naming conventions. We also always (at least in the days when DEC was still DEC) reserved a foodlybar for the customer with the promise that we would never ever use the foodlybar. /BAH <snip> /BAH
From: jmfbahciv on 19 Oct 2006 06:17 In article <dcsZg.3393$9z6.892(a)trndny03>, "Michael Metcalf" <michaelmetcalf(a)compuserve.com> wrote: > >"Dave Seaman" <dseaman(a)no.such.host> wrote in message >news:eh5fks$4gv$3(a)mailhub227.itcs.purdue.edu... >> ... which reminds me of the following ancient example: >> >.... and here it's modern transformation. Significant blanks really do make a >difference (and to think we debated their value for so long). > >Regards, > >Mike Metcalf > > INTEGER goto, do100if, return > REAL read (4) > LOGICAL gotoif > REAL logical (30) > DATA read / 4h(1x,, 3hi5,, 4hf8.1, 1h) / > DATA goto, do100if, if100do / 2, 1, 30 / > ASSIGN 100 TO ifgoto > DO 100 if = do100if, if100do > return = if > logical (if) = return > gotoif = if - goto * (if / goto) .eq.do100if > IF (gotoif) goto ifgoto > CALL call (logical, return) > 100 END DO > PRINT read, (if, logical (if), if = do100if, if100do) > STOP > END > SUBROUTINE call (integer, real) > INTEGER real > REAL integer (real) > common (if) = if * if > integer (real) = common (real) > RETURN > END SUBROUTINE call > > Chop, chop. ROTFL. You people are evil. /BAH
From: jmfbahciv on 19 Oct 2006 06:19 In article <1879.517T2640T10365801(a)kltpzyxm.invalid>, "Charlie Gibbs" <cgibbs(a)kltpzyxm.invalid> wrote: >In article <eh5fks$4gv$3(a)mailhub227.itcs.purdue.edu>, >dseaman(a)no.such.host (Dave Seaman) writes: > >> On 18 Oct 2006 07:38:30 -0700, wclodius(a)lanl.gov wrote: >> >>> Minor comment. Fortran as a language is one of the few with NO >>> reserved words/identifiers. You can not only define your own >>> SIN function, you can also define your own FUNCTION, IF, END, >>> CONTINUE, ... functions, variables, or subroutines. Fortran uses >>> punctuation to identify contexts where keywords are required >>> (resulting in the potential need for a second pass in lexing), >>> and the explicit identification of user defined semantics for >>> a name will use user definition in locations where keywords are >>> not required. >>><snip> >> >> ... which reminds me of the following ancient example: >> >> integer go to,do 100 if,return >> real read(4) >> logical go to if >> real logical(30) >> data read/4h(1x,,3hi5,,4hf8.1,1h)/ >> data go to,do 100 if,if 100 do/2,1,30/ >> assign 100 to if go to >> do 100 if=do 100 if,if 100 do >> return=if >> logical(if)=return >> go to if=if-go to*(if/go to).eq.do 100 if >> if(go to if) go to if go to >> call call(logical,return) >> 100 continue >> print read, (if,logical(if),if=do 100 if,if 100 do) >> stop >> end >> subroutine call( integer,real ) >> integer real >> real integer(real) >> common(if)=if*if >> integer(real)=common(real) >> return >> end > >Omigod. It's the ancestor of the IOCCC! But maybe we should call it >the IOFFF, for, uhh... International Obfuscated Fortran Fabrication >Fandango. Right. I'd be lining up their 9 edges. No keypuncher would let that go through without painting those cards very red. /BAH
From: Richard Maine on 19 Oct 2006 11:00 <jmfbahciv(a)aol.com> wrote: > In article <1hne8p2.vgiivpx9358gN%nospam(a)see.signature>, > nospam(a)see.signature (Richard E Maine) wrote: [about name conflicts with intrinsics] > >Elsewhere in my post, I mentioned that one of the ways this comes up is > >when new intrinsics are added to the language. > > 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 until f90 was the 6-character limit formally lifted, though in the later days of f77, most compilers allowed longer names. In the earlier days of f77, not so at all. There were plenty of early compilers/systems that enforced the 6 character limit (or at least something close - I recall CDC as having a limit at 7) so that one needed to stick to it for portable code. These days, modules provide an improved solution. In fact, I personally would have preferred to put more of the new standard intrinsics into modules, but I didn't have much luck swaying the committee on that one. I do put my own new code in modules. -- Richard Maine | Good judgement comes from experience; email: last name at domain . net | experience comes from bad judgement. domain: summertriangle | -- Mark Twain
From: Rostyslaw J. Lewyckyj on 19 Oct 2006 13:41
jmfbahciv(a)aol.com wrote: > In article <1879.517T2640T10365801(a)kltpzyxm.invalid>, > "Charlie Gibbs" <cgibbs(a)kltpzyxm.invalid> wrote: > >>In article <eh5fks$4gv$3(a)mailhub227.itcs.purdue.edu>, >>dseaman(a)no.such.host (Dave Seaman) writes: >> >> >>>On 18 Oct 2006 07:38:30 -0700, wclodius(a)lanl.gov wrote: >>> >>> >>>>Minor comment. Fortran as a language is one of the few with NO >>>>reserved words/identifiers. You can not only define your own >>>>SIN function, you can also define your own FUNCTION, IF, END, >>>>CONTINUE, ... functions, variables, or subroutines. Fortran uses >>>>punctuation to identify contexts where keywords are required >>>>(resulting in the potential need for a second pass in lexing), >>>>and the explicit identification of user defined semantics for >>>>a name will use user definition in locations where keywords are >>>>not required. >>>><snip> >>> >>>... which reminds me of the following ancient example: >>> >>> integer go to,do 100 if,return >>> real read(4) >>> logical go to if >>> real logical(30) >>> data read/4h(1x,,3hi5,,4hf8.1,1h)/ >>> data go to,do 100 if,if 100 do/2,1,30/ >>> assign 100 to if go to >>> do 100 if=do 100 if,if 100 do >>> return=if >>> logical(if)=return >>> go to if=if-go to*(if/go to).eq.do 100 if >>> if(go to if) go to if go to >>> call call(logical,return) >>> 100 continue >>> print read, (if,logical(if),if=do 100 if,if 100 do) >>> stop >>> end >>> subroutine call( integer,real ) >>> integer real >>> real integer(real) >>> common(if)=if*if >>> integer(real)=common(real) >>> return >>> end >> >>Omigod. It's the ancestor of the IOCCC! But maybe we should call it >>the IOFFF, for, uhh... International Obfuscated Fortran Fabrication >>Fandango. > > > Right. I'd be lining up their 9 edges. No keypuncher would > let that go through without painting those cards very red. > > /BAH Keypunchers, unless summer interns from a technical school or such like, are not expected to be the Fortran pre compiler syntax checking phase. Similarly we instructed our student help staffing the input-output window (i.e. accepting job decks & handing out the printed outputs) not to hand out programming advice, i.e. not play at being consultants, even if they were seniors with some programming courses under their belts. It was a matter of 'liability' of the "but he/she told me to" type. -- Rostyk |