항상 재귀 함수를 반복 함수로 바꿀 수 있습니까? 물론 그렇습니다. 그리고 교회 튜링 논문은 기억이 도움이된다면 그것을 증명합니다. 즉, 재귀 함수로 계산할 수있는 것은 반복 모델 (예 : Turing machine)로 계산할 수 있으며 그 반대도 마찬가지입니다. 논문은 변환 방법을 정확하게 알려주지는 않지만 확실히 가능하다고 말합니다.
많은 경우 재귀 함수를 쉽게 변환 할 수 있습니다. Knuth는 "컴퓨터 프로그래밍 기술"에서 몇 가지 기술을 제공합니다. 그리고 종종 재귀 적으로 계산 된 것을 적은 시간과 공간에서 완전히 다른 접근법으로 계산할 수 있습니다. 이것의 전형적인 예는 피보나치 수 또는 이의 서열이다. 학위 과정에서 반드시이 문제를 해결했습니다.
이 동전의 반대편에서, 우리는 공식의 재귀 적 정의를 이전 결과를 기억하기위한 초대로 취급 할 정도로 진보 된 프로그래밍 시스템을 상상할 수 있습니다. 재귀 적 정의를 가진 공식의 계산을 따르십시오. Dijkstra는 거의 확실히 그러한 시스템을 상상했습니다. 그는 구현을 프로그래밍 언어의 의미와 분리하는 데 오랜 시간을 보냈습니다. 그런 다음 그의 비결정적이고 다중 처리 프로그래밍 언어는 실무 전문 프로그래머보다 우위에 있습니다.
최종 분석에서 많은 함수는 재귀적인 형태로 이해하고 읽고 쓰는 것이 더 쉬워졌습니다. 설득력있는 이유가 없다면,이 함수들을 명시 적으로 반복적 인 알고리즘으로 (수동으로) 변환해서는 안됩니다. 컴퓨터가 해당 작업을 올바르게 처리합니다.
한 가지 설득력있는 이유가 있습니다. [ 석면 속옷 착용 ] 구성표, Lisp, Haskell, OCaml, Perl 또는 Pascal 과 같은 최고급 언어로 프로토 타입 시스템을 구축했다고 가정합니다 . 조건이 C 또는 Java로 구현되어야한다고 가정하십시오. (아마도 정치 일 것입니다.) 그렇다면 재귀 적으로 작성된 일부 함수를 가질 수 있지만 문자 그대로 번역되어 런타임 시스템을 폭발시킬 수 있습니다. 예를 들어, Scheme에서는 무한 꼬리 재귀가 가능하지만 동일한 관용구가 기존 C 환경에 문제를 일으 킵니다. 또 다른 예는 파스칼은 지원하지만 C는 지원하지 않는 어휘 중첩 함수와 정적 범위를 사용하는 것입니다.
이러한 상황에서는 원래 언어에 대한 정치적 저항을 극복하려고 시도 할 수 있습니다. Greenspun의 (뺨에 혀로) 10 번째 법칙에서와 같이 Lisp를 잘못 구현 한 것을 알게 될 것입니다. 또는 완전히 다른 솔루션 접근 방식을 찾을 수 있습니다. 그러나 어쨌든 확실한 방법이 있습니다.