평가 전략

Evaluation strategy
평가 전략

프로그래밍 언어에서 평가 전략은 [1]식을 평가하기 위한 규칙 세트입니다.이 용어는 각 파라미터에 대해 함수에 전달되는 값의 종류(바인딩 [3]전략)와 함수 호출의 파라미터 평가 여부 및 평가될 경우 어떤 순서로(평가 순서)[4]를 정의하는 파라미터 전달[2] 전략의 보다 구체적인 개념을 가리키기 위해 자주 사용됩니다.비록 일부 저자가 두 용어를 혼동하고 각 용어의 정의에 [6]널리 동의하지는 않지만 감소전략의 개념은 구별된다.[5]

예를 들어 함수 호출 실행f(a,b)먼저 인수를 평가할 수 있습니다.a그리고.b, 결과를 참조 또는 메모리 위치에 저장합니다.ref_a그리고.ref_b그런 다음 전달된 참조를 사용하여 함수 본문을 평가합니다.이를 통해 함수는 인수 값을 검색하고 로컬 변수인 것처럼 할당하여 수정하며 참조를 통해 값을 반환할 수 있습니다.이것이 Call-by-Reference 평가 [7]전략입니다.

평가 전략은 프로그래밍 언어 정의에 의해 지정되며 특정 구현의 함수는 아닙니다.호출 규약은 구현 고유의 파라미터 전달 세부사항을 정의합니다.

테이블

소개된 연도별 평가 전략 및 대표 언어 표입니다.대표 언어는 전략을 도입한 언어부터 시작하여 전략을 사용하는 [8]: 434 주요 언어까지 연대순으로 나열되어 있습니다.

평가 전략 대표 언어 처음 도입된 연도
참조에 의한 콜 FORTRAN II, PL/I 1958
값에 의한 콜 ALGOL, C, 스킴 1960
이름으로의 콜 ALGOL 60, Simula 1960
복사/복원에 의한 호출 Fortran IV, Ada[9] 1962
필요에 의한 콜 SASL,[10] Haskell, R[11] 1971년[12]
공유에 의한 콜 CLU, Java, Python, Ruby 1974년[13]
참조 파라미터에 의한 콜 C++, PHP,[14] C#,[15] Visual Basic.네트워크[16] 1985년[17]
const에 대한 참조에 의한 콜 C++, C 1985년[18]

평가 오더

연산 순서는 식의 추상 구문 트리를 정의하는 반면 평가 순서는 식을 평가하는 순서를 정의합니다.예를 들어 Python 프로그램은

방어하다 f(x):     인쇄물(x)     돌아가다 x  f(1) + f(2)

출력1 2Python의 왼쪽에서 오른쪽 평가 순서 때문이지만 OCaml의 유사한 프로그램:

허락하다 f x =  print_string (string_of_int x); x ;; f 1 + f 2

출력2 1OCaml의 오른쪽에서 왼쪽으로 평가 순서 때문입니다.

평가 순서는 주로 부작용이 있는 코드에서 볼 수 있지만, 엄격한 순서가 명령 스케줄링을 억제하기 때문에 코드의 성능에도 영향을 미칩니다.이 때문에 Java나 C# 등의 언어가 평가 순서를 왼쪽에서[8]: 240–241 오른쪽으로 정의하고 C++17 표준에서는 평가 [19]순서에 제약이 추가되어 있습니다만, C++ 등의 언어 규격에서는 전통적으로 순서가 정의되어 있지 않습니다.

엄격한 평가

적용 순서는 함수를 적용하기 전에 함수의 인수를 완전히 평가하는 평가 순서 집합입니다.[20] 이는 함수를 엄격하게 만드는 효과가 있습니다. 즉, 인수가 정의되지 않은 경우 함수의 결과가 정의되지 않으므로, 적용 순서 평가는 일반적으로 엄격한 평가라고 불립니다.또, 함수 호출은, 순서에서 마주치는 대로 행해지기 때문에, 열성 평가 또는 탐욕 [21][22]평가라고도 불린다.일부 저자는 엄격한 [4]평가가 필요한 값별 콜 바인딩 전략 때문에 엄격한 평가를 "값별 콜"이라고 부릅니다.

일반적인 Lisp, Effel 및 Java는 왼쪽에서 오른쪽으로 함수 인수를 평가합니다.C는 순서를 [23]정의하지 않은 상태로 둡니다.스킴에서는 실행 순서가 [24]인수의 지정되지 않은 순열의 순차적 실행이어야 합니다.OCaml은 마찬가지로 순서를 지정하지 않은 채로 두지만 실제로는 추상 [25]머신의 설계에 따라 인수를 오른쪽에서 왼쪽으로 평가합니다.이 모든 것은 엄격한 평가입니다.

엄격하지 않은 평가

엄격하지 않은 평가 순서는 엄격하지 않은 평가 순서입니다.즉, 함수는 모든 인수를 완전히 [26]: 46–47 평가하기 전에 결과를 반환할 수 있습니다.프로토타입의 예는 정규 순서 평가로,[27] 함수 본문에 인수가 필요할 때까지 인수를 평가하지 않습니다.일반 순서 평가에는 다른 평가 순서가 [28]오류 없이 종료될 때마다 오류 없이 종료되는 특성이 있습니다.이 문서에서는 게으른 평가는 평가 순서가 아닌 구속 기법으로 분류됩니다.그러나 이러한 구분이 항상 따르는 것은 아니며 일부 저자는 게으른 평가를 정상 순서 평가 또는 [29][30]그 반대로 정의하거나 엄격하지 않은 평가와 게으른 [26]: 43–44 평가를 혼동한다.

많은 언어에서 부울 표현은 단락 평가라고 불리는 엄격하지 않은 평가의 형식을 사용합니다.여기서 명확한 부울이 발생한다고 판단되는 즉시 평가가 반환됩니다.예를 들어, 예를 들어 다음과 같은 경우, 논리식(OR)에서true접속 표현식(AND)으로, 또는 접속 표현식(AND)으로,false이 발생하는 등입니다.[30]조건식도 마찬가지로 엄격하지 않은 평가를 사용합니다. 즉, 브랜치 중 하나만 [26]평가됩니다.

적용오더와 정상오더 평가의 비교

일반 순서 평가에서는 고가의 계산, 오류 또는 무한 루프를 포함하는 식은 [4]필요하지 않은 경우 무시되므로 사용자 정의 제어 흐름 구조를 지정할 수 있습니다.이러한 구조물은 해당 순서 평가에서 사용할 수 없습니다.일반 순서 평가에서는 적용 순서 [31]평가에서 사용되는 콜스택과 비교하여 비정치 표현에 thunk 등의 복잡한 구조를 사용합니다.통상적인 순서 평가에서는,[32] 그 복잡성으로 인해, 지금까지 사용 가능한 디버깅툴이 없었습니다.

엄격한 바인딩 전략

값에 의한 콜

Call by value에서는 인수식의 평가치는 함수 내의 대응하는 변수에 바인드됩니다(대부분은 값을 새로운 메모리영역에 복사함으로써).함수 또는 프로시저가 파라미터에 값을 할당할 수 있는 경우 해당 로컬 변수만 할당됩니다.즉, 함수 호출에 전달된 모든 것은 함수가 반환될 때 호출자의 범위에서 변경되지 않습니다.

암묵적 제한

경우에 따라서는 "값별 호출"이라는 용어가 문제가 되는 경우가 있는데, 전달되는 값은 일반적인 값의 의미에 의해 이해되는 변수의 값이 아니라 값에 대한 구현 고유의 참조이기 때문입니다.그 결과 구문적으로 값별 콜처럼 보이는 것이 참조에 의한 콜 또는 공유에 의한 콜처럼 동작할 수 있으며, 종종 언어 의미론의 매우 미묘한 측면에 의존합니다.

참조를 전달하는 이유는 종종 언어가 기술적으로 복잡한 데이터의 값 표현을 제공하지 않고 소스 코드에 값 외관을 보존하면서 데이터 구조로 표현하기 때문입니다.적절한 값과 데이터 구조 사이에 정확히 어디에서 경계가 그려지는지를 예측하는 것은 종종 어렵습니다.C에서 배열은 데이터 구조이지만 배열의 이름은 배열의 첫 번째 요소에 대한 참조(값으로 있음)로 처리되는 반면 구조 변수의 이름은 벡터 필드가 있더라도 값을 참조합니다.Maple에서 벡터는 테이블의 특수한 경우이며 따라서 데이터 구조이지만, 리스트는 값입니다(이것은 정확하게 같은 방법으로 렌더링되고 인덱싱될 수 있습니다).Tcl에서는 값 표현이 스크립트레벨에서 사용되도록 값이 "듀얼 포트"되며 필요에 따라 언어 자체가 대응하는 데이터 구조를 관리합니다.데이터 구조를 통해 이루어진 변경은 값 표현에 다시 반영되며, 그 반대도 마찬가지입니다.

"값이 참조인 경우 값에 의한 호출"이라는 설명이 일반적입니다(단, 참조에 의한 호출로 이해해서는 안 됩니다). 다른 용어는 공유에 의한 호출입니다.따라서 값 Java 또는 Visual Basic과 값 C 또는 Pascal의 콜 동작은 크게 다릅니다.C 또는 Pascal에서는 큰 구조를 가진 함수를 인수로 호출하면 구조 전체가 복사되어 심각한 성능 저하가 발생할 수 있습니다.발신자에게는 보이지 않습니다.그러나 Java 또는 Visual Basic에서는 구조에 대한 참조만 빠르게 복사되고 구조에 대한 돌연변이가 호출자에게 표시됩니다.

참조에 의한 콜

Call by reference(또는 pass by reference)는 파라미터가 값의 복사가 아닌 인수로 사용되는 변수에 대한 암묵적인 참조에 바인드되는 평가 전략입니다.

이는 일반적으로 함수가 인수로 사용되는 변수를 수정할 수 있음을 의미합니다(즉, 에 할당).이것은 발신자가 확인할 수 있는 것입니다.따라서, 참조에 의한 콜은, 착신 함수와 호출 함수 사이에 추가의 통신 채널을 제공하기 위해서 사용할 수 있습니다.참조별 호출 언어는 프로그래머가 함수 호출의 효과를 추적하는 것을 더 어렵게 하며 미묘한 버그를 발생시킬 수 있습니다.언어가 참조에 의한 콜 시멘틱스를 지원하는지 아닌지에 대한 간단한 리트머스 테스트는 기존의 시멘틱스를 작성할 수 있는지 여부입니다.swap(a, b)언어 [33]기능을 합니다.

참조에 의한 콜은 참조(다른 오브젝트의 메모리주소를 나타내는 오브젝트)등의 참조(다른 오브젝트를 참조하는 오브젝트)를 사용하는 것으로, 값에 의한 콜을 사용하고, 참조에 의한 콜을 정확하게 서포트하지 않는 언어로 시뮬레이트 할 수 있습니다.C, ML, Rust 등의 언어에서는 이 기법을 사용합니다.이는 개별 평가 전략(값별 언어 호출)이 아니라 "주소별 호출" 또는 "주소별 전달"이라고도 합니다.ML에서 참조는 Rust와 마찬가지로 유형 및 메모리에 안전합니다.

순수 기능적 언어에서는 일반적으로 두 전략 사이에 의미적 차이가 없습니다(데이터 구조가 불변하기 때문에 함수가 그 인수를 수정할 가능성이 없기 때문에). 따라서 구현이 EF에 대해 내부적으로 참조에 의한 콜을 자주 사용하더라도 일반적으로 값별 콜로 기술됩니다.효율화 혜택.

다음으로 E 프로그래밍 언어로 참조에 의한 콜을 나타내는 예를 나타냅니다. 

def modify(var p, &q) { p : = 27 # passed by value : 로컬파라미터만 수정됨q : = 27 # passed by reference : } ?var a : =1 # var b : =2 # val b : 2 # value : 2 ? modify ( a , & b ) ? # value : 1 ?

다음으로 C에서 참조에 의한 콜을 시뮬레이트하는 주소별 콜의 예를 나타냅니다.

무효 수정하다(인트 p, 인트* q, 인트* r) {     p = 27; // 값에 의해 전달됨: 로컬 매개 변수만 수정됨     *q = 27; // 값 또는 참조에 의해 전달된 경우 콜사이트를 체크하여 어떤 값을 사용할지 판단합니다.     *r = 27; // 값 또는 참조에 의해 전달된 경우 콜사이트를 체크하여 어떤 값을 사용할지 판단합니다. }  인트 주된() {     인트 a = 1;     인트 b = 1;     인트 x = 1;     인트* c = &x;     수정하다(a, &b, c); // a는 값으로 전달되고 b는 포인터를 생성하여 참조로 전달됩니다(값으로 호출).                     // c는 값으로 전달된 포인터입니다.                     // b 및 x가 변경됨     돌아가다 0; }

공유에 의한 콜

Call by sharing(Call by object 또는 call by object-sharing)은 1974년 [13]Barbara Liskov가 CLU 언어에 대해 처음 언급한 평가 전략입니다.Python,[34] Java(개체 참조용), Ruby, JavaScript, Scheme, OCaml, AppleScript 등의 언어에서 사용됩니다.다만, 「공유에 의한 콜」이라는 용어는 일반적으로 사용되고 있지 않습니다.이 용어는, 다른 소스간에 일관성이 없습니다.예를 들어 Java 커뮤니티에서는 Java는 값에 [35]의한 콜이라고 합니다.공유에 의한 호출은 언어의 값이 원시 유형이 아닌 객체에 기반한다는 것을 의미합니다. 즉, 모든 값이 "상자화"된다는 것입니다.이들은 상자에 들어있기 때문에 참조 복사본에 의해 전달된다고 할 수 있습니다(여기서 원시 요소는 통과하기 전에 상자에 들어있고 호출된 함수로 상자 해제됩니다).

공유에 의한 콜의 의미는 참조에 따라 다릅니다.「특히, 콜된 루틴에 의해서 실행되는 인수의 돌연변이가 발신자에게 표시되기 때문에, 값에 의한 콜은 아닙니다.또, 액세스권은 발신자의 변수가 아니고, 특정의 오브젝트에만 주어지기 때문에, 참조에 의해서 호출되는 것이 아닙니다.[36]따라서 예를 들어 변수가 전달된 경우 착신측 범위에서 [37]해당 변수에 대한 할당을 시뮬레이션할 수 없습니다.다만, 함수는 발신자와 같은 오브젝트에 액세스 할 수 있기 때문에(복사는 행해지지 않기 때문에), 오브젝트가 변경 가능한 경우, 그 오브젝트에 대한 변이가 발신자에 의해서 표시됩니다.이러한 변이는, 값의 의미에 의해서 콜과는 다른 것처럼 보일 수 있습니다.함수 내의 가변 객체의 돌연변이는 오브젝트가 복사 또는 복제되지 않고 공유되기 때문에 발신자에게 표시됩니다.

예를 들어 Python에서는 목록이 변경 가능하므로 다음과 같습니다.

방어하다 f(a_리스트):     a_리스트.추가하다(1)  m = [] f(m) 인쇄물(m)

출력[1]왜냐하면appendmethod는 호출된 개체를 변경합니다.

함수내의 할당은, 이러한 언어에서는 변수를 건네주는 것은, 변수에 의해서 참조되는 실제의 오브젝트만을 건네주는 것을 의미하고, 원래의(발신자) 변수에는 액세스 하는 것을 의미하지 않기 때문에, 발신자에게는 인식되지 않습니다.리바운드 변수는 함수의 범위 내에만 존재하기 때문에 발신자 내의 상대는 원래의 바인딩을 유지합니다.

위의 Python 변환과 아래의 코드를 비교하여 형식 인수를 새 객체에 바인딩합니다.

방어하다 f(a_리스트):     a_리스트 = a_리스트 + [1]  m = [] f(m) 인쇄물(m)

출력[]스테이트먼트가a_list + [1]는 참조하는 위치가 아닌 변수에 새 목록을 재할당합니다.

불변 객체의 경우 오브젝트 ID가 언어로 표시되는 경우를 제외하고 공유에 의한 콜과 값에 의한 콜 사이에는 실질적으로 차이가 없습니다.변환 가능한 오브젝트와의 공유에 의한 콜 사용은 입력/출력 파라미터의 대체 수단입니다.파라미터는 에 할당되지 않습니다(인수는 덮어쓰지 않고 오브젝트 ID는 변경되지 않습니다).단, 오브젝트(인수)는 [38]변환됩니다.

복사/복원에 의한 호출

Call by copy-in copy-out, call by value result, call by value return(Fortran 커뮤니티에서 정의됨)이라고도 하는 Call by copy-restore는 제공된 참조가 발신자에게 고유한 특별한 경우입니다.이 변형 맥락과 원격 프로시저 호출:[39]실행의 다른 스레드에 의해서 접근할 수 있다면 함수 호출에 매개 변수가 참조형 다중 처리에,지 않을 때 새로운 참조로 복사될 수 있고 함수 호출이 반환되고, 이 새로운 기준의 업데이트된 내용 다시기 위해서는 모방된 주목을 받았t입니다원래 참조("disclosed")입니다.

복사 복원에 의한 호출의 의미 또한 둘 이상의 함수 인수가 서로 별칭을 짓는 참조에 의한 호출의 의미와 다릅니다(즉, 호출자의 환경에서 동일한 변수를 가리킵니다).참조에 의한 콜에서는, 어느 쪽인가에의 기입은 다른 쪽인가에 영향을 줍니다.복사 복원에 의한 콜은, 기능에 고유의 카피를 주는 것으로써, 이것을 회피합니다만, 어느 쪽의 에일리어스 된 인수가 최초로 카피되는가에 따라, 발신자 환경에서 결과가 정의되지 않은 채로 남습니다.복사는 입력시 및 반환시 모두 왼쪽에서 오른쪽 순서로 작성됩니까?

참조가 초기화되지 않은 착신 측에 전달되면 이 평가 전략은 "call by result"라고 불립니다.

엄격하지 않은 바인딩 전략

이름으로의 콜

이름에 의한 호출은 함수를 호출하기 전에 함수에 대한 인수가 평가되지 않는 평가 전략입니다.대신 함수 본문에 직접 치환되고(캡처 회피 치환을 사용하여), 함수에 나타날 때마다 평가되도록 남겨집니다.함수 본문에서 인수가 사용되지 않는 경우 인수는 평가되지 않습니다.여러 번 사용할 경우 인수가 표시될 때마다 재평가됩니다(Jensen의 디바이스 참조).

경우에 따라서는 콜 바이 밸류 평가보다 콜 바이 네임 평가가 선호될 수 있습니다.함수의 인수가 함수에 사용되지 않는 경우 이름으로 호출하면 인수가 평가되지 않으므로 시간이 절약되지만 값으로 호출하면 인수가 평가됩니다.만약 인수가 종료되지 않는 계산이라면, 이점은 엄청납니다.단, function 인수를 사용하는 경우 이름에 의한 콜 속도가 느려지기 때문에 트렁크 등의 메커니즘이 필요합니다.

오늘의.NET 언어에서는 대리인을 사용하여 이름별로 콜을 시뮬레이트할 수 있습니다.Expression<T>파라미터를 지정합니다.후자의 경우 함수에 추상 구문 트리가 지정됩니다.에펠은 에이전트를 제공하며, 이는 필요할 때 평가할 작업을 나타냅니다.Seed7은 함수 파라미터와 함께 이름으로 콜을 제공합니다.Java 프로그램은 lamda 표현식을 사용하여 유사한 느린 평가를 수행할 수 있습니다.java.util.function.Supplier<T>인터페이스입니다.

필요에 의한 콜

주요 기사 : 게으른 평가

Call by need는 이름별 콜의 메모화된 변형입니다.이 경우 함수 인수가 평가되면 그 값은 나중에 사용하기 위해 저장됩니다.인수가 순수할 경우(즉, 부작용이 없는 경우), 이는 이름별 호출과 동일한 결과를 생성하므로 인수의 재계산 비용이 절감됩니다.

Haskell은 니즈별 평가를 사용하는 유명한 언어입니다.표현의 평가는 계산에서 임의로 발생할 수 있기 때문에 Haskell은 모나드를 사용하여 부작용(예: 돌연변이)만 지원합니다.그러면 지연된 평가 전에 값이 변경되는 변수에서 예기치 않은 동작이 제거됩니다.

필요에 의한 호출의 R의 구현에서, 모든 인수는 전달되며, 이는 R이 임의의 부작용을 허용함을 의미한다.

게으른 평가는 니즈에 의한 콜의 의미론의 가장 일반적인 구현이지만 낙관적인 평가와 같은 변화가 존재합니다.NET 언어는 필요에 따라 다음 유형을 사용하여 콜을 구현합니다.Lazy<T>.

그래프 감소는 게으른 평가를 효율적으로 구현하는 것이다.

매크로 확장에 의한 호출

매크로 전개에 의한 콜은 이름에 의한 콜과 비슷하지만 캡처가 아닌 텍스트 치환을 사용하기 때문에 치환을 피할 수 있습니다.그러나 매크로 치환으로 인해 오류가 발생하여 변수 캡처가 발생하여 원치 않는 동작이 발생할 수 있습니다.위생 매크로에서는 파라미터가 아닌 음영 변수를 확인하고 대체하여 이 문제를 방지합니다.

장래에 의한 콜

"Call by future"는 "이름에 의한 병렬 호출" 또는 "lenient evaluation"[40]이라고도 하며, 엄격한 의미론과 열성적인 평가를 결합한 동시 평가 전략입니다.이 방법에는 세밀한 동적 스케줄링과 동기화가 필요하지만 대규모 병렬 머신에 적합합니다.

이 전략은 기능 본문과 각 기능의 인수에 대한 미래(약속)를 창출합니다.이러한 선물은 프로그램의 나머지 흐름과 동시에 계산됩니다.미래 A가 아직 계산되지 않은 다른 미래 B의 값을 요구할 때 미래 A는 미래 B가 계산을 완료하고 값을 가질 때까지 차단합니다.미래 B가 이미 계산을 마친 경우 즉시 값이 반환됩니다.조건이 조건이 평가될 때까지 차단되고 람다는 완전히 [41]적용될 때까지 미래를 생성하지 않습니다.

프로세스 또는 스레드와 함께 구현되는 경우 미래를 만드는 것은 하나 이상의 새로운 프로세스 또는 스레드를 생성하며, 값에 액세스하는 것은 메인 스레드와 동기화되며, 미래의 계산을 종료하는 것은 그 가치를 계산하는 약속들을 죽이는 것에 해당합니다.Coroutine과 함께 실장되어 있는 경우( 참조).NET async/ait에 의해 장래의 콜이 coroutine(비동기 함수)이 작성됩니다.이 함수는 발신자에게 반환되어 값이 사용되는 타이밍에 반환되어 멀티태스킹이 연계됩니다.

평가는 미래의 창조(즉, 표현이 주어질 때)와 미래의 가치 사용 사이에서 언제든지 발생할 수 있기 때문에 전략은 비결정론적이다.함수 본문이 인수를 평가하기 전에 값을 반환할 수 있기 때문에 이 전략은 엄격하지 않습니다.그러나 대부분의 구현에서는 불필요한 인수를 평가하는 동안 실행이 중단될 수 있습니다.예를 들어, 프로그램은

f x = 1/x g y = 1 주된 = 인쇄물 (g (f 0))

가지고 있을 수도 있다g전에 끝내다f출력 1 또는 에러가 발생할 수 있습니다.1/0를 클릭합니다.[26]

Call-by-future는 한 번만 값이 계산된다는 점에서 요구에 의한 Call과 유사합니다.오류 및 비종단을 신중하게 처리함으로써, 특히 필요하지 않다고 판단될 경우 중간중간에 미래를 종료하기 때문에, Call-by-Future는 Call-by-Need [41]평가와 동일한 종료 속성을 가집니다.단, Call-by-Future는 Call-by-Need에 비해 불필요한 추측성 작업을 수행할 수 있습니다.예를 들어 느린 데이터 [26]구조를 깊이 평가하는 것입니다.이는 값이 확실히 필요할 때까지 계산을 시작하지 않는 느린 미래를 사용함으로써 피할 수 있습니다.

낙관적 평가

낙관적 평가는 함수의 인수가 일정 시간 동안(실행 시 조정될 수 있음) 값별 호출 스타일로 부분적으로 평가되는 니즈별 호출 변형입니다.이 시간이 경과하면 평가가 중단되고 필요에 따라 [42]콜을 사용하여 기능이 적용됩니다.이 접근방식을 통해 원하는 종료 특성을 유지하면서 니즈에 따른 호출에 따른 런타임 비용을 일부 절감할 수 있습니다.

「 」를 참조해 주세요.

레퍼런스

  1. ^ Araki, Shota; Nishizaki, Shin-ya (November 2014). "Call-by-name evaluation of RPC and RMI calculi". Theory and Practice of Computation: 1. doi:10.1142/9789814612883_0001. ISBN 978-981-4612-87-6. Retrieved 21 August 2021.
  2. ^ Turbak, Franklyn; Gifford, David (18 July 2008). Design Concepts in Programming Languages. MIT Press. p. 309. ISBN 978-0-262-30315-6.
  3. ^ Crank, Erik; Felleisen, Matthias (1991). "Parameter-passing and the lambda calculus". Proceedings of the 18th ACM SIGPLAN-SIGACT Symposium on Principles of Programming Languages - POPL '91: 2. CiteSeerX 10.1.1.23.4385. doi:10.1145/99583.99616. ISBN 0897914198. S2CID 5782416.
  4. ^ a b c Wilhelm, Reinhard; Seidl, Helmut (10 November 2010). Compiler Design: Virtual Machines. Springer Science & Business Media. p. 61. ISBN 978-3-642-14909-2.
  5. ^ Nita, Stefania Loredana; Mihailescu, Marius (2017). "Introduction". Practical Concurrent Haskell: 3. doi:10.1007/978-1-4842-2781-7_1. ISBN 978-1-4842-2780-0.
  6. ^ Pierce, Benjamin C. (2002). Types and Programming Languages. MIT Press. p. 56. ISBN 0-262-16209-1.
  7. ^ Daniel P. Friedman; Mitchell Wand (2008). Essentials of Programming Languages (third ed.). Cambridge, MA: The MIT Press. ISBN 978-0262062794.
  8. ^ a b Scott, Michael Lee (2016). Programming language pragmatics (Fourth ed.). Waltham, MA: Elsevier. ISBN 9780124104778.
  9. ^ Hasti, Rebecca. "Parameter Passing". CS 536: Introduction to Programming Languages and Compilers. University of Wisconsin. Retrieved 22 August 2021.
  10. ^ Bundy, Alan; Wallen, Lincoln (1984). "SASL". Catalogue of Artificial Intelligence Tools: 117. doi:10.1007/978-3-642-96868-6_222. ISBN 978-3-540-13938-6. Was probably the first language to systematically exploit the power of lazy evaluation.
  11. ^ Fay, Colin (30 July 2018). "About lazy evaluation". R-bloggers. Retrieved 21 August 2021.
  12. ^ Wadsworth, Christopher P. (1971). Semantics and Pragmatics of the Lambda Calculus (PhD). Oxford University.
  13. ^ a b Liskov, Barbara; Atkinson, Russ; Bloom, Toby; Moss, Eliot; Schaffert, Craig; Scheifler, Craig; Snyder, Alan (October 1979). "CLU Reference Manual" (PDF). Laboratory for Computer Science. Massachusetts Institute of Technology. Archived from the original (PDF) on 2006-09-22. Retrieved 2011-05-19.
  14. ^ "PHP: Passing by Reference - Manual". www.php.net. Retrieved 2021-07-04.
  15. ^ BillWagner. "Passing Parameters - C# Programming Guide". docs.microsoft.com. Retrieved 2021-07-04.
  16. ^ KathleenDollard. "Passing Arguments by Value and by Reference - Visual Basic". docs.microsoft.com. Retrieved 2021-07-04.
  17. ^ "History of C++". en.cppreference.com. Retrieved 11 June 2022.
  18. ^ "History of C++". en.cppreference.com. Retrieved 11 June 2022.
  19. ^ Filipek, Bartlomiej. "Stricter Expression Evaluation Order in C++17". C++ Stories. Retrieved 24 August 2021.
  20. ^ Abelson, Harold; Sussman, Gerald Jay (1996). "Normal Order and Applicative Order". Structure and interpretation of computer programs (Second ed.). Cambridge, Mass.: MIT Press. ISBN 0-262-01153-0.
  21. ^ Reese, Richard M. (14 October 2015). Learning Java Functional Programming. Packt Publishing Ltd. p. 106. ISBN 978-1-78528-935-4.
  22. ^ Antani, Ved; Timms, Simon; Mantyla, Dan (31 August 2016). JavaScript: Functional Programming for JavaScript Developers. Packt Publishing Ltd. p. 614. ISBN 978-1-78712-557-5.
  23. ^ Seacord, Robert C. "EXP30-C. Do not depend on the order of evaluation for side effects". SEI CERT C Coding Standard. Carnegie Mellon University. Retrieved 23 August 2021.
  24. ^ Anglade, S.; Lacrampe, J. J.; Queinnec, C. (October 1994). "Semantics of combinations in scheme" (PDF). ACM SIGPLAN Lisp Pointers. VII (4): 15–20. doi:10.1145/382109.382669. S2CID 2987427.
  25. ^ "Why are OCaml function arguments evaluated right-to-left?". OCaml. 30 November 2017.
  26. ^ a b c d e Tremblay, G. (April 2000). "Lenient evaluation is neither strict nor lazy". Computer Languages. 26 (1): 43–66. CiteSeerX 10.1.1.137.9885. doi:10.1016/S0096-0551(01)00006-6.
  27. ^ George, Lai (March 1987). Efficient evaluation of normal order through strictness information (MSc). University of Utah. p. 10.
  28. ^ Borning, Alan (Autumn 1999). "Applicative vs Normal Order Evaluation in Functional Languages" (PDF). CSE 505: Concepts of Programming Languages. University of Washington. Retrieved 23 August 2021.
  29. ^ Abelson, Harold; Sussman, Gerald Jay (1996). "Normal Order and Applicative Order". Structure and interpretation of computer programs (Second ed.). Cambridge, Mass.: MIT Press. ISBN 0-262-01153-0.
  30. ^ a b Sturm, Oliver (11 April 2011). Functional Programming in C#: Classic Programming Techniques for Modern Projects. John Wiley and Sons. p. 91. ISBN 978-0-470-74458-1.
  31. ^ Marlow, Simon. "Why can't I get a stack trace?". Haskell Implementors Workshop 2012. Retrieved 25 August 2021.
  32. ^ Nilsson, Henrik (1999). "Tracing piece by piece: affordable debugging for lazy functional languages". Proceedings of the Fourth ACM SIGPLAN International Conference on Functional Programming - ICFP '99: 36–47. CiteSeerX 10.1.1.451.6513. doi:10.1145/317636.317782. S2CID 13954359.
  33. ^ "Java is Pass-by-Value, Dammit!". 16 May 2001. Retrieved 2016-12-24.
  34. ^ Lundh, Fredrik. "Call By Object". effbot.org. Retrieved 2011-05-19.
  35. ^ "Java is Pass-by-Value, Dammit!". 16 May 2001. Retrieved 2016-12-24.
  36. ^ CLU 참조 설명서(1974), 페이지 14-15. 오류::
  37. ^ 주의: CLU 언어에서 "variable"은 변수의 일반적인/통상적인 의미가 아니라 현대 표준 용법에서 "identifier" 및 "pointinter"에 해당합니다.
  38. ^ "CA1021: Avoid out parameters". Microsoft.
  39. ^ "RPC: Remote Procedure Call Protocol Specification Version 2". tools.ietf.org. IETF. Retrieved 7 April 2018.
  40. ^ McCollin, Thomas Gwynfryn; Morell, Tobias. "A Game of Paradigms: A Usability Study of Functional Idioms in Gameplay Programming" (PDF). Aalborg University. p. 6. Retrieved 11 January 2022.
  41. ^ a b Schauser, Klaus E.; Goldstein, Seth C. (1995). "How much non-strictness do lenient programs require?" (PDF). Proceedings of the Seventh International Conference on Functional Programming Languages and Computer Architecture - FPCA '95: 216–225. doi:10.1145/224164.224208. ISBN 0897917197. S2CID 2045943. Retrieved 7 January 2022.
  42. ^ Ennals, Robert; Jones, Simon Peyton (August 2003). "Optimistic Evaluation: a fast evaluation strategy for non-strict programs".


추가 정보

외부 링크