Why these original FORTRAN quirks?
in [Fortran]
|
From: Richard E Maine on 18 Oct 2006 10:55 glen herrmannsfeldt <gah(a)ugcs.caltech.edu> wrote: > That wouldn't get around any restrictions on initialization > expression, though. For example: > > PARAMETER (XYZ=sin(123.)) > EXTERNAL sin > > to reference a user supplied sin, unless this has been added > to what is allowed for initialization expression. Correct. I had debated going into that, but decided not to, as it seemed a side issue to the question of how to specify user procedures as opposed to intrinsic ones. If you specify a user procedure for sin() and use it in an initialization expression, that doesn't change the interpretation of it as a user procedure. It just means that the code is illegal. No, user procedures aren't allowed in initialization expressions. That would take some pretty fundamental changes - probably including a recategorization of initialization expressions into two different categories. After all, having a user procedure do things like initialize variables doesn't seem so awfully horrible, as long as one deals with questions of what order things get done in, which shouldn't be intractable (such matters as initializations in a user procedure that does initialization). But some uses of initialization expressions would essentially push much of the compiler into run-time if you allowed user procedures (or looked at the other way - could move the whole application program into compile time). In fact, even the intrinsic sin wasn't allowed in initialization expressions until recently. I'd have to go look it up to find whether that was an f95 or f2003 addition, but I think it is f2003. -- Richard Maine | Good judgment comes from experience; email: my first.last at org.domain| experience comes from bad judgment. org: nasa, domain: gov | -- Mark Twain
From: Dave Seaman on 18 Oct 2006 10:56 On Wed, 18 Oct 06 13:07:01 GMT, 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. How do you avoid it? An implementation is allowed to provide additional intrinsics besides those that are required by the standard. Therefore, there is no name you can choose that is guaranteed not to be an intrinsic. That's why it's good practice to declare your externals. -- Dave Seaman U.S. Court of Appeals to review three issues concerning case of Mumia Abu-Jamal. <http://www.mumia2000.org/>
From: Dave Seaman on 18 Oct 2006 11:01 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 -- Dave Seaman U.S. Court of Appeals to review three issues concerning case of Mumia Abu-Jamal. <http://www.mumia2000.org/>
From: Richard E Maine on 18 Oct 2006 11:12 <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. :-( Elsewhere in my post, I mentioned that one of the ways this comes up is when new intrinsics are added to the language. Concrete examples in common practice exist. One particular one that comes to mind... The old CalComp plotter HCBS (Host Computer Basic Software - I think) library included an external procedure named SCALE. This library was widely used in its day. Offshoots of it, using compatible interfaces (or nearly so - the transition from f66 Hollerith to f77 character caused a bit of a glitch) continue to be used today. The f90 standard added an intrinsic named SCALE. I apologize for my inexcusable use of the HCBS SCALE procedure in 1970 when I first saw it. F90 was only 20 years in the future; I should have known. :-) From the other direction, the HCBS library was well enough known that I was somewhat surprised that the f90 standard added an intrinsic that had a name conflict with it. But then I've never seen a program that had much need to use both of them in the same scoping unit. It could concievably happen, but doesn't seem particularly likely and I haven't happened to see it. There probably were programs somewhere that broke because they failed to specify the external attribute for SCALE. There are several other intrinsics whose names I'm sure I used for local variables of my own prior to the introduction of the intrinsic into the language. I couldn't pull out the specific codes right now, but I'm quite likely to have used names such as index, len, sum, and a few others at one time or another prior to their standardization as intrinsics. -- Richard Maine | Good judgment comes from experience; email: my first.last at org.domain| experience comes from bad judgment. org: nasa, domain: gov | -- Mark Twain
From: Michael Metcalf on 18 Oct 2006 12:00
"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 |