Re: Fortran and simple tree recursion

Michael Bader wrote:
> Jon Harrop wrote:
>>> Which seems to be exactly what I need - thanks for the suggestion.
>>> There's just no similar statement in C/C++, or, in fact, any other
>>> programming language I know ...
>>
>> The C/C++ equivalent is putting "static" before every local variable
>> definition.
>
> Not quite: I'd need a static that's static to a group of functions, and
> not only to one.

That would need to be a global static in C. It could be an outer-scope
static in C++. In OCaml (or ML) you would write something like:

let a, b, c, d =
let my_static = 1 in
let rec a = ...
and b = ...
and c = ...
and d = ... in
a, b, c, d

So there is only one "my_static" and it is local to a, b, c and d.

I use this style when memoizing a function. The hash table used to store the
memoized results is then local to the function in question but there is
only one such hash table in this scope.

>> Modern languages don't let you do this yourself because it breaks
>> modularity, concurrency, safety, determinism.
>
> Exactly :-) But still it would be very useful in my case.

Yes.

>> Instead, it is left as an
>> optimisation for the compiler to do when it can prove that there are no
>> ill effects.
>
> Which is almost impossible to grasp by a compiler - recognizing such a
> system of nested recursive calls should be quite difficult.

Essentially, tail calls are simply determined by whether or not the result
is returned immediately or used as a subexpression in further computation.
In functional languages (even impure functional languages), recursion is so
common that spotting tail recursion is almost essential. Consequently, most
such compilers spot 99% of tail calls.

--
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com
.

Relevant Pages

  • Re: references about the beauty of functional programming ?
    ... Jon Harrop wrote: ... such languages are therefore easier to maintain. ... For non-trivial tasks, OCaml is usually much faster than C++. ...
    (comp.lang.functional)
  • Re: Parallel Common-Lisp with at least 64 processors?
    ... Jon Harrop wrote: ... some languages process sleep cycles faster than others, ... My original point was that Lisp makes high-level programming slow. ... modern functional languages are so much more effective than ...
    (comp.lang.lisp)
  • Re: LLVM: A superior Lisp compiler framework?
    ... I also don't see direct support for proper tail ... > recursion, which would also be needed to make things work well. ... The tail call documentation is unofficial and currently available from the ... broad class of languages, particularly functional languages. ...
    (comp.lang.lisp)
  • Re: Troll-o-Matic
    ... I think Jon Harrop gets more flak that he deserves. ... criticism that was levied against his benchmarks was justified, ... in all these languages for comparison would be practical in most situations). ... It is easy to lie with statistics, but it's a lot easier to lie without them. ...
    (comp.lang.lisp)
  • Re: The power difference between a macro and a function
    ... Pascal Costanza wrote: ... > Jon Harrop wrote: ... Many people consider using other languages, ... to be a "reasonable alternative" to retrofitting an ad-hoc syntax ...
    (comp.lang.lisp)