jerry@violet.berkeley.edu ( Jerry Berkman ) (03/25/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. ... And 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. The 1977 FORTRAN standard, ANSI x3.9-1978 says (page 15-1, lines 55-56): "A subprogram must not reference itself, either directly or indirectly." Recursion is explicitly allowed in Fortran 8x. Jerry Berkman jerry@violet.berkeley.edu Computing Services, U.C. Berkeley (415)642-4804
jlg@a.UUCP (Jim Giles) (03/25/88)
In article <7975@agate.BERKELEY.EDU>, jerry@violet.berkeley.edu ( Jerry Berkman ) writes: > > The 1977 FORTRAN standard, ANSI x3.9-1978 says (page 15-1, lines 55-56): > "A subprogram must not reference itself, either directly or indirectly." > > Recursion is explicitly allowed in Fortran 8x. > I know all this. My point was that Fortran 8x only needed to include the sentence: "A procedure may reference itself, either directly or indirectly." This would be the only change required in order to allow recursion. The question I asked was: "Why is the keyword RECURSIVE necessary?" J. Giles Los Alamos
jlg@a.UUCP (Jim Giles) (03/25/88)
There seems to be a fundamental misunderstanding about what constitutes a standard-conforming implementation of Fortran. Two responses to the issue of recursion have tried to claim that a processor which allows recursion is inherently not standard-conforming. This is not true - the standard explicitly allows for extensions. Read ANSI X3.9-1978 FORTRAN 77 page 1-2 lines 25-43: A processor conforms to this standard if it executes standard-conforming programs in a manner that fulfills the interpretations prescribed herein. A standard-conforming processor may allow additional forms and relationships provided that such additions do not conflict with the standard forms and relationships. [...] Note that a standard- conforming _PROGRAM_ must not use any forms or relationships that are prohibited by this standard, but a standard-conforming _PROCESSOR_ may allow such forms and relationships if they do not change the proper interpretation of a standard-conforming program. [My emphasis on _PROGRAM_ and _PROCESSOR_] By the above description, a _PROGRAM_ which uses recursion is not standard-conforming, but a _PROCESSOR_ which allows recursion is not against the standard. J. Giles Los Alamos
eugene@pioneer.arpa (Eugene N. Miya) (03/25/88)
In article <533@a.UUCP> jlg@a.UUCP (Jim Giles) writes: >The question I asked was: "Why is the keyword RECURSIVE necessary?" You are right, it's not. The keyword (not reserved) is "necessary" for those users who believe in comparing languages solely by counting the number of keywords. (Hence COBOL with 300-500 reserved words is a "bigger" language.) I would question a statement that Giles make in a subsequent posting about better business languages, or that Fortran is a good scientific language. COBOL is a somewhat terrible business language, and only an artifact of Adm. Grace ;-) [Had to say that she wasn't able to make CSC in Atlanta.] Fortran has some semblence of algebra, and that's why it is popular. A recent story I heard was about a self-taught [lunch-time only] programmer physicist at Livermore who started all his labels in column 1 and they all started with "1" and the line printers caught this on his big code which had one label per line (you know like BASIC ;-). They came running after him. From the Rock of Ages Home for Retired Hackers: --eugene miya, NASA Ames Research Center, eugene@ames-aurora.ARPA "You trust the `reply' command with all those different mailers out there?" "Send mail, avoid follow-ups. If enough, I'll summarize." {uunet,hplabs,hao,ihnp4,decwrl,allegra,tektronix}!ames!aurora!eugene
jhs@actnyc.UUCP (John Spicer) (03/26/88)
It has been pointed out that FORTRAN can support recursion as the language now exists. This is true, as is proven by the number of implementations that support recursion. However, this does not mean that a recursive keyword is not useful. 1. Many FORTRAN compilers allocate variables as if the were SAVED'd to conform to common practice that expects this to be true. A recursive keyword allows a compiler to continue to do this for non-recursive subprograms. 2. Some architechtures do not support recursion well. For example, on the IBM 370 architechture, it is common to have static parameter packs for subroutine calls, and other static structures. On these systems, the static approach is usually more efficient than building the structures dynamically. Non-recursive procedures could continue to use the more efficient system. 3. Many FORTRAN implementations use dope-vectors for adjustable bound arrays. Recursive routines must construct the dope vector dynamically. Non-recursive routines can build most of the dope vectory statically. The recursive keyword is useful because it allows each implementation to make choices based on a given architechtures, and not produce slower code just because a given subprogram may end up being called recursively. John Spicer InterACT Corp. uunet!actnyc!jhs
platt@emory.uucp (Dan Platt) (03/27/88)
Following a bunch of stuff about recursion being permitted, we have: In article <533@a.UUCP> jlg@a.UUCP (Jim Giles) writes: >... The question I asked was: "Why is the keyword RECURSIVE >necessary?" Recursion requires variables to be passed by value (in general) rather than by address. If a variable is passed by address, then changing the variable in the subroutine changes the value in the called routine as well. If the value is placed "on the stack" so that the subroutine works with the values in a separate variable space (a new one for each call - and each level of recursion), then changing the variable won't affect its value in the calling routine. In other words, the calling routine will remember the value rather than having it changed with each recursive call.... Dan Platt
fpst@hubcap.UUCP (Steve Stevenson) (03/28/88)
in article <2787@emory.uucp>, platt@emory.uucp (Dan Platt) says: > > Recursion requires variables to be passed by value (in general) rather than > by address. Not true. The real problem is what is the semantics of the assignment to an input variable. Don't confuse implmentations with semantics of the language. -- 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