After checking with SICP I notice they have a footnote 29) which is what they would have
written in “real” code.

Btw, I forgot a 1 in the srfi-42 version.

A programming language is commonly characterized as problem-oriented or machine-oriented, according as it is intended mainly for the description and analysis of algorithms or for their execution.

Where are the problem-oriented languages today? None of the languages we learn and use–even those considered “academic”–are effective tools of thought. C++, Java, Lisp, Haskell, even Cat all fall terribly short of the mark.

I’ve also been struggling with this issue. Haven’t connected all the dots, though.

In order to get the recursive functions into a form that the compiler can optimise they have to be given in tail recursive form which for a function like factorial involves the use of a separate accumulator argument.

Re-writing recursive algorithms into a tail recursive form can be an extremely hard challenge. I thought the power function I used as an example impossible after trying without success for a few days. Luckily somebody else knew the solution.

The compiler is basically looking for a way to remove the function call overhead by re-using the same stack frame for each step. In effect it converts the recursion into a for loop.

I actually lifted both samples directly from the SICP page I linked to.

Be that as it may, it strikes me as odd, that your original example counts down where as the last one counts up. A more natural translation into SICP-style would be:

(define (fact n)
  (define (fact-iter product n)
    (if (= n 1)
        product
        (fact-iter (* n product) (- n 1))))
  (fact-iter 1 n))

However, I don’t think SICP-style is idiomatic Scheme anymore. A much more common approach to these kinds of loops are named lets:

(define (fact n)
  (let loop ([product 1] [n n])
    (if (= n 1)
        product
        (loop (* n product) (- n 1)))))

A srfi-42 addict as me would write:

(define (fact n)
  (product-ec (: i (+ n 1))
              i))