«

wrote:
> In article <4be62644$0$14116$>,
> Sjouke Burry <> wrote:
>> Nick Keighley wrote:
>>> On 8 May, 17:46, Tim Streater <timstrea...@waitrose.com> wrote:
>>>> In article
>>>> <5dd9bdc8-4dc4-4537-84a0-885c4c92f...@l28g2000yqd.googlegroups.com>,
>>>> Nick Keighley <nick_keighley_nos...@hotmail.com> wrote:
>>>>> On 8 May, 01:41, Lie Ryan <lie.1...@gmail.com> wrote:
>>>
>>>>>>> I've never heard of any programming languages that doesn't support
>>>>>>> recursion.
>>> [...]
>>>>> FORTRAN (in its original form), Coral-66 you had to use a special
>>>>> keyword to indicate a function was recursive. Some BASICs probably
>>>>> didn't alow recursion. But these all qualify as "ancient" (and maybe
>>>>> jocular!)
>>>> What FORTRAN are you referring to. I never saw it in any FORTRAN up to
>>>> 1978 (the last time I used FORTRAN).
>>> lost me. So far as I remember FORTRAN didn't have recursion. Am I
>>> wrong? Or are you saying even modern Fortran doesn't have recursion?
>> If recursion does not exist, I will have to ditch quite a couple
>> of fortran programs.
>> There is only 1 hitch, you have to write a 3 line dummy routine,
>> to do the calling, so a calls b , b calls a.
>> fortran MS 5.1 and later.
>> Also Fortran77 for Riscos (arc 320 computer)
>
> And then there are systems on which this approach would almost
> surely fail spectacularly (as you may know -- just sayin').
> In a long-ago job in which one of my responsibilities was finding
> and fixing bugs other people's FORTRAN, a particularly nasty
> one turned out to be the result of this kind of mutual recursion.
> If the system puts the return address for a call to a non-recursive
> subroutine in a fixed location, well ....
>
> I'm curious now about why A-calls-B-calls-A would work but simple
> A-calls-A would not. Is it a compiler issue? where the compiler
> won't allow the latter, but will allow the former?
>
a to a gets you an angry compiler.
As far as I can remember, the a > b > a advice came from M$.
I used recursion for quite some fractal drawing.
Those routines themselves were rather small.
Because of the excessive use of the stack, you had to tell the
linker to use a larger stack.
/stack:32768 on the commandline, normally only about ~1024.

That stack, together with the "automatic" statement gave reliable
recursion.

Andy Champ wrote:
> wrote:
>> I'm curious now about why A-calls-B-calls-A would work but simple
>> A-calls-A would not. Is it a compiler issue? where the compiler
>> won't allow the latter, but will allow the former?
>>
>
> I tried this once upon a time (well back in the last millenium!) and
> found out that all the variable in the subroutines were what in the
> C/C++ world are called static - there was only one instance. So when
> you got to the second instance of A you were using the same local
> variables as the first instance.
>
> The compiler blocked A-calls-A but didn't spot A-calls-B-calls-A - it
> just let you shoot your own foot.
>
> Andy
Thats where the "automatic" statement comes in, it makes all variables
in the routine temporary, and makes recursion possible.

In article <CNWdneJy4NoCfZ_RnZ2dnUVZ7o->,
Andy Champ <> wrote:
> wrote:
> >
> > I'm curious now about why A-calls-B-calls-A would work but simple
> > A-calls-A would not. Is it a compiler issue? where the compiler
> > won't allow the latter, but will allow the former?
> >
>
> I tried this once upon a time (well back in the last millenium!) and
> found out that all the variable in the subroutines were what in the
> C/C++ world are called static - there was only one instance. So when
> you got to the second instance of A you were using the same local
> variables as the first instance.
>
> The compiler blocked A-calls-A but didn't spot A-calls-B-calls-A - it
> just let you shoot your own foot.

Yup, that's exactly what happened in the story from a previous life
that prompted my earlier post. I can't remember now how I (we?)
finally tracked *that* bug down, but I seem to remember at some
point it may have involved looking at an assembly-language version
of the object code produced by the compiler. "Those were the days"?

--
B. L. Massingill
ObDisclaimer: I don't speak for my employers; they return the favor.