러셀 식 이론과 형식 시스템의 관계


12

나는 최근 Haskell에서 볼 수 있듯이 Russellian 유형 이론과 유형 시스템 사이에 어떤 종류의 관계가 있음을 깨달았습니다. 실제로 Haskell의 유형 표기법 중 일부는 유형 이론에 선구자가있는 것 같습니다. 그러나 1908 년의 IMHO, Russell의 동기는 Russell의 역설을 피하는 것이었고, 그것이 컴퓨터 과학의 유형 시스템과 어떻게 관련되는지는 확실하지 않습니다.

러셀의 역설은 어떤 형태로되어 있습니까? 예를 들어, 우리가 주어진 언어로 좋은 유형 체계를 가지고 있지 않은 경우 우리가 걱정해야 할 것이 있습니까?

답변:


8

프로그래밍 언어와 러셀의 의미에서``유형 이론 ''은 밀접한 관련이 있습니다. 실제로, 종속 유형 이론의 현대 분야는 수학에 건설적인 기초를 제공하는 것을 목표로합니다. 설정 이론과 달리 유형 이론에 대한 대부분의 연구 Coq, NuPRL 또는 Agda와 같은 교정 보조원에서 수학을 수행하므로 이러한 시스템에서 수행 된 교정은 "형식화 가능"할뿐만 아니라 실제로 정식 및 기계 점검을 거칩니다. 시스템은 "높은 수준"으로 비공식적 인 수학과 비슷하지만 모든 것이 확인되기 때문에 정확성을 훨씬 더 잘 보장 할 수 있습니다.

여기를 참조 하십시오

일반적인 프로그래밍 언어의 유형은 더 제한적인 경향이 있지만 메타 이론은 동일합니다.

Russell의 역설과 유사한 것이 종속 유형 이론의 주요 문제입니다. 특히

Type : Type

일반적으로 모순을 초래합니다. 유니버스를 중첩 시켜서 Coq 및 유사한 작업

Type_0 : Type_1

그러나 Coq에서는 기본적으로이 숫자는 프로그래머에게 중요하지 않으므로 암시 적입니다.

일부 시스템 (Agda, Idris)에서 유형 규칙의 유형은 컴파일 플래그를 통해 활성화됩니다. 논리가 일관성이 없지만 탐색 프로그래밍 / 증명이 더 쉬워집니다.

더 많은 주류 언어에서도 러셀의 역설이 때때로 나타납니다. 예를 들어, Haskell에서는 Impredicativity와 Open Type Case를 결합한 Russell의 역설 인코딩이 가능 하여 유형 수준에서도 재귀없이 분기 용어를 만들 수 있습니다. Haskell은 예외를 언급하지 않고 유형 및 값 수준의 재귀를 모두 지원하기 때문에``일관되지 않음 ''(일반적인 방식으로 논리로 해석 할 때)입니다.


자세한 답변을 보내 주셔서 감사합니다. 증거가있는 한 C ++ 또는 Java와 같은 명령형 언어로 프로그램의 정확성을 입증 할 수있는 도구는 아직 없습니다. 나는 이것들 중 하나에 손을 대고 싶습니다 ... 나는 이것이 완전한 접선이라는 것을 알고 있습니다. 나는 Coq와 Agda에 대해 알고 있지만 C ++ 또는 Java로 작성된 프로그램의 정확성을 입증하는 올바른 도구는 아닌 것 같습니다.
Frank

3
몇 가지 도구가 있습니다. C의 경우 몇 개, Java의 경우 몇 개, Ada의 경우 몇 톤입니다. 예를 들어 : 왜 (Java, C, Ada), Krakatoa (Java) 또는 SPARK (Ada 하위 집합이 매우 우수한 도구)를 참조하십시오. C ++의 경우 그렇게 많지 않습니다. YNot (Coq DSL)에 관심이있을 수도 있습니다.
Philip JF

3

당신은 러셀의 동기에 대해 맞습니다. 그의 역설은 제한없는 이해 공리를 인정하는 모든 세트 이론에 대해 다음과 같은 효과를 내고있다. 모든 제안 함수가 세트, 즉 함수를 만족시키는 모든 개체의 세트를 결정한다. 그 결점을 가지고 있었던 세트들에 대한 이론들에 근거하거나 근거한 것은 Cantor의 순진한 이론과 Frege의 Grundgesetze 시스템 (특히 공리 5)이었다.

타입은 특별한 종류의 세트로 간주되기 때문에주의를 기울이지 않으면 비슷한 역설이 타입 시스템으로 들어올 수 있습니다. 나는 30 년대에 람다 미적분학을 공식화하려는 교회의 초기 시도 만 기억할 수 있는데, 이는 클레 다-로저 역설 (Lleeser-Rosser Paradox)과 일치하지 않았지만, 그 유형은 러셀의 역설과 관련이 없었거나 그와 관련이 없었습니다.

업데이트 : 질문에 대한 실제 답변은 Philip의 답변을 참조하십시오.


1
답변 주셔서 감사합니다. Russell 역설을 피하기 위해 type-a-la-Russell에 대한 대안이있을 수 있습니다. 이러한 대안 솔루션 중 컴퓨터 언어에 기여할만한 흥미로운 것이 있습니까? Mundane 유형은 코드의 부분 사이에 계약을 명확하게 지정하고 그 이전에도 프로그램에 의미를 부여하는 데 매우 유용합니다. 유형 이외의 다른 것으로 얻을 수있는 다른 의미가 있습니까? (나는 그것이 무엇인지 전혀 모른다 :-)
Frank

1
예, 많은 대안 (Quine 's NF, ZFC 등)이 있지만 기초 위기와 프로그래밍 언어 사이에 직접적인 연관성이 없습니다. Martin Lof의 유형 이론을 프로그래밍 언어로 생각하면 직관과 다시 연결될 수 있습니다. 프로그래밍 언어의 의미와 관련하여 Kripke (또는 가능한 세계) 의미를 갖는 PDL (Propositional Dynamic Logic)과 같은 몇 가지 기본 언어가 있습니다. 그러나 유형은 나에게 매우 근본적인 것처럼 보이며 그들은 무대 뒤에서있을 수 있습니다 :)
Hunan Rostomyan

1
그러나 유형은 일종의 혼란입니다. 원하는 유형과 필요하지만 유형을 지정하지 않아도됩니다 (따라서 IMHO, 왜 Haskell 또는 Ocaml과 같은 언어로 유형 유추 시스템을 사용하는지 (나는 그 언어를 좋아합니다)). 스펙트럼의 다른 쪽 끝에서, 파이썬은 매우 직관적으로 느껴지고 해당 언어의 유형에 대해 너무 걱정할 필요가없는 것이 즐겁습니다 (코딩 시간 측면에서 효율적). 아마도 형식 유추가 두 세계에서 가장 좋을 수도 있지만 엔지니어가 말하는 것입니다. 저는 수학이 컴퓨터 과학에 또 다른 중요한 개념 (유형)을 기여할 수 있다는 공상을하고있었습니다 :-)
Frank

1
@Frank 모든 시간은 내가 정적 유형 (주로 루비)가없는 언어를 사용 싫어 내가 때문에, 경험을 싫어 피할 수 런타임 오류를. 그래서 그것은 대부분 맛의 문제인 것 같습니다. 나는 강력한 타입 추론이 당신에게 두 세계의 최고를 줄 수 있다는 데 동의합니다. 아마 스칼라를 좋아하는 이유는 무엇입니까?
Raphael

"자동으로"유형이 없으면 런타임 오류가 발생한다고 확신하지 않습니다. :-) 파이썬에서 문제가 없었습니다.
Frank

3

파이썬을 언급했기 때문에 문제는 순전히 형식 이론이 아닙니다. 그래서 나는 유형에 대해 더 넓은 관점을 제시하려고 노력합니다. 유형은 사람들마다 다릅니다. 나는 적어도 5 가지 (그러나 관련성이있는) 유형의 개념을 수집했습니다.

  1. 유형 시스템은 논리 시스템이며 설정 이론입니다.

  2. 유형 시스템은 유형을 각 계산 된 값과 연관시킵니다. 유형 시스템은 이러한 값의 흐름을 검사하여 유형 오류가 발생하지 않음을 증명하거나 확인하려고합니다.

  3. 유형은 실제 유형, 정수 또는 부울과 같은 다양한 유형의 데이터 중 하나를 식별하는 분류로 해당 유형에 가능한 값을 결정합니다. 해당 유형의 값에 대해 수행 할 수있는 작업 데이터의 의미; 해당 유형의 값을 저장하는 방법

  4. 추상 데이터 형식을 사용하면 고급 언어로 데이터를 추상화 할 수 있습니다. ADT는 종종 모듈로 구현됩니다. 모듈의 인터페이스는 ADT 작업에 해당하는 절차를 선언합니다. 이 정보 숨김 전략을 통해 클라이언트 프로그램을 방해하지 않고 모듈의 구현을 변경할 수 있습니다.

  5. 프로그래밍 언어 구현은 값 유형을 사용하여 값이 필요한 스토리지와 값 조작을위한 알고리즘을 선택합니다.

인용문은 Wikipedia에서 가져온 것이지만, 필요할 경우 더 나은 참조를 제공 할 수 있습니다.

타입 -1은 러셀의 연구에서 생겨 났지만 오늘날은 역설을 막을뿐 아니라 형식화 된 호모 토피 타입 이론은 수학을 형식적이고 기계가 이해할 수있는 언어로 인코딩하는 새로운 방법이며 인간이 기초를 이해하는 새로운 방법이다 수학 "이전 방식은 공리 집합 이론을 사용하여 인코딩하는 것입니다."

타입 2-5는 버그를 피하고, 데이터 소프트웨어 설계자와 프로그래머가 함께 작업하고, 큰 시스템을 설계하고, 프로그래밍 언어를 각각 효율적으로 구현하기 위해 여러 가지 요구에서 프로그래밍을 시작했습니다.

C / C ++, Ada, Java, Python의 유형 시스템은 Russel의 작업이나 버그를 피하려는 열망에서 발생하지 않았습니다. 그들은 다양한 종류의 데이터 (예 : "성은 숫자가 아닌 문자열")를 설명하고, 소프트웨어 설계를 모듈화하고, 데이터에 대한 저수준 표현을 최적으로 선택해야하는 필요성에서 생겨났습니다. 이 언어에는 유형 -1 또는 유형 -2가 없습니다. Java는 유형 시스템을 사용하여 프로그램 정확성을 검증하는 것이 아니라 언어 (포인터 산술 없음) 및 런타임 시스템 (가상 머신, 바이트 코드 검증)을 신중하게 설계하여 버그로부터 상대적 안전을 보장합니다. Java의 유형 시스템은 논리 시스템이나 집합 이론이 아닙니다.

그러나 Agda 프로그래밍 언어의 유형 시스템은 Russel 유형 시스템의 최신 변형입니다 (나중에 작업하거나 Per Martin-Lof 및 기타 수학자 기반). Agda의 유형 시스템은 프로그램의 수학적 속성과 해당 속성의 증거를 표현하도록 설계되었으며 논리적 시스템과 이론입니다.

여기에는 흑백 구분이 없습니다. 많은 언어가 그 사이에 맞습니다. 예를 들어, Haskell 언어의 유형 시스템은 Russel의 연구에 뿌리를두고 있으며 간결한 Agda 시스템으로 볼 수 있지만, 수학적 관점에서는 논리적 시스템이나 이론으로 볼 때 일관성이 없습니다 (자기 모순).

그러나 Haskell 프로그램을 버그로부터 보호하기위한 이론적 수단으로 작동합니다. 유형을 사용하여 특정 속성 및 증명을 인코딩 할 수도 있지만 모든 속성을 인코딩 할 수있는 것은 아니며 프로그래머가 낙심 한 더러운 핵을 사용하는 경우에도 입증 된 속성을 위반할 수 있습니다.

Scala의 타입 시스템은 Russel의 작업과 Agda의 완벽한 교정 언어에서 멀어졌지만 여전히 Russel의 작업에 뿌리를두고 있습니다.

유형 시스템이 설계되지 않은 산업 언어의 속성을 입증하는 데는 많은 접근 방식과 시스템이 있습니다.

흥미롭지 만 다른 접근법은 Coq 및 Microsoft Boogie 리서치 프로젝트를 참조하십시오. Coq는 Coq 프로그램에서 명령형 프로그램을 생성하기 위해 유형 이론에 의존합니다. Boogie는 속성이있는 명령형 프로그램의 주석에 의존하며 Coq와 완전히 다른 접근 방식을 사용하여 Z3 정리를 통해 해당 속성을 증명합니다.

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.