컴파일 타임 보장에 대해 더 연구하지 않는 이유는 무엇입니까?

나는 컴파일 시간 인 모든 것을 좋아하며 일단 프로그램을 컴파일하면 실행에 대해 많은 보장이 이루어집니다. 일반적으로 정적 유형 시스템 (Haskell, C ++, ...)은 동적 유형 시스템보다 강력한 컴파일 타임 보장을 제공하는 것 같습니다.

내가 이해 한 바에 따르면, Ada는 컴파일 시간 검사와 관련하여 훨씬 더 나아가고 실행 전에 더 많은 버그를 감지 할 수 있습니다. 또한 특정 시점에 (프로그래밍 오류가 인명을 초래할 수있는) 섬세한 분야를 위해 선택되었다는 점을 고려하면 상당히 안전한 것으로 간주됩니다.

더 강력한 정적 보장이 더 문서화되고 안전한 코드로 이어진다면 왜 더 많은 방향으로 연구하지 않습니까?

누락 된 것으로 보이는 것의 예는 int기본 아키텍처의 비트 수에 의해 결정되는 범위를 갖는 일반 유형을 정의하는 대신 범위를 가질 수있는 언어입니다 (다음 예 Int [a..b]에서는 사이에 정수 유형을 설명합니다) a와 b 포함) :

a : Int [1..24]
b : Int [1..12]
a + b : Int [2..36]
a - b : Int [-11..23]
b - a : Int [-23..11]

또는 (Ada에서 가져옴) :

a : Int [mod 24]
b : Int [mod 24]
a + b : Int [mod 24]

이 언어는 범위에 가장 적합한 기본 유형을 선택하고 표현식에서 컴파일 시간 검사를 수행합니다. 예를 들어 다음과 같이 주어집니다.

a : Int [-3..24]
b : Int [3..10]

그때:

a / b

정의되지 않습니다.

이것은 단지 예일 뿐이지 만 컴파일 타임에 시행 할 수있는 것이 더 많다고 생각합니다. 그래서 왜 이것에 대한 연구가 거의 보이지 않습니까? 이 아이디어를 설명하는 기술 용어는 무엇입니까 (이 주제에 대한 추가 정보를 찾을 수 있도록)? 한계는 무엇입니까?

내가 얼마나 말할 수있는 위치에 아닙니다 더 주제에 수행해야 연구 만이 있음을 나는 말할 수 있다 수행되는 연구는 예를 들어, VeriSoft의 XT는 독일 정부의 지원 프로그램.

내가 생각하는 개념을 공식 검증 및 계약 기반 프로그래밍 이라고 하며, 후자는 프로그래머에게 친숙한 방법입니다. 계약 기반 프로그래밍에서는 먼저 코드를 정상적으로 작성하고 소위 계약 을 코드에 삽입 하십시오. 이 패러다임에 기반을 둔 쉽게 사용할 수있는 언어는 Microsoft Research의 Spec # 이며, 온라인에서 사용해 볼 수 있는 기능적으로 유사하지만 약간 적은 C # 용 코드 계약 확장입니다 (다른 언어에 대한 유사한 도구도 있음). ). 언급 한 "int with range type"은 함수에서 두 개의 계약에 의해 반영됩니다.

Contract.Requires(-3 <= a && a <= 24);
Contract.Requires( 3 <= b && b <= 10);

해당 함수를 호출하려면 이러한 기준을 충족하도록 보장 된 매개 변수를 사용해야합니다. 그렇지 않으면 컴파일 시간 오류가 발생합니다. 위의 내용은 매우 간단한 계약으로, 변수 또는 예외에 대한 거의 모든 가정 또는 요구 사항과 생각할 수있는 관계를 삽입 할 수 있으며 컴파일러는 모든 요구 사항이 가정 또는 보장 할 수있는 것 (예 : 파생 된 것)에 의해 포함되는지 확인합니다. 가정에서. 그렇기 때문에 이름이 유래하는 이유는 다음과 같습니다. 수신자가 요구 사항 을 작성하면 발신자 는 비즈니스 계약에서와 같이 요구 사항 이 충족 되도록 합니다.

$P(x_1,x_2,...,x_n)$$n$$P$사용. CS 측면에서이 두 가지가 프로세스의 중요한 부분입니다. 검증 조건 생성이 까다 롭고 SMT는 고려 된 이론에 따라 NP- 완전 또는 결정 불가능한 문제입니다. SMT 솔버에 대한 경쟁 조차 있기 때문에 확실히 이것에 대한 몇 가지 연구가 진행됩니다. 또한, SMT는 현재 가장 현대적인 접근 방식이지만, SMT는 상태 공간 열거, 상징적 모델 확인, 경계 모델 확인 등과 같은 공식 검증을 위해 SMT를 사용하는 대체 방법이 있습니다.

일반적인 아이디어의 한계와 관련하여 :

• 앞에서 언급했듯이 프로그램의 정확성을 입증하는 것은 계산 상 어려운 문제이므로 계약 (또는 다른 형식의 사양)이있는 프로그램의 컴파일 시간 확인에 실제로 시간이 오래 걸리거나 불가능할 수도 있습니다. 대부분의 시간에 잘 작동하는 휴리스틱을 적용하는 것이 가장 좋습니다.
• 프로그램에 대해 더 많이 지정할수록 사양 자체에 버그가있을 확률이 높아집니다 . 이로 인해 프로그램에 여전히 버그가 있어도 오 탐지 (모든 것이 버그가 없어도 컴파일 시간 검사가 실패 함) 또는 안전하다는 잘못된 인상으로 이어질 수 있습니다.
• 계약이나 사양을 작성하는 것은 실제로 지루한 작업이며 대부분의 프로그래머는 너무 게으르다. 언제 어디서나 코드 계약으로 C # 프로그램을 작성해보십시오. 그렇기 때문에 공식 검증이 일반적으로 비행기 나 자동차를 제어하는 ​​소프트웨어와 같은 하드웨어 설계 및 안전에 중요한 시스템에 사용됩니다.

확실히 위의 설명에 맞지 않는 마지막 한가지 가치에 대한 언급은 "암시 적 복잡성 이론"라는 필드, 예를 들면이다 이 논문 . 작성할 수있는 각 프로그램이 특정 복잡성 클래스 (예 : P)에 속하는 프로그래밍 언어의 특성을 분석하는 것을 목표로합니다. 이러한 언어에서 작성하는 각 프로그램은 다항식 런타임이되도록 자동으로 "확장되어" "확인"될 수 있습니다. 컴파일 타임에 단순히 프로그램을 컴파일하여. 그러나이 연구의 실질적으로 유용한 결과는 알지 못하지만 전문가는 아닙니다.