Why these original FORTRAN quirks?
in [Fortran]
|
From: Rostyslaw J. Lewyckyj on 18 Oct 2006 00:18 Richard Maine wrote: > Rostyslaw J. Lewyckyj <urjlew(a)bellsouth.net> wrote: > > >>Well yes and no. The intrinsics are not really a part >>of the language, though almost. I don't believe any such >>functions are mandated for the language in the standard. > > > I couldn't quirte follow whether you were talking about Fortran or PL/I, > both having been mentioned in prior paragraphs. I don't know enough PL/I > to comment, so I won't tr. But in Fortran, the standard intrinsic > functions most definitely are part of the language. They are specified > in the standard, are required of all compilers, and are in general just > as much a part of the language as the syntax is. > > >>(I don't think any of these are evaluated at compile time ) > > > Again, sticking to Fortran, several are all but required to be > evaluatable at compile time. The standard doesn't technically > distinguish between compile-time and run-time; a standard-conforming > processor isn't required to have two such separate parts. But the design > definitely envisions such separation, and there are things that are > designed to be done at compile time; if they weren't, you wouldn't be > able to do much useful in the way of compilation. The list of intrinsics > that must be usable at compile time (specifically, the list of > intrinsics that are allowed in what are called initialization > expressions has grown over the years; in f2003, it is all of them). > Ok,ok, I stand corrected. However as a result I need an explanation and clarification of the 'practical ?' difference between intrinsics and reserved words/identifiers in the Fortran language. What is supposed to happen if I write {intrinsic} = .... and how do control whose {intrinsic} will be used during compilation versus execution. If I write PARAMETER (XYZ = {intrinsic ...}) and then EXTERNAL {intrinsic} with the intention of providing my own version of {intrinsic} eg. some strange approximation of sin. How can I control this? > >>Well plain DATA initializes local variables which are kept >>in the same CSECT as the code. Theoretically, I suppose, >>these variables could be placed into a seperate CSECT with >>a special name, which the linker would automatically move >>to the root segment, But I don't know of such. > > > I have seen Fortran compilers that put some initialized data into > separate CSECTS. In particular, I'm sure I recall things like that in > the old CDC compilers. Those compilers were also the ones where it > sometimes actually did make a difference whether COMMONs were saved or > not. >
From: Richard Maine on 18 Oct 2006 02:39 Rostyslaw J. Lewyckyj <urjlew(a)bellsouth.net> wrote: > Ok,ok, I stand corrected. However as a result I need an explanation > and clarification of the 'practical ?' difference between intrinsics > and reserved words/identifiers in the Fortran language. The names of intrinsics are not reserved. You can use them for anything you like. The practical effects of using the name of an intrinsic depend on whether you are using it as an external procedure or not. If you are using the name for something other than an external procedure, nothing special is required. You can't use the same name for 2 different things in the same scoping unit (with a few exceptions, but this isn't one), so you won't be able to use that name for the intrinsic in that scoping unit, although you can still use the intrinsic by that name in other scoping units. Just using the name for something else will declare it to be whatever that is instead of the intrinsic. If you use the name of the intrinsic for an external procedure, then you must explicitly specify the external attribute (by any of several ways; the EXTERNAL statement is the oldest). That's basically what the EXTERNAL attribute says - that the name is being used for an external instead of for an intrinsic. Note that this applies only to external procedures. If you use a module procedure, again, nothing special is required. > If I write PARAMETER (XYZ = {intrinsic ...}) > and then EXTERNAL {intrinsic} with the intention of providing > my own version of {intrinsic} eg. some strange approximation of sin. > How can I control this? See above. For anything other than an external procedure, just do whatever you would do anyway. For example, if you make it a module procvedure and then USE the module, then the USE statement brings in your version of sin, just the same as any other procedure. If you make it an external procedure, then use the EXTERNAL statement; that's what it is for. The standard specifically advises specifying the external attribute for all external procedures. That protects you against accidental collisions with intrinsic procedure names, including any added by future standards or as vendor-specific intrinsics (which are allowed). It also means that you don't need to memorize the whole listy of intrinsic names. If there is some intrinsic that you've never heard of and are not intentionally using, then that won't matter because you won't get it. By the way, the standard has had this advice since at least f77; I forget whether it was in f66 or not. The external statement was in f66, but I forget whether the standard included the advice about using it. My personal advice is to not use external procedures for new code; then the matter doesn't come up. But if you must use an external procedure, specify the external attribute, as recommended by the standard. -- Richard Maine | Good judgement comes from experience; email: last name at domain . net | experience comes from bad judgement. domain: summertriangle | -- Mark Twain
From: Richard Maine on 18 Oct 2006 02:47 Rostyslaw J. Lewyckyj <urjlew(a)bellsouth.net> wrote: > I was thinking of > things like sin({var}) where unless you specified > EXTERNAL sin, the compiler chose which of it's library > routines to call depending on the type of {var}. That is genericity. It is not directly related to whether or not something is intrinsic. Generic intrinsic procedures were added to the language in f77. As of f90, the user can also define generics (or extend the intrinsic generics). To re-emphasize generic/=intrinsic. They are unrelated concepts. All 4 combinations of generic/specific crossed with intrinsic/nonintrinsic exist. > I forgot to consider max/min, mod which did sometimes > get done at compile time. Though again you could override. > I never tried changing the use of any of these names > e.g. max=....... . So I don't recall any warnings, or > error messages because of these names having that special > almost reserved word status. They don't have any reserved word status - almost or otherwise. That's why you didn't get a complaint. See my other post. The only things in Fortran that are almost reserved words are the intrinsic type names. Those are reserved as type names. You can have, for example, a variable named "real", but you cannot have a derived type named real. -- Richard Maine | Good judgement comes from experience; email: last name at domain . net | experience comes from bad judgement. domain: summertriangle | -- Mark Twain
From: glen herrmannsfeldt on 18 Oct 2006 03:04 Rostyslaw J. Lewyckyj wrote: (snip) > I was not thinking of the case of relinking a load > module to either replace or add a BLOCK DATA. Here's > my example: Suppose you have a long routine with a block > of initialized variables. If you put these into a NAMED > COMMON then you can compile the subroutine once and > compile several BLOCK DATA subroutines on an as needed > basis to link with the object of the subroutine (Plus > other object decks, also using any linkage editor control > cards as needed) without needing to recompile the long > subroutine for each different set of initializations. This reminded me of something I saw in the F66 days similar to that. Without dynamic arrays, programs that needed dynamic arrays started with one large array and divided it up as needed. Then, as you say, you can separately compile the BLOCK DATA with the desired size array, which also includes a variable indicating the size. This allows one to change the size without recompiling the large program (which might be in a library). (It also relies on the non-standard use of different sized named COMMON in different routines, following OS/360 rules instead.) -- glen
From: glen herrmannsfeldt on 18 Oct 2006 03:12
Richard Maine wrote: > Rostyslaw J. Lewyckyj <urjlew(a)bellsouth.net> wrote: (snip) >>If I write PARAMETER (XYZ = {intrinsic ...}) >>and then EXTERNAL {intrinsic} with the intention of providing >>my own version of {intrinsic} eg. some strange approximation of sin. >>How can I control this? > See above. For anything other than an external procedure, just do > whatever you would do anyway. For example, if you make it a module > procvedure and then USE the module, then the USE statement brings in > your version of sin, just the same as any other procedure. If you make > it an external procedure, then use the EXTERNAL statement; that's what > it is for. 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. -- glen |