이 다른 답변은 다소 오도됩니다. 본인은 이러한 불일치를 설명 할 수있는 구현 세부 사항을 진술하지만 동의합니다. jmite가 올바르게 제안한 것처럼, 함수 호출 / 재귀의 깨진 구현을 향한 구현 지향적 입니다. 많은 언어가 재귀를 통해 루프를 구현하므로 해당 언어에서 루프가 더 빠르지는 않습니다. 이론적으로 재귀는 루핑보다 효율적이지 않습니다 (둘 다 적용 가능한 경우). 가이 스틸 ( Ge Steele)의 1977 년 논문 에서 "비용이 많이 드는 절차 호출"신화 또는 절차 구현이 유해한 것으로 간주되거나 Lambda : Ultimate GOTO에 대한 요약을 인용하겠습니다 .
Folklore는 GOTO 문이 "저렴한"반면 프로 시저 호출은 "고가"라고 말합니다. 이 신화는 주로 제대로 구현되지 않은 언어 구현의 결과입니다. 이 신화의 역사적 성장이 고려됩니다. 이 신화에 대한 이론적 아이디어와 기존의 구현에 대해 논의합니다. 프로 시저 호출의 무제한 사용은 큰 문체 자유를 허용합니다. 특히, 플로우 차트는 추가 변수를 도입하지 않고 "구조화 된"프로그램으로 작성할 수 있습니다. GOTO 문과 프로 시저 호출의 어려움은 추상적 인 프로그래밍 개념과 구체적인 언어 구성 사이의 충돌로 특징 지워집니다.
은 "추상적 인 프로그래밍 개념과 구체적인 언어 구조 사이의 충돌은"대부분의 이론적 모델은, 예를 들어, 형식화되지 않은 사실에서 볼 수있는 람다 계산법은 , 스택이 없습니다 . 물론, 위의 논문이 설명하고 Haskell과 같은 재귀 이외의 반복 메커니즘이없는 언어에서도이 충돌이 필요하지 않습니다.
fixfix f x = f (fix f) x( λ x . M) N⇝ 남[ N/ x][ N/ x]엑스미디엄엔⇝
이제 예를 들어 보겠습니다. 정의 fact로
fact = fix (λf.λa.λn.if n == 0 then a else f (a*n) (n-1)) 1
다음 fact 3은 압축을 g위해 fix (λf.λa.λn.if n == 0 then a else f (a*n) (n-1)),에 대한 동의어로 사용 하는 평가입니다 fact = g 1. 이것은 내 주장에 영향을 미치지 않습니다.
fact 3
~> g 1 3
~> fix (λf.λa.λn.if n == 0 then a else f (a*n) (n-1)) 1 3
~> (λf.λa.λn.if n == 0 then a else f (a*n) (n-1)) g 1 3
~> (λa.λn.if n == 0 then a else g (a*n) (n-1)) 1 3
~> (λn.if n == 0 then 1 else g (1*n) (n-1)) 3
~> if 3 == 0 then 1 else g (1*3) (3-1)
~> g (1*3) (3-1)
~> g 3 2
~> fix (λf.λa.λn.if n == 0 then a else f (a*n) (n-1)) 3 2
~> (λf.λa.λn.if n == 0 then a else f (a*n) (n-1)) g 3 2
~> (λa.λn.if n == 0 then a else g (a*n) (n-1)) 3 2
~> (λn.if n == 0 then 3 else g (3*n) (n-1)) 2
~> if 2 == 0 then 3 else g (3*2) (2-1)
~> g (3*2) (2-1)
~> g 6 1
~> fix (λf.λa.λn.if n == 0 then a else f (a*n) (n-1)) 6 1
~> (λf.λa.λn.if n == 0 then a else f (a*n) (n-1)) g 6 1
~> (λa.λn.if n == 0 then a else g (a*n) (n-1)) 6 1
~> (λn.if n == 0 then 6 else g (6*n) (n-1)) 1
~> if 1 == 0 then 6 else g (6*1) (1-1)
~> g (6*1) (1-1)
~> g 6 0
~> fix (λf.λa.λn.if n == 0 then a else f (a*n) (n-1)) 6 0
~> (λf.λa.λn.if n == 0 then a else f (a*n) (n-1)) g 6 0
~> (λa.λn.if n == 0 then a else g (a*n) (n-1)) 6 0
~> (λn.if n == 0 then 6 else g (6*n) (n-1)) 0
~> if 0 == 0 then 6 else g (6*0) (0-1)
~> 6
성장이 없으며 각 반복에 동일한 양의 공간이 필요하다는 세부 정보를 보지 않고도 모양에서 볼 수 있습니다. (기술적으로, 수치 결과는 피할 수없고 while루프에 대해서도 마찬가지입니다 .) 나는 무한히 성장하는 "스택"을 여기서 지적하지 않습니다.
람다 미적분학의 전형적인 의미론은 이미 "꼬리 호출 최적화"라는 이름을 가진 것을 이미 수행하는 것 같습니다. 물론 여기서는 "최적화"가 일어나지 않습니다. 여기서는 "통상"호출과 달리 "꼬리"호출에 대한 특별한 규칙이 없습니다. 이러한 이유로 함수 호출 시맨틱의 많은 추상 특성화에서 꼬리 호출 "최적화"를 수행 할 수있는 것은 없기 때문에 꼬리 호출 "최적화"가 수행하는 작업에 대한 "추상적 인"특성을 부여하기가 어렵습니다!
fact많은 언어에서 "스택 오버플로" 의 유사한 정의는 함수 호출 시맨틱을 올바르게 구현하지 못하는 언어에서 실패했습니다. (일부 언어에는 변명의 여지가 있습니다.) 상황은 링크 된 목록으로 배열을 구현 한 언어 구현과 유사합니다. 그런 다음 "배열"로 인덱싱하면 배열 기대 값을 충족하지 않는 O (n) 연산이됩니다. 링크 된 목록 대신 실제 배열을 사용하는 언어를 별도로 구현하면 "배열 액세스 최적화"를 구현했다고 말하지 않고 배열의 깨진 구현을 수정했다고 말할 수 있습니다.
따라서 Veedrac의 답변에 응답하십시오. 스택은 재귀에 "기본적" 이 아닙니다 . 평가 과정에서 "스택 유사"동작이 발생하는 경우, 이는 보조 데이터 구조가없는 루프가 처음에는 적용되지 않는 경우에만 발생할 수 있습니다! 다시 말하면, 정확히 동일한 성능 특성을 가진 재귀로 루프를 구현할 수 있습니다. 실제로 Scheme과 SML은 모두 반복 구조를 포함하지만 둘 다 재귀 측면에서 구조를 정의합니다 (적어도 Scheme에서는 do종종 재귀 호출로 확장되는 매크로로 구현 됩니다). 마찬가지로 Johan의 답변에 대해서는 아무것도 대답하지 않습니다. 컴파일러는 재귀에 대해 설명 된 어셈블리 Johan을 내 보내야합니다. 과연,루프를 사용하든 재귀를 사용하든 정확히 동일한 어셈블리입니다. 컴파일러가 Johan이 설명하는 것과 같은 어셈블리를 방출 해야하는 유일한 시간은 어쨌든 루프로 표현할 수없는 무언가를 할 때입니다. 스틸의 논문에서 설명하고 하스켈, 계획 및 SML 같은 언어의 실제 연습에 의해 입증, 그들이 할 수있는, 꼬리 호출이 "최적화"할 수있다 "대단히 드문"아니다 항상"최적화"하십시오. 특정 재귀 사용이 일정한 공간에서 실행 될지 여부는 작성 방법에 따라 다르지만, 가능한 한 적용해야 할 제한 사항은 문제를 루프 모양에 맞추기 위해 필요한 제한 사항입니다. (실제로 덜 엄격합니다. 인코딩 상태 머신과 같이 보조 변수를 필요로하는 루프와 달리 테일 호출을 통해보다 깨끗하고 효율적으로 처리되는 문제가 있습니다.) 재귀에 더 많은 작업을 수행 해야하는 유일한 시간 은 어쨌든 코드가 루프가 아닌 경우.
내 생각에 Johan은 꼬리 호출 "최적화"를 수행 할시기에 대한 임의의 제한이있는 C 컴파일러를 언급하고있다. Johan은 아마도 "관리되는 유형의 언어"에 대해 이야기 할 때 C ++ 및 Rust와 같은 언어를 언급하고있을 것입니다. C ++ 의 RAII 관용구는 Rust에도 있으며 꼬리 호출이 아닌 표면 호출처럼 보이게합니다 ( "소멸자"는 여전히 호출해야하기 때문에). 꼬리 재귀를 허용하는 약간 다른 의미론을 선택하기 위해 다른 구문을 사용하라는 제안이있었습니다 (즉, 소멸자 를 호출 하기 전에최종 테일 호출 및 "파괴 된"객체에 대한 액세스를 명백히 금지합니다). 가비지 수집에는 이러한 문제가 없으며 Haskell, SML 및 Scheme은 모두 가비지 수집 언어입니다. 매우 다른 맥락에서 스몰 토크와 같은 일부 언어는 "스택"을 일류 개체로 노출합니다. "스택"은 더 이상 구현 세부 사항이 아니지만 의미가 다른 별도의 호출 유형을 배제하지는 않습니다. (자바는 보안의 일부 측면을 처리하는 방식으로 인해 불가능하다고 말하지만 실제로는 거짓 입니다.)
실제로, 함수 호출의 깨진 구현의 보급은 세 가지 주요 요소에서 비롯됩니다. 첫째, 많은 언어가 구현 언어 (보통 C)에서 깨진 구현을 상속합니다. 둘째, 결정 론적 자원 관리는 훌륭하고 문제를 더욱 복잡하게 만들지 만 소수의 언어 만이이를 제공합니다. 셋째, 내 경험상 대부분의 사람들이 관심을 갖는 이유는 디버깅 목적으로 오류가 발생할 때 스택 추적을 원하기 때문입니다. 두 번째 이유는 이론적으로 동기를 부여 할 수있는 이유입니다.