종속 유형 및 프로그래밍 계약에 대한 기사를 읽었습니다. 내가 읽은 대부분의 것에서 계약은 동적으로 제약 조건을 확인하고 종속 유형을 정적으로 확인하는 것으로 보입니다.
부분적으로 정적으로 계약을 체결 할 수 있다고 생각한 논문이 있습니다.
이로 인해 상당한 양의 중복이 발생하는 것으로 보이며 계약 대 종속 유형의 분류가 사라지기 시작합니다.
내가 놓친 개념 중 하나에 더 깊은 것이 있습니까? 아니면 이것들이 실제로 동일한 기본 개념을 나타내는 퍼지 범주입니까?
답변:
실질적으로 계약은 명제입니다. 프로그램의 개별 실행에 대한 (정량없는) 속성을 확인할 수 있습니다. 계약 확인의 핵심은 비난이라는 개념입니다. 기본적으로 계약 위반으로 누가 잘못했는지 알고 싶어합니다. 이것은 구현 (약속 된 값을 계산하지 않음) 또는 호출자 (잘못된 종류의 값을 함수에 전달한 사람) 일 수 있습니다.
핵심 통찰력은 도메인 이론의 역 제한 구성에서 임베딩 프로젝션 쌍과 동일한 기계를 사용하여 비난을 추적 할 수 있다는 것입니다. 기본적으로 어설 션 작업에서 어설 션 쌍 작업으로 전환합니다. 하나는 프로그램 컨텍스트를 비난하고 다른 하나는 프로그램을 비난합니다. 그런 다음 어설 션 쌍을 교체하여 함수 공간의 상호 분산을 모델링 할 수 있으므로 고차 함수를 계약으로 래핑 할 수 있습니다. 예를 들어 Nick Benton의 논문 "Undoing Dynamic Typing"을 참조하십시오 .
종속 유형은 유형입니다. 유형은 특정 프로그램의 허용 여부를 주장하는 규칙을 지정합니다. 결과적으로, 그들은 비난의 개념과 같은 것들을 포함하지 않습니다. 왜냐하면 그들의 기능은 처음에 악의로 행동하는 프로그램이 존재하는 것을 막기 때문입니다. 잘 구성된 프로그램 만이 문법적으로 발언되기 때문에 비난 할 것은 없습니다. 실용적으로, 이는 한정자를 사용하여 항의 속성을 말하기 위해 종속 유형을 사용하는 것이 매우 쉽다는 것을 의미합니다 (예 : 함수가 모든 입력에 대해 작동 함).
이 두 가지 견해는 동일하지 않지만 관련이 있습니다. 기본적으로 요점은 계약을 통해 보편적 인 가치 영역으로 시작하고 계약을 사용하여 사물을 줄이는 것입니다. 그러나 유형을 사용할 때 더 작은 값의 도메인을 원하는 속성으로 지정하려고합니다. 따라서 유형 지정 관계를 통해 두 관계를 연결할 수 있습니다 (즉, 논리 관계). 예를 들어 Ahmed, Findler, Siek 및 Wadler의 최근 "Blame for All" 또는 Reynolds의 "유형의 의미 : 내재적 의미에서 외적 의미론"을 참조하십시오 .
유형과 계약이 공격하는 (공정하게 추상적 인) 문제는 "프로그램이 특정 속성을 갖도록하는 방법"입니다. 여기에는 더 넓은 종류의 속성을 표현할 수있는 것과 프로그램에 속성이 있는지 없는지를 확인할 수있는 것 사이에 고유 한 긴장이 있습니다. 유형 시스템은 일반적으로 매우 특정한 속성을 보장하고 (프로그램은 특정 방식으로 충돌하지 않음) 유형 검사 알고리즘을 갖습니다. 반면에 계약을 사용하면 매우 광범위한 속성 (예 :이 프로그램의 출력이 소수 임)을 지정할 수 있지만 검사 알고리즘은 제공되지 않습니다.
그럼에도 불구하고 계약 검사 알고리즘이 항상 작동한다는 것은 계약 검사 알고리즘이 거의 없다는 것을 의미하지는 않습니다 (실제로 작동하는 경향이 있음). Frama-C의 Spec # 및 Jessie 플러그인 을 살펴 보는 것이 좋습니다 . 둘 다 "이 프로그램은이 계약을 준수합니다"를 1 차 논리 의 진술로 표현함으로써 작동합니다. 를 검증 조건 생성을 통해 다음 SMT에 요청함으로써 작동합니다.솔버가 증거를 찾아보십시오. 솔버가 증거를 찾지 못하면 프로그램이 잘못되었거나 솔버가 존재하는 증거를 찾지 못했습니다. (이것이 "거의"계약 확인 알고리즘 인 이유입니다.) 상징적 실행을 기반으로하는 도구도 있습니다. 이는 "이 프로그램이이 계약을 준수합니다"라는 제안이 여러 논리로 표현됨을 의미합니다. 예를 들어 jStar 를 참조하십시오 .
Flanagan의 연구는 유형과 같은 속성을 신속하게 확인한 다음 나머지를 위해 노력할 수 있도록 두 세계에서 가장 좋은 것을 취하려고합니다. 필자는 하이브리드 유형에 익숙하지 않지만 저자는 자신의 동기가 주석이 덜 필요한 솔루션을 제안했다는 것을 기억합니다 (이전 ESC / Java에 대한 이전 작업보다). 그러나 어떤 의미에서는 ESC / Java (및 Spec #)에서 유형과 계약간에 일부 느슨한 통합이 있습니다. 계약을 확인할 때 솔버는 유형 점검이 성공하여 해당 정보를 얻을 수 있다고 알려줍니다.
계약은 정적으로 확인할 수 있습니다. ESC / Haskell 에 대한 Dana Xu의 오래된 작업을 살펴보면 컴파일 타임에 전체 계약 확인을 구현할 수 있었으며 산술에 대한 정리 증명 자만 사용했습니다. 올바르게 기억하면 종료는 간단한 깊이 제한으로 해결됩니다.
계약과 유형 모두 기능에 대한 Hoare 스타일 (사전 / 사후 조건) 사양을 나타낼 수 있습니다. 둘 다 컴파일 타임에 정적으로 또는 런타임에 동적으로 확인할 수 있습니다.
종속 유형을 사용하면 계약 시스템 프로그래머가 예상하는 유형의 유형 인 유형 시스템에서 매우 광범위한 속성을 인코딩 할 수 있습니다. 유형의 값에 따라 달라질 수 있기 때문 입니다. 필자가 인용 한 논문이 다른 접근 방식을보고 있다고 생각하지만 종속 유형은 정적으로 확인되는 경향이 있습니다.
궁극적으로 차이는 거의 없습니다. 필자는 종속 형식이 사양을 표현할 수있는 논리 인 반면 계약은 사양을 표현하는 프로그래밍 방법론이라고 생각합니다.