타입 체커에 대한 정확성 증명은 실제로 무엇을 증명해야합니까?

나는 몇 년 동안 프로그래밍을 해왔지만 이론적 인 CS에는 익숙하지 않습니다. 나는 최근에 프로그래밍 언어를 연구하려고 노력했으며 그 일부로 유형 검사 및 추론을 시도했습니다.

내 질문은 프로그래밍 언어에 대한 형식 유추 및 검사 프로그램을 작성하려고하는데 형식 검사기가 작동한다는 것을 증명하고 싶다면 내가 찾고있는 증거는 정확히 무엇입니까?

평범한 언어로, 유형 검사기가 런타임에 발생할 수있는 코드 조각의 오류를 식별 할 수 있기를 바랍니다. Coq과 같은 것을 사용하여 구현이 올바른지 증명하려고하면이 "정확성 증명"이 정확히 무엇을 보여 주려고합니까?

coq type-inference proof-assistants

— 비벡 가이사 스
소스

(1) 구현에서 지정된 타이핑 시스템

구현 하는지 여부 또는 (2) 타이핑 시스템

가 생각하는 오류를 방지 하는지 여부를 알고 싶을 수도 있습니다 . 그들은 다른 질문입니다.

T

$T$

T

$T$

— Martin Berger

@MartinBerger : 아, 그 차이를 건너 뛰는 것 같습니다. 내 실제 질문은 아마 두 가지 모두를 묻는 것입니다. 컨텍스트는 언어를 작성하려고하는데 유형 검사기를 작성하는 것입니다. 그리고 사람들은 시험되고 검증 된 알고리즘을 사용하도록 요청했습니다. 내가 사용하고있는 알고리즘과 타입 체커가 "정확한"것인지 "증명"하는 것이 얼마나 어려운지 알고 싶었다. 따라서 내 질문에 애매 모호합니다.

— Vivek Ghaisas

2 + "hello"

M

$M$

n \geq

$n \geq$

M

$M$

n

$n$

N

$N$

N

$N$

이것은 일반적으로

에 대한 유도와 타이핑 판결의 유도에 의해 입증됩니다 . (2/2)

n

$n$

— Martin Berger

감사합니다! 귀하의 설명에 따르면 (2)는 실제로 내가 찾던 것 같습니다. 대답 해 주시겠습니까? (그리고 아마도 유용하다고 생각되는 세부 사항을 추가하십시오.) 나는 그것을 대답으로 받아 들일 것입니다! :)

— Vivek Ghaisas

답변:

질문은 두 가지 방식으로 해석 될 수 있습니다.

구현이 주어진 입력 시스템 구현 않습니다 여부 ? $T$
타이핑 시스템 가 생각해야하는 오류를 방지 하는지 여부 $T$

전자는 실제로 프로그램 확인에 대한 질문이며 입력과는 거의 관련이 없습니다. 구현이 사양을 충족 함을 보여 주기만하면됩니다. Andrej의 답변을 참조하십시오.

나중의 질문에 대해 이야기하겠습니다. Andrej가 말했듯이 추상적 인 관점에서 타이핑 시스템은 프로그램에 속성을 적용하는 것으로 보입니다. 실제로, 타이핑 시스템 ( 에러가 발생하는 것을 방지하려고 노력하는데, 이는 타이핑 가능한 프로그램이 관심있는 에러 클래스를 나타내지 않아야한다는 것을 의미한다. 가 생각 작동 한다는 것을 보여 주려면 두 가지를해야합니다. $T$ $T$

먼저, 프로그램에 즉각적인 타이핑 오류가 발생 하는 의미를 공식적으로 정의 합니다 . 이것을 정의 할 수있는 방법은 여러 가지가 있습니다. 그것은 당신에게 달려 있습니다. 일반적으로 우리는 같은 프로그램을 방지하고 싶습니다 2 + "hello". 즉, 프로그램의 하위 집합을 정의 그들을 호출 할 필요가 나쁜 즉시 입력 오류로 정확하게 프로그램이 포함되어 있습니다.
$\Gamma \vdash M : \alpha.$ $M$ $\alpha$ $\Gamma$

$\Gamma \vdash M : \alpha$ $M \rightarrow \cdots \rightarrow N$ $N \notin$

이 정리를 증명하는 방법은 언어의 세부 사항, 타이핑 시스템 및 선택한 Bad 옵션에 따라 다릅니다 .

$M$ $M \rightarrow N$ $M$

$\Gamma \vdash M : \alpha$ $M \rightarrow N$ $\Gamma \vdash N : \alpha$
$\Gamma \vdash M : \alpha$ $M$

모든 타이핑 시스템에 세션 유형과 같은 "대상 축소"기능이있는 것은 아닙니다. 이 경우 더 정교한 증명 기술이 필요합니다.

— 마틴 버거
소스

그건 좋은 질문이야! 형식화 된 언어로 된 유형에서 예상되는 내용을 묻습니다.

먼저, 우리는 단일 유형으로 모든 프로그래밍 언어를 입력 할 수 있습니다 . 문자를 고르고 U모든 프로그램에 유형이 있다고 말합니다 U. 이것은별로 유용하지 않지만 중요합니다.

$e$ $A$ $e$ $A$ $A$ int

당신의 유형이 얼마나 표현력이 좋을지는 끝이 없습니다. 원칙적으로 그것들은 어떤 종류의 논리적 진술 일 수도 있고, 범주 이론과 기타 등등을 사용할 수도 있습니다. 예를 들어, 종속 유형을 사용하면 "이 함수는 목록을 출력하여 정렬 된 입력이되도록 목록을 매핑합니다"와 같은 것을 표현할 수 있습니다. 현재 동시 프로그램이 공유 상태와 작동하는 방식에 대해 이야기 할 수있는 "동시 분리 논리"에 대한 이야기를 듣고있는 순간부터 더 나아갈 수 있습니다. 멋진 물건.

프로그래밍 언어 디자인의 유형 기술은 표현력과 단순성 의 균형 을 유지하는 것 중 하나입니다 .

보다 표현적인 유형을 통해 우리 자신과 컴파일러에게 더 자세한 내용을 설명 할 수 있습니다.
더 간단한 유형은 이해하기 쉽고 컴파일러에서 더 쉽게 자동화 할 수 있습니다. (사람들은 유형 검사를 수행하기 위해 기본적으로 교정 보조 및 사용자 입력이 필요한 유형을 제시합니다.)

모든 프로그래머가 프로그래밍 언어 이론에서 박사 학위를 가지고있는 것은 아니기 때문에 단순성을 과소 평가해서는 안됩니다.

다시 질문으로 돌아 갑시다 : 타입 시스템이 좋은지 어떻게 알 수 있습니까? 글쎄, 당신의 유형이 균형을 이루고 있다는 이론을 증명하십시오. 두 종류의 정리가 있습니다 :

당신의 타입이 유용 하다고 말하는 정리 . 프로그램에 유형이 있음을 알면 프로그램이 멈추지 않는다는 것을 보증해야합니다 ( 안전 정리 가 될 것입니다 ). 또 다른 이론 정리는 유형을 시맨틱 모델에 연결 하여 실제 수학을 사용하여 프로그램에 대한 사항을 증명할 수 있습니다 ( 적정성 이론 및 기타 많은 것들). 위의 단일 유형은 유용한 이론이 없기 때문에 나쁩니다.
당신의 타입이 단순 하다고 말하는 정리 . 기본 표현식은 주어진 표현식에 주어진 유형이 있는지 여부를 결정할 수 있다는 것입니다. 또 다른 단순 기능은 형식을 유추하는 알고리즘을 제공하는 것입니다. 단순성에 대한 다른 이론은식이 최대 하나의 형식을 갖거나식이 기본 형식 (즉, 모든 형식 중에서 "최고의"형식)을 갖는다는 것입니다.

유형은 매우 일반적인 메커니즘이므로 더 구체적으로 지정하기가 어렵습니다. 하지만 당신이 쏴야 할 것을보기를 바랍니다. 프로그래밍 언어 디자인의 대부분의 측면과 마찬가지로 절대적인 성공 척도는 없습니다. 대신, 설계 가능성의 공간이 있으며, 중요한 것은 공간의 현재 위치 또는 원하는 위치를 이해하는 것입니다.

— 안드레이 바우어
소스

자세한 답변 감사합니다! 그러나 여전히 내 질문에 대한 답변이 확실하지 않습니다. 구체적인 예를 들어, 간단하고 충분한 유형 시스템을 가진 정적으로 유형이 지정된 언어 인 C를 살펴 보겠습니다. C에 대한 typechecker를 작성한 경우 typechecker가 "올바르다"는 것을 어떻게 증명할 수 있습니까? HK와 같이 Haskell에 대한 유형 검사기를 작성하면이 답변은 어떻게 변경됩니까? 이제 "정확함"을 어떻게 증명할 수 있습니까?

— Vivek Ghaisas

T

$T$

e

$e$

A

$A$

T

$T$

e

$e$

A

$A$

2와 3을 함께 사용하는 것이 좋습니다. 또한 CompCert를 살펴 보십시오 .

— Andrej Bauer

T

$T$

e

$e$

A

$A$

e

$e$

A

$A$

e

$e$

A

$A$

A

$A$

e

$e$

"나의 typechecker가 작동한다는 것을 증명"한다는 의미는 몇 가지가 있습니다. 어느 것이 당신의 질문이 요구하는 것의 일부라고 생각합니다.)

이 질문의 절반은 타입 이론 이 언어의 속성을 증명할 수있을만큼 충분하다는 것을 증명합니다. Andrej의 답변은 이 영역을 잘 다루고 있습니다. 질문의 나머지 절반은 언어와 해당 유형 시스템이 이미 고정되어 있다고 가정합니다. 특정 유형 검사기가 실제로 유형 시스템을 올바르게 구현하고 있음을 어떻게 증명할 수 있습니까? 여기에 두 가지 주요 관점이 있습니다.

하나는 : 특정 구현이 사양과 일치한다고 어떻게 믿을 수 있습니까? 원하는 보증 정도에 따라 대규모 테스트 스위트에 만족할 수도 있고, 공식적인 검증을 원할 수도 있고, 또는 두 가지를 혼합하여 사용할 수도 있습니다 . 이 관점의 장점은 그것이 주장하고있는 주장에 경계를 설정하는 것의 중요성을 실제로 강조한다는 것입니다. "정확한"이 정확히 무엇을 의미합니까? 가정 된 올바른 TCB의 어느 부분과 비교하여 코드의 어느 부분이 점검됩니까? 단점. 이것에 대해 너무 열심히 생각 하면 하나의 철학적 토끼 구멍 이 생깁니다. 토끼 구멍 이 마음에 들지 않으면 "약점"입니다.

두 번째 관점은 정확성에 대한 수학적 계산입니다. 수학에서 언어를 다룰 때 우리는 종종 "이론"에 대한 "모델"을 설정 한 다음 그 반대의 경우를 증명하려고 시도합니다. 우리가 이론에서 할 수있는 모델에서 할 수있는 모든 것. ( 건전성 과 완전성정리. 구문 이론 또는 시맨틱 모델에서 "시작했는지"에 따라 달라집니다.) 이러한 사고 방식을 통해 유형 확인 구현을 해당 유형 이론의 특정 모델로 생각할 수 있습니다. 따라서 구현이 수행 할 수있는 것과 수행 할 수있는 이론에 따라 수행되는 양방향 통신을 증명하고자합니다. 이 관점의 단점은 모든 코너 사례를 다루 었는지 여부, 구현이 형식 안전으로 허용 해야하는 프로그램을 남기지 않는다는 의미에서 구현이 완료되었는지 여부 및 구현이 올바른지 여부에 실제로 중점을 둡니다. 어떤 프로그램에서도 잘못된 형식으로 거부해서는 안된다는 의미. 단점은 통신 증명이 구현 자체와 상당히 분리 될 가능성이 있다는 것입니다.

— 렌 로마노
소스

"이 관점의 반대편은 모델이 건전하지만 완벽하지 않은 경우 특히 모든 코너 케이스를 다루 었는지 여부에 중점을두고 있다는 점"에 동의 할 수 없습니다. 다른 관점을 제안하고자합니다. 모델을 거치는 것은 예를 들어 모델이 더 단순하기 때문에 다양한 이유로 사용 하는 우연한 증명 기술 입니다. 모델을 거치는 것에 대해 철학적으로 더 위엄있는 것은 없습니다. 궁극적으로 실제 실행 파일과 그 동작에 대해 알고 싶습니다.

— Martin Berger

나는 "모델"과 "이론"이 넓은 의미로 여겨졌다 고 생각했으며, "건전성 + 완전성 정리"를 통해 양방향 통신을 설정하려는 노력의 중요성을 강조했습니다. (또한 이것이 중요하다고 생각하고 Andrej의 게시물에 댓글을 달았습니다.) 어떤 상황에서는 건전성 정리 (또는 관점에 따라 완전성 정리) 만 증명할 수 있지만 두 방향을 모두 갖는 것은 사실입니다 마음에 유용한 방법 론적 제약이 있습니다.

— Noam Zeilberger 2018 년

마틴은“NoamZeilberger는“질문이 너무나 많은 다른 것을 의미하게 만들 수 있느냐”고 말했다.

— Martin Berger

타이핑 시스템과 프로그래밍 언어 의미에 대해 배웠을 때, 모델은 그 자체로 끝나는 것이 아니라, 운영 의미론에 대한 증명 기법 일 뿐이라는 것을 깨달았습니다.

— Martin Berger

견고성과 완전성을 통해 다른 모델을 연결하는 것은 통찰력을 전달하는 데 중요한 과학적 방법입니다.

— Martin Berger