jlg@a.UUCP (Jim Giles) (03/22/88)
> The criterion for Fortran 8x features (in my opinion) should be to > certify existing practice or to extend the language in a significant > way. I will use this criterion throughout this discussion. There are a number of Fortran environments that already allow recursive subroutines and/or functions. The addition of recursion is something that is long overdue. Efficient implementations of any given algorithm will probably remain iterative, but recursion is often the most natural presentation of an algorithm and should be provided (if only to allow quick testing of ideas). The main question I have is: why is the keyword RECURSIVE required? The standard should just state that procedures may invoke themselves, either directly or indirectly. I can think of only two reasons that the RECURSIVE keyword was included. First, the committee wanted to make it possible for the compiler and loader to check that recursion is not unintentionally present. But, I have seen no implementation of Fortran (where recursion was allowed) that actually performs such checks. The second reason is that in spite of the introduction of SAVE in Fortran 77, many Fortran environments have not fully implemented stack-based code. Since stack-based code is absolutely required for recursion to work, the committee wanted to make it possible for the compiler to generate stack references ONLY for the recursive procedures. Non-recursive procedures would continue to work as before (and without the stack references they might run slightly faster). In any case, both (or neither) of these reasons might have been involved. It really doesn't matter a lot if the RECURSIVE keyword remains in the new standard. It just seemed to be unnecessary. J. Giles Los Alamos
fpst@hubcap.UUCP (Steve Stevenson) (03/23/88)
in article <522@a.UUCP>, jlg@a.UUCP (Jim Giles) says: > > > There are a number of Fortran environments that already allow recursive > subroutines and/or functions. The addition of recursion is something > that is long overdue. Efficient implementations of any given algorithm > will probably remain iterative, but recursion is often the most natural > presentation of an algorithm and should be provided (if only to allow > quick testing of ideas). > We are extending Fortan for hypercubes and we have been rummaging around the standard some. There seems to be no prohibition to recursion. As you point out, there are several. The problems seems to be that, as usual, the last used compiler becomes the standard definition. Since folks weren't required to support recursion, they didn't. The rules as to what is local data variables to a procedure and what are not is quite clear. The inefficiencies are runtime stack inefficiencies [ if multiple copies of the activation record are inefficiencies.] The obvious problem is that those holding that all computers look like the IBM 709x and therefore Fortran 77 is an adequate model need to be re-educated. -- Steve Stevenson fpst@hubcap.clemson.edu (aka D. E. Stevenson), fpst@clemson.csnet Department of Computer Science, comp.parallel Clemson University, Clemson, SC 29634-1906 (803)656-5880.mabell
levy@ttrdc.UUCP (Daniel R. Levy) (03/24/88)
In article <522@a.UUCP>, jlg@a.UUCP (Jim Giles) writes: [possible reasons why RECURSIVE keyword is still in F8x] # ...in spite of the introduction of SAVE in Fortran # 77, many Fortran environments have not fully implemented stack-based code. # Since stack-based code is absolutely required for recursion to work, the # committee wanted to make it possible for the compiler to generate stack # references ONLY for the recursive procedures. Non-recursive procedures # would continue to work as before (and without the stack references they # might run slightly faster). Plain-vanilla UNIX f77 (not exactly a paradigm of efficiency) will, in fact, produce significantly faster and somewhat smaller code when stack references are forced (via the extension storage class AUTOMATIC) than the default, where it will use static data. It is faster on many machines to reference memory indexed with small offsets from a register (i.e. the stack pointer) than it is to reference it by absolute address. So, stack-based code is a win-win situation with respect to both efficiency and recursion. -- |------------Dan Levy------------| Path: ..!{akgua,homxb,ihnp4,ltuxa,mvuxa, | an Engihacker @ | <most AT&T machines>}!ttrdc!ttrda!levy | AT&T Computer Systems Division | Disclaimer? Huh? What disclaimer??? |--------Skokie, Illinois--------|
firth@sei.cmu.edu (Robert Firth) (03/25/88)
In article <1180@hubcap.UUCP> fpst@hubcap.UUCP (Steve Stevenson) writes: >We are extending Fortan for hypercubes and we have been rummaging around >the standard some. There seems to be no prohibition to recursion. As >you point out, there are several. I'm not sure exactly what this means, but if it means that the Fortran standard doesn't prohibit recursion, it's wrong. See [ANSI X3.9-1978 15.6.2.2], third para. Also, I'm a bit puzzled by the idea of "extending Fortran for hypercubes". Extending Fortran for, say, business data processing sounds like a good idea, since that's a genuine problem domain.
jlg@a.UUCP (Jim Giles) (03/25/88)
In article <4737@aw.sei.cmu.edu>, firth@sei.cmu.edu (Robert Firth) writes: > Also, I'm a bit puzzled by the idea of "extending Fortran for hypercubes". > Extending Fortran for, say, business data processing sounds like a good > idea, since that's a genuine problem domain. "Extending Fortran for hypercubes" obviously means that they are extending the language to better utilize hardware features inherent to the target machine (for hypercubes this probably means recursion and variable sharing in a multi-tasking environment). This is a perfectly normal thing to do to Fortran and has been common practice for researchers and hardware vendors for years - extend Fortran to meet the characteristics of the machine. Such extensions are usually modest: New data types (remember REAL*4 and REAL*8?); New intrinsic functions; and, most recently, super-computer vendors adding vector syntax. Extending Fortran for business data processing doesn't sound like a good idea to me. There are already other languages that are better suited to that area. Fortran is best suited to scientific number-crunching - let's keep our extensions targeted to that set of problems. (This is not to say that there may not be overlaps in the features of languages. If Fortran users would benefit from some feature that also has uses in business data processing, I see no reason not to include it. But, Fortran should not seek to widen its scope to types of problems that are best solved with other languages.) J. Giles Los Alamos
fpst@hubcap.UUCP (Steve Stevenson) (03/25/88)
in article <4737@aw.sei.cmu.edu>, firth@sei.cmu.edu (Robert Firth) says: > > In article <1180@hubcap.UUCP> fpst@hubcap.UUCP (Steve Stevenson) writes: > > [ANSI X3.9-1978 15.6.2.2], third para. Ooooopsss.... I goofed. Let me put it this way: there is no good reason for above reference and there is nothing in the Fortran virtual machine that make recursion prohibited. > > Also, I'm a bit puzzled by the idea of "extending Fortran for hypercubes". > Extending Fortran for, say, business data processing sounds like a good > idea, since that's a genuine problem domain. To deal with the T-series effectively, several new concepts need to be put into the language. The T is an unshared memory system and hence large matrices are carved up and stored locally to a processor. There seems to be two points of view about programming on these things. The dusty deckers and the non-dusty deckers. Our numerical people fall into the latter. As to business applications for Fortran - surely you jest. -- Steve Stevenson fpst@hubcap.clemson.edu (aka D. E. Stevenson), fpst@clemson.csnet Department of Computer Science, comp.parallel Clemson University, Clemson, SC 29634-1906 (803)656-5880.mabell