유형계

이 문서에는 여러 가지 문제가 있습니다.개선을 돕거나 토크 페이지에서 이러한 문제에 대해 논의해 주십시오.(이러한 템플릿메시지를 삭제하는 방법과 타이밍에 대해 설명합니다) 이 문서에는 일반적인 참조 목록이 포함되어 있지만 대응하는 충분한 인라인 인용이 없습니다. 좀 더 정확한 인용문을 도입하여 이 기사의 개선에 도움을 주십시오. (2010년 10월) (이 템플릿메시지의 삭제 방법과 삭제 시기에 대해 알아보세요) 이 글은 위키피디아 편집자의 개인적인 감정을 기술하거나 주제에 대한 독창적인 주장을 제시하는 개인적인 성찰, 개인적인 에세이 또는 논쟁적인 에세이처럼 쓰여집니다. 백과사전 형식으로 고쳐서 개선해 주세요.(2016년 7월) (이 템플릿메시지 삭제 방법 및 삭제 시기 확인) (이 템플릿메시지를 삭제하는 방법과 타이밍을 확인합니다)

컴퓨터 과학 프로그래밍 언어에서, 유형 시스템은 유형이라고 불리는 속성을 모든 용어(단어, 구 또는 기타 기호 집합)에 할당하는 일련의 규칙으로 구성된 논리 시스템입니다.일반적으로 용어는 변수, 식, 함수 또는 ^[1]모듈과 같은 컴퓨터 프로그램의 다양한 구성입니다.유형 시스템은 한 기간에 수행할 수 있는 작업을 지시합니다.변수의 경우 유형 시스템은 해당 항의 허용되는 값을 결정합니다.형식 시스템은 프로그래머가 대수적 데이터 유형, 데이터 구조 또는 기타 구성 요소(예: "string", "float", "float" 반환 부울)에 사용하는 암묵적인 범주를 공식화하고 적용합니다.

타입 시스템은 종종 프로그래밍 언어의 일부로 지정되며 인터프리터와 컴파일러에 내장되지만 언어의 원래 타입 구문과 문법을 사용하여 추가 검사를 수행하는 옵션 도구에 의해 확장될 수 있습니다.프로그래밍 언어의 유형 시스템의 주요 목적은 유형 ^[2]오류로 인한 컴퓨터 프로그램의 버그 가능성을 줄이는 것입니다.해당 유형 시스템에 따라 무엇이 유형 오류를 구성하는지가 결정되지만, 일반적으로는 특정 종류의 값을 예상하는 작업이 해당 작업이 의미가 없는 값(유효성 오류)과 함께 사용되지 않도록 하는 것이 목적입니다.타입 시스템을 사용하면 컴퓨터 프로그램의 다른 부품 간의 인터페이스를 정의하고 부품이 일관된 방식으로 연결되었는지 확인할 수 있습니다.이 체크는 정적(컴파일 시), 동적(실행 시) 또는 두 가지 조합으로 수행할 수 있습니다.유형 시스템에는 비즈니스 규칙 표현, 특정 컴파일러 최적화 활성화, 다중 디스패치 허용, 문서 형식 제공 등 다른 목적도 있습니다.

사용방법 개요

단순한 타입 시스템의 예로는 C언어를 들 수 있다.C 프로그램의 일부는 함수 정의입니다.한 함수는 다른 함수에 의해 호출됩니다.함수의 인터페이스는 함수의 이름과 함수의 코드로 전달되는 파라미터 목록을 나타냅니다.호출 함수의 코드에는 호출된 함수의 이름과 전달될 값을 유지하는 변수의 이름이 표시됩니다.실행 중에 값이 임시 스토리지에 배치되고 실행이 호출된 함수의 코드로 이동합니다.호출된 함수의 코드가 값에 액세스하여 값을 사용합니다.함수내의 명령이 정수치를 수신하는 것을 전제로 쓰여져 있습니다만, 발신측 코드가 부동 소수점치를 넘었을 경우, 호출된 함수에 의해서 잘못된 결과가 계산됩니다.C 컴파일러는 함수의 정의에 선언된 파라미터의 유형에 대해 함수가 호출될 때 함수에 전달되는 인수의 유형을 확인합니다.유형이 일치하지 않으면 컴파일러는 컴파일 시간 오류를 발생시킵니다.

컴파일러는 정적 유형의 값을 사용하여 필요한 스토리지를 최적화하고 해당 값에 대한 연산을 위한 알고리즘을 선택할 수도 있습니다.예를 들어 많은 C 컴파일러에서 플로트 데이터형은 단정도 부동소수점 번호의 IEEE 사양에 따라 32비트로 표시됩니다.따라서 이들 값(부동소수점 가산, 곱셈 등)에 대해 부동소수점 고유의 마이크로프로세서를 사용합니다.

유형 제약의 깊이와 그 평가 방식은 언어 입력에 영향을 미칩니다.프로그래밍 언어는 타입 다형성의 경우, 각 타입에 대해 다양한 해상도와 연산을 더욱 관련지을 수 있다.유형 이론은 유형 시스템을 연구하는 학문이다.정수나 문자열과 같은 일부 프로그래밍 언어의 구체적인 유형은 컴퓨터 아키텍처, 컴파일러 구현 및 언어 설계의 실제 문제에 따라 달라집니다.

기초

형식적으로는 이론 연구 유형 시스템을 입력합니다.프로그래밍 언어에는 컴파일 시 또는 런타임에 수동으로 주석을 달거나 자동으로 추론하는 형식 시스템을 사용하여 유형 검사를 수행할 수 있는 기회가 있어야 합니다.Mark Manasse가 ^[3]간결하게 말했듯이:

유형 이론이 다루는 근본적인 문제는 프로그램이 의미를 갖는다는 것입니다.유형 이론에 의해 야기되는 근본적인 문제는 의미 있는 프로그램들이 그들에게 주어진 의미를 가지지 않을 수 있다는 것이다.보다 풍부한 타입의 시스템을 추구하는 것은, 이러한 긴장감으로부터 비롯됩니다.

타이핑이라고 불리는 데이터 유형을 할당하면 메모리 내의 값이나 변수와 같은 일부 개체와 같은 일련의 비트에 의미를 부여합니다.범용 컴퓨터의 하드웨어는 예를 들어 메모리 주소와 명령 코드 또는 문자, 정수 또는 부동소수점 숫자를 구별할 수 없습니다.이는 일련의 비트가 ^{[note 1]}의미할 수 있는 어떤 값도 본질적으로 구별하지 않기 때문입니다.일련의 비트를 유형에 관련짓는 것은 그 의미를 프로그램 가능한 하드웨어에 전달하고 그 하드웨어와 어떤 프로그램으로 구성된 심볼 시스템을 형성한다.

프로그램은 각 값을 하나 이상의 특정 유형과 관련짓지만 하나의 값이 여러 하위 유형과 관련지어지는 경우도 있습니다.오브젝트, 모듈, 통신채널, 의존관계 등의 다른 엔티티가 유형과 관련지어질 수 있습니다.타입도 타입과 관련지을 수 있습니다.유형 시스템의 구현은 이론적으로 데이터 유형(값의 일종), 클래스(객체의 일종) 및 종류(유형의 일종 또는 메타 유형)라고 불리는 식별을 연관시킬 수 있다.시스템에 포함된 레벨의 계층에서 타이핑이 수행할 수 있는 추상화입니다.

프로그래밍 언어가 보다 정교한 유형 시스템을 발전시키면 기본 유형 검사보다 더 세밀한 규칙 집합을 얻을 수 있지만, 이는 유형 추론(및 다른 속성)을 결정할 수 없게 되고 프로그래머가 코드에 주석을 달거나 컴퓨터 관련 조작과 함수를 고려하기 위해 더 많은 주의를 기울여야 할 때 발생한다.ioning. 모든 프로그래밍 관행을 만족시키는 충분히 표현력 있는 타입 시스템을 찾는 것은 어렵다.

프로그래밍 언어 컴파일러는 의존형 또는 효과 시스템을 구현할 수도 있으며, 이를 통해 훨씬 더 많은 프로그램 사양을 유형 검사기에 의해 검증할 수 있다.단순한 값 유형의 쌍을 넘어 코드의 가상 "지역"은 무엇을 사용하여 무엇을 수행하는지 설명하고 오류 보고서를 "투척"할 수 있도록 하는 "효과" 구성 요소와 관련지어집니다.따라서 심볼 시스템은 유형 및 효과 시스템일 수 있으며, 이를 통해 유형 검사만 수행하는 것보다 더 많은 안전 검사를 수행할 수 있습니다.

컴파일러에 의해 자동화되거나 프로그래머에 의해 지정되거나 타입 시스템은 타입 시스템 규칙 밖에 있는 경우 프로그램 동작을 불법으로 합니다.프로그래머 지정 유형 시스템에 의해 제공되는 이점은 다음과 같습니다.

• 추상화(또는 모듈화)– 타입은 프로그래머가 낮은 수준의 구현에 신경 쓰지 않고 비트나 바이트보다 높은 수준에서 생각할 수 있도록 합니다.예를 들어 프로그래머는 문자열을 단순히 바이트 배열이 아닌 문자 값의 집합으로 생각하기 시작할 수 있습니다.게다가 타입은 프로그래머가 임의의 크기의 서브시스템 2개 사이의 인터페이스에 대해 생각하고 표현할 수 있도록 합니다.이것에 의해, 보다 높은 레벨의 현지화가 가능하게 되어, 이러한 2개의 서브 시스템이 통신할 때에 서브 시스템의 상호 운용성에 필요한 정의가 일관되게 유지됩니다.
• 문서 – 보다 표현력이 풍부한 유형 시스템에서는 유형은 프로그래머의 의도를 명확히 하는 문서 형태로 기능할 수 있습니다.예를 들어, 프로그래머가 함수를 타임스탬프 타입을 반환하는 것으로 선언했을 경우, 이는 타임스탬프 타입이 정수 타입으로 코드 내에서 명시적으로 선언될 수 있는 경우에 함수를 문서화합니다.

컴파일러 전용 타입의 시스템에는 다음과 같은 이점이 있습니다.

• 최적화 – 정적 유형 검사는 유용한 컴파일 시간 정보를 제공할 수 있습니다.예를 들어, 어떤 타입에서 값이 4바이트의 배수로 메모리에 정렬되어야 하는 경우 컴파일러는 보다 효율적인 기계 명령을 사용할 수 있습니다.
• 안전성 – 타입 시스템은 컴파일러가 의미 없거나 유효하지 않은 코드를 검출할 수 있도록 합니다.예를 들어, 다음과 같은 식을 식별할 수 있습니다.3 / "Hello, World"규칙에 정수를 문자열로 나누는 방법이 지정되어 있지 않은 경우 비활성화됩니다.타이핑이 강하면 안전성은 높아지지만 완전한 타입의 안전성은 보장되지 않습니다.

입력 오류

유형 오류는 프로그램 개발의 여러 단계에서 나타날 수 있는 의도하지^[a] 않은 상태입니다.따라서 타입 시스템에서는 에러를 검출하는 설비가 필요합니다.Haskell 등 타입 추론이 자동화된 언어에서는 오류 검출에 도움이 되도록 컴파일러가 보풀을 사용할 수 있습니다.

유형 안전은 프로그램 정확성에 기여하지만 유형 검사 자체를 결정할 수 없는 ^{[citation needed]}문제로 만드는 대신 정확성을 보장할 수 있습니다.자동 타입 체크가 있는 타입 시스템에서는, 프로그램이 올바르게 동작하지 않는 것이 판명되는 일이 있습니다만, 컴파일러 에러는 발생하지 않습니다.0으로 나눗셈하는 것은 안전하지 않고 잘못된 작업이지만 컴파일 시에만 실행되는 유형 검사기는 대부분의 언어에서 0으로 나눗셈을 검사하지 않습니다. 이 분할은 런타임 오류로 나타납니다.이러한 결함이 없음을 증명하기 위해 프로그램 분석으로 알려진 다른 종류의 공식 방법이 일반적으로 사용됩니다.또는 의존적으로 입력된 언어에서와 같이 충분히 표현적인 유형 시스템을 통해 이러한 종류의 오류(예를 들어 0이 아닌 숫자의 유형 표현)를 방지할 수 있습니다.또한 소프트웨어 테스트는 그러한 유형 검사기에서는 탐지할 수 없는 오류를 찾기 위한 경험적 방법입니다.

유형 확인

타입의 제약을 검증 및 적용하는 프로세스(타입 체크)는 컴파일 시(스태틱체크) 또는 런타임에 발생할 수 있습니다.언어 사양에 타이핑 규칙이 강하게 필요한 경우(즉, 정보가 손실되지 않는 자동 타입 변환만 허용하는 경우), 프로세스를 강하게 타이핑하거나 약하게 타이핑한 것으로 볼 수 있습니다.그 용어들은 보통 엄격한 의미로 사용되지 않는다.

정적 유형 확인

정적 형식 확인은 프로그램의 텍스트(소스 코드) 분석을 기반으로 프로그램의 형식 안전성을 확인하는 과정입니다.프로그램이 정적 유형 검사기를 통과하면 프로그램은 가능한 모든 입력에 대해 몇 가지 유형의 안전 속성을 충족할 수 있습니다.

정적 유형 확인은 제한된 프로그램 검증 형식(형식 안전성 참조)으로 간주될 수 있으며, 유형 안전 언어로도 최적화를 고려할 수 있다.컴파일러가 프로그램이 잘 입력되었음을 증명할 수 있다면 동적 안전 검사를 수행할 필요가 없으며 결과적으로 컴파일된 바이너리를 더 빠르게 실행하고 더 작게 만들 수 있습니다.

튜링 완전 언어의 정적 유형 검사는 본질적으로 보수적입니다.즉, 타입 시스템이 사운드(모든 잘못된 프로그램을 거부함을 의미)와 디시블(프로그램이 올바르게 입력되었는지 여부를 판단하는 알고리즘을 작성할 수 있음을 의미)인 경우, 그 시스템은 불완전해야 합니다(실행시 ^[4]오류가 발생하지 않더라도 올바른 프로그램이 있음을 의미).예를 들어, 다음 코드가 포함된 프로그램을 생각해 보겠습니다.

if <complex test> then <do something> else <signal that there is a type error>

비록 그 표현이<complex test>항상 평가하다true런타임에 대부분의 타입 체커는 프로그램을 부정하게 리젝트합니다.이는 정적 분석기에서는 (불가능하지 않은 경우) 다음 사항을 판단하기 어렵기 때문입니다.else브랜치는 ^[5]취득되지 않습니다.따라서 정적 유형 검사기는 거의 사용되지 않는 코드 경로에서 유형 오류를 빠르게 탐지합니다.스태틱 타입 체크가 없으면 커버리지가 100%인 코드커버리지 테스트에서도 이러한 타입 오류를 검출하지 못할 수 있습니다.값이 생성되는 모든 장소와 특정 값이 사용되는 모든 장소의 조합을 고려해야 하기 때문에 테스트에서는 이러한 유형의 오류를 검출하지 못할 수 있습니다.

다운캐스팅과 같이 유용하고 일반적인 프로그래밍 언어 기능은 정적으로 확인할 수 없습니다.따라서 많은 언어에는 스태틱타입 체크와 다이내믹타입 체크가 모두 있습니다.스태틱타입 체커는 그 기능을 검증하고 다이내믹체크는 나머지를 검증합니다.

정적 유형 검사를 사용하는 많은 언어에서는 유형 검사를 우회하는 방법을 제공합니다.일부 언어에서는 프로그래머가 정적과 동적 유형 안전성 중 하나를 선택할 수 있습니다.예를 들어 C#은 정적 유형 변수와 동적 유형 변수를 구분합니다.전자의 사용은 정적으로 체크되며 후자의 사용은 동적으로 체크됩니다.다른 언어에서는 타입 세이프가 아닌 코드를 쓸 수 있습니다.예를 들어 C에서는 프로그래머가 같은 사이즈의 임의의 두 타입 사이에 값을 자유롭게 캐스트 할 수 있기 때문에 타입의 개념을 효과적으로 뒤집을 수 있습니다.

정적 유형 검사를 사용하는 언어 목록은 정적 유형 언어 범주를 참조하십시오.

동적 유형 확인 및 런타임 유형 정보

동적 유형 검사는 런타임에 프로그램의 유형 안전성을 확인하는 프로세스입니다.동적 유형 검사 언어 구현은 일반적으로 각 런타임 개체를 유형 정보를 포함하는 유형 태그(즉, 유형에 대한 참조)와 관련짓습니다.이 런타임 유형 정보(RTTI)는 동적 디스패치, 레이트바인딩, 다운캐스트, 리플렉션 및 유사한 기능을 구현하기 위해서도 사용할 수 있습니다.

대부분의 타입 세이프 언어에는 스태틱타입 ^{[citation needed]}체커가 있는 경우에도 다이내믹타입 체크가 포함되어 있습니다.^[6] 그 이유는 많은 유용한 기능 또는 속성이 정적으로 검증하기 어렵거나 불가능하기 때문입니다.예를 들어 프로그램이 A와 B의 두 가지 유형을 정의한다고 가정합니다. 여기서 B는 A의 하위 유형입니다.프로그램이 타입 A의 값을 타입 B(다운캐스트)로 변환하려고 하면 변환되는 값이 실제로 타입 B의 값일 경우에만 조작이 유효합니다.따라서 동작이 안전한지 확인하기 위해 동적 점검이 필요합니다.이 요건은 다운캐스팅에 대한 비판 중 하나입니다.

정의상 동적 유형 검사는 실행 시 프로그램을 실패시킬 수 있습니다.일부 프로그래밍 언어에서는 이러한 장애를 예측하고 복구할 수 있습니다.다른 경우 유형 검사 오류는 치명적이라고 간주됩니다.

동적 유형 체크를 포함하지만 정적 유형 체크를 포함하지 않는 프로그래밍 언어를 종종 "동적 유형 프로그래밍 언어"라고 합니다.이러한 언어 목록은 동적 유형의 프로그래밍 언어 범주를 참조하십시오.

정적 및 동적 유형 검사 결합

일부 언어에서는 정적 타이핑과 동적 타이핑을 모두 사용할 수 있습니다.예를 들어 Java 및 기타 정적인 유형의 언어는 서브타입으로 다운캐스트유형을 지원하며 오브젝트를 쿼리하여 다이내믹유형 및 런타임유형 정보에 의존하는 기타 유형의 조작을 검출합니다.다른 예로는 C++ RTI가 있습니다.보다 일반적으로, 대부분의 프로그래밍 언어는 분리된 결합, 런타임 다형성 및 변형 유형과 같은 다양한 종류의 데이터를 디스패치하기 위한 메커니즘을 포함합니다.유형 주석이나 유형 확인과 상호 작용하지 않는 경우에도 이러한 메커니즘은 동적 타이핑 구현과 실질적으로 유사합니다.정적 입력과 동적 입력 간의 상호 작용에 대한 자세한 내용은 프로그래밍 언어를 참조하십시오.

오브젝트 지향 언어의 오브젝트는 보통 오브젝트의 런타임타입(잠재형) 또는 슈퍼타입과 동일한 스태틱타깃타입(또는 매니페스트타입)을 가진 참조에 의해 액세스 됩니다.이는 특정 유형의 인스턴스에서 실행되는 모든 작업을 하위 유형의 인스턴스에서도 수행할 수 있다는 Liskov 대체 원칙에 준거합니다.이 개념은 추정 또는 아형 다형성이라고도 합니다.일부 언어에서는 하위 유형이 공변 또는 반변 반환 유형과 인수 유형을 각각 가질 수도 있습니다.

Clojure, Common Lisp 또는 Cython과 같은 특정 언어는 기본적으로 동적으로 유형이 확인되지만, 옵션 주석을 제공하여 프로그램이 정적 유형 확인을 선택할 수 있습니다.이러한 힌트를 사용하는 한 가지 이유는 프로그램의 중요한 부분의 성능을 최적화하기 위함입니다.이것은 점진적인 타이핑으로 공식화된다.프로그래밍 환경인 DrRacket, Lisp에 기반한 교육 환경 및 Raket 언어의 선구자이기도 합니다.^[7]

반대로 버전 4.0에서는 C# 언어를 사용하여 변수를 스태틱타입 체크하지 않는 것을 나타냅니다.유형이 다음과 같은 변수dynamic는 정적 유형 체크의 대상이 되지 않습니다.대신, 프로그램은 런타임 유형 정보에 의존하여 변수가 어떻게 ^[8]사용될 수 있는지를 결정합니다.

[ Rust ]에서dyn std::any::Anytype은 의 동적 입력을 제공합니다.'static타입을 지정합니다.^[9]

정적 및 동적 유형 체크 인 실전

정적 타이핑과 동적 타이핑 중 하나를 선택하려면 일정한 트레이드오프가 필요합니다.

정적 입력은 컴파일 시 안정적으로 유형 오류를 찾을 수 있으므로 제공된 프로그램의 신뢰성이 높아집니다.그러나 프로그래머들은 유형 오류가 얼마나 자주 발생하는지에 대해 의견이 일치하지 않으며, 결과적으로 코드화된 버그의 비율에 대한 의견 불일치를 초래하고,^[10][11] 코드화된 유형을 적절히 표현함으로써 포착될 수 있습니다.정적 타이핑^[who?] 옹호자들은 프로그램이 제대로 타이핑 검사를 받아야 더 신뢰할 수 있다고 믿는 반면, 동적 타이핑^[who?] 옹호자들은 신뢰할 수 있는 것으로 입증된 분산 코드와 작은 버그 ^{[citation needed]}데이터베이스를 가리킵니다.정적 타이핑 값은 유형 시스템의 강도가 증가할수록 증가합니다.Dependent ML이나 Epigram과 같은 언어로 구현된 의존형 ^[who?]타입의 옹호자들은 프로그램에서 사용되는 타입이 프로그래머에 의해 적절히 선언되거나 ^[12]컴파일러에 의해 올바르게 추론된다면 거의 모든 버그가 타입 오류로 간주될 수 있다고 제안했습니다.

일반적으로 정적 입력으로 인해 컴파일된 코드가 더 빠르게 실행됩니다.컴파일러가 사용되고 있는 정확한 데이터 타입을 알고 있을 때(선언 또는 추론을 통해 정적 검증에 필요함) 최적화된 머신 코드를 생성할 수 있습니다.Common Lisp 등 일부 동적 유형 언어에서는 이러한 이유로 최적화를 위한 선택적 유형 선언이 허용됩니다.

반면 동적 타이핑을 사용하면 컴파일러의 실행 속도가 빨라지고 인터프리터가 새로운 코드를 동적으로 로드할 수 있습니다.이는 동적으로 타이핑된 언어로 소스 코드를 변경하면 실행하는 검사와 ^{[clarification needed]}재방문하는 코드가 줄어들 수 있기 때문입니다.이것에 의해서, 편집-컴파일-테스트-디버깅 사이클이 단축될 가능성이 있습니다.

(버전 10보다 이전 버전의 C나 Java 등)유형 추론이 부족한 정적 타입의 언어에서는 프로그래머가 메서드 또는 함수가 사용해야 하는 유형을 선언해야 합니다.이는 스태틱 대신 액티브하고 역동적인 프로그램 문서로서 기능할 수 있습니다.이를 통해 컴파일러는 동기화가 되지 않고 프로그래머에 의해 무시되는 것을 방지할 수 있습니다.단, 타입 선언을 필요로 하지 않고 언어를 스태틱하게 입력할 수 있기 때문에(예를 들어 Haskell, Scala, OCaml, F#, 그보다 작은 범위 C# 및 C++ 등), 명시적인 타입 선언이 모든 언어의 스태틱 입력에 필요한 것은 아닙니다.

동적 입력을 사용하면 일부(단순한) 정적 유형 검사가 잘못된 것으로 거부되는 구성을 사용할 수 있습니다.예를 들어 임의의 데이터를 코드로 실행하는 eval 함수가 가능해진다.정적 타이핑으로 평가 함수를 사용할 수 있지만 대수 데이터 유형을 고급으로 사용해야 합니다.또한 동적 타이핑은 전체 데이터 구조(보통 실험 및 테스트 목적) 대신 자리 표시자 데이터 구조(mock 개체)를 투명하게 사용할 수 있도록 하는 것과 같은 과도 코드 및 프로토타이핑을 더 잘 수용합니다.

동적 입력은 일반적으로 덕 입력(코드 재사용이 용이함)을 허용합니다.정적^[specify] 타이핑을 사용하는 많은 언어에는 덕 타이핑이나 일반 프로그래밍과 같은 다른 메커니즘도 있어 코드를 쉽게 재사용할 수 있습니다.

일반적으로 동적 입력으로 메타프로그래밍을 보다 쉽게 사용할 수 있습니다.예를 들어, C++ 템플릿은 (함수와 변수 모두에 대해) 유형 정의와 관련하여 더 강력한 규칙을 가지고 있기 때문에 일반적으로 동등한 Ruby 또는 Python 코드보다 작성하기가 더 어렵습니다.이로 인해 개발자는 Python 개발자가 필요로 하는 것보다 더 많은 템플릿용 보일러 플레이트 코드를 작성해야 합니다.메타클래스 및 인스펙션과 같은 고급 런타임 구성 요소는 정적 유형의 언어에서 사용하기 어렵습니다.일부 언어에서는 이러한 기능을 사용하여 런타임 데이터를 기반으로 새로운 유형 및 동작을 즉시 생성할 수도 있습니다.이러한 고급 구조는 종종 동적 프로그래밍 언어에 의해 제공되며, 동적 타이핑이 동적 프로그래밍 언어와 관련될 필요는 없지만, 이들 중 다수는 동적 타이핑입니다.

강점과 약점 타입의 시스템

언어는 구어체로 강하게 타이핑되거나 약하게 타이핑되는 경우가 많습니다.사실, 이러한 용어의 의미에 대한 보편적 정의는 없습니다.일반적으로 유형 시스템 간의 차이를 나타내는 보다 정확한 용어가 있어 사람들은 이를 "강함" 또는 "약함"이라고 부른다.

타입 세이프티 및 메모리 세이프티

프로그래밍 언어의 유형 시스템을 분류하는 세 번째 방법은 유형화된 연산과 변환의 안전성에 의한 것입니다.컴퓨터 과학자는 타입 세이프 언어라는 용어를 사용하여 타입 시스템의 규칙을 위반하는 조작이나 변환을 허용하지 않는 언어를 기술합니다.

컴퓨터 사이언티스트들은 메모리 세이프 언어(또는 세이프 언어)라는 용어를 사용하여 프로그램이 사용하지 않는 메모리에 액세스할 수 없는 언어를 설명합니다.예를 들어, 메모리 세이프 언어는 어레이 경계를 체크하거나 어레이 경계를 벗어나는 액세스에 대해 (실행 전 컴파일 시) 정적 보증을 합니다.

타입 세이프 및 메모리 ^[13]세이프 양쪽의 언어에 대해서, 다음의 프로그램을 검토해 주세요.

var x := 5; var y := "37", var z := x + y;

이 예에서는 변수가z값은 42가 됩니다.비록 프로그래머가 예상한 것은 아닐지라도, 이것은 명확하게 정의된 결과입니다.한다면y숫자(예: "Hello World")로 변환할 수 없는 다른 문자열이면 결과도 명확하게 정의됩니다.프로그램은 타입 세이프 또는 메모리 세이프할 수 있지만, 무효인 조작으로 크래쉬 할 수 있습니다.이는 가능한 모든 피연산자에 대한 연산의 유효성을 정확하게 지정할 수 있을 만큼 유형 시스템이 충분히 발전하지 않은 언어를 위한 것입니다.그러나 프로그램이 타입 세이프가 아닌 조작을 발견했을 경우, 그 프로그램을 종료하는 것만이 유일한 옵션인 경우가 많습니다.

이제 C의 유사한 예를 살펴보겠습니다.

인트 x = 5; 차 y[] = "37"; 차* z = x + y; 인쇄물(%c\n", *z); 

이 예에서는z메모리 주소가 5글자 이상일 경우y에 의해 지시된 스트링의 끝0 문자 뒤에3 문자에 상당합니다.y이것은, 프로그램이 액세스 할 수 없는 메모리입니다.C 용어로 이것은 단순히 정의되지 않은 동작이며 프로그램은 무엇이든 할 수 있다; 단순한 컴파일러로 문자열 "37" 뒤에 저장된 바이트를 실제로 인쇄할 수 있다.이 예에서 알 수 있듯이 C는 메모리 세이프가 아닙니다.임의 데이터는 문자로 가정했기 때문에 활자 안전 언어도 아니다.

일반적으로 활자 안전과 기억 안전은 밀접하게 관련되어 있다.예를 들어 포인터 산술과 숫자 대 포인터 변환을 지원하는 언어(예: C)는 메모리 안전하지도 않고 타입 안전하지도 않습니다.이는 임의의 메모리가 모든 유형의 유효한 메모리인 것처럼 액세스할 수 있기 때문입니다.

자세한 내용은 메모리 안전을 참조하십시오.

유형 확인의 가변 수준

언어에 따라 코드의 다른 영역에 다른 수준의 검사를 적용할 수 있습니다.예를 들어 다음과 같습니다.

• 그use strictJavaScript 및 Perl의^[14][15][16] 디렉티브는 보다 강력한 체크를 적용합니다.
• 그declare(strict_types=1)파일 단위로 PHP에서는 형식^[17] 선언의 정확한 유형의 변수만 허용하거나, 또는TypeError던져질 것이다.
• 그Option Strict On컴파일러는 오브젝트 간의 변환을 요구할 수 있습니다.

보풀 및 IBM Rational Purify와 같은 추가 도구를 사용하여 보다 높은 수준의 엄격함을 달성할 수 있습니다.

옵션 타입 시스템

주로 Gilad Bracha에 의해 언어 선택과 무관하게 활자 시스템의 선택이 제안되어 왔다. 활자 시스템은 필요에 따라 언어에 연결할 수 있는 모듈이어야 한다.그는 이것이 유리하다고 생각한다. 왜냐하면 그가 의무적 유형 시스템이라고 부르는 것이 언어를 덜 표현하고 코드를 더 ^[18]취약하게 만들기 때문이다.형식 체계가 언어의 의미에 영향을 미치지 않는다는 요건은 충족시키기가 어렵다.

선택적 타이핑은 점진적 타이핑과 관련이 있지만 이와는 다릅니다.두 타이핑 규칙을 모두 사용하여 코드의 정적 분석(정적 타이핑)을 수행할 수 있지만, 옵션 타입 시스템은 실행 시(동적 타이핑)에 형식 안전을 강제하지 않습니다.^[18][19]

다형 및 유형

다형성이라는 용어는 여러 유형의 값에 작용하는 코드(특히 함수 또는 클래스)의 능력 또는 동일한 데이터 구조의 다른 인스턴스가 다른 유형의 요소를 포함하는 능력을 의미합니다.다형성을 허용하는 타입 시스템은 일반적으로 코드 재사용 가능성을 개선하기 위해 그렇게 합니다.다형성을 가진 언어에서는 프로그래머가 사용하는 요소 유형별로 한 번이 아니라 목록이나 연관 배열과 같은 데이터 구조를 한 번만 구현하면 됩니다.이러한 이유로 컴퓨터 과학자들은 때때로 특정 형태의 다형성을 범용 프로그래밍이라고 부른다.다형성의 유형 이론의 기초는 추상화, 모듈화 및 (어떤 경우에는) 서브타이핑의 기초와 밀접하게 관련되어 있다.

특수형 시스템

특정 유형의 데이터가 있는 특정 환경에서 사용하거나 대역 외 정적 프로그램 분석에 특화된 많은 유형의 시스템이 생성되었습니다.이는 종종 형식 유형 이론의 아이디어를 기반으로 하며 프로토타입 연구 시스템의 일부로만 사용할 수 있습니다.

다음 표는 특수 유형 시스템에서 사용되는 유형 이론 개념에 대한 개요를 보여 줍니다.이름 M, N, O는 용어에 걸쳐 ${\displaystyle \mathrm{있으며}}$ $이름{\displaystyle }$" ,$$" \$displaystyle$ \$sigma$, \ $tau }$는 유형에 걸쳐 있습니다.다음 표기가 사용됩니다.

• ${\displaystyle M}$: ${\$ { $displaystyle$ M$$: \ $sigma$ $}$는$M$의 $타입$이 "\$$$displaystyle$ \ $sigma$$임$을 의미합니다.
• $)$ {$displaystyle$ M$(N)}$은$$N({$displaystyle$N$\})$에 M$({displaystyle$M})을$$ $적용$한 것입니다.
• ${\displaystyle :}$ [ ${\displaystyle \alpha }$ :${\displaystyle }$=$σstyle ]{ display$ \ display [ \ alpha : = \ $display$]}$$ ( ${\displaystyle \mathrm{resp}}$ ) ${\displaystyle 。}$${\displaystyle [[x}$ : = N$$]{ $style$\ $display [ x$ : = N$$]}은 by의 모든 유형 변수 α(응답항 변수 x)를 유형 ((응답항 N)으로 치환한 결과 발생하는 유형을 나타낸다.

유형 개념	표기법	의미.
기능.	$\displaystyle \to\displays }$	M${\displaystyle }$: $τdisplay$ （ \ $displaystyle$ M : \ $sigma$\$to$\$tau }$ ${\displaystyle \mathrm{n<img\; alt="\{\backslash displaystyle\; M:\backslash sigma\; \backslash to\; \backslash tau\; \}"\; aria-hidden="true"\; class="mwe-math-fallback-image-inline"\; src="https://wikimedia.org/api/rest\_v1/media/math/render/svg/398b21c2b2a48db6b6d2a9e57cfe64d33d572357"\; style="vertical-align:\; -0.338ex;\; width:10.525ex;\; height:2.176ex;">}}$ n${\displaystyle }$n N$$: \ $displaystyle$ N : \ $sigma$인 $경우{\displaystyle }$${\displaystyle }M{\displaystyle }$ (${\displaystyle N}$) :$$\ $displaystyle$M ( N ) : \ $tau$ $\}$$$。
제품.	$\displaystyle \times \times \times }$	${\displaystyle M}$: ${\displaystyle \times }$ × ${\$ { $displaystyle$ M : \ $sigma$\$times$ \ times$\}$인 경우 $M{\displaystyle }$ ${\displaystyle =}$ (${\displaystyle N}$ ,${\displaystyle O}$) { $displaystyle$ M = ($N$ , $O$)는$$ 쌍 s.t 입니다.${\displaystyle }$$N{\displaystyle }$$:\displaystyle$ N$$$:\sigma$ 및$$O$:\displaystyle$ O$:\tau$
합	$\displaystyle +\displaystyle }$	$M{\displaystyle }$: ${\displaystyle +}$ +$τ$ { $displaystyle$ M : \ $sigma$+ \ $sigma$일 경우 $M{\displaystyle }$ ${\displaystyle =}$ ${\displaystyle {1\mathrm{}}_{}}$1 (${\displaystyle N}$) { $displaystyle$ M = \$iota$_ {$1}$ ( $N$)가$$ 첫 번째 주입 s.t 입니다.${\displaystyle N}$: $（$ \ $display style$ N : \ $sigma$ $）$ $mた{\displaystyle }$ ${\displaystyle =}$ =${\displaystyle {}_{}2}$ (${\displaystyle }$N $){$ $display style$ M = \$iota$_ {$2}$ ( N )는$$두 번째$$ 주입 s.t 입니다.$(\displaystyle$ $:\tau$
교차로	$\displaystyle \cap \cap \cap }$	$M{\displaystyle }$: ${\displaystyle \mathrm{\sigma displaydisplay}}$（ \ $displaystyle$ M : \ $sigma \ tau$ 、 ${\displaystyle M}$ :${\displaystyle }$${\displaystyle （}$$$\ $displaystyle$ M : \ $sigma$） 、 ${\displaystyle \mathrm{M<img\; alt="\{\backslash displaystyle\; M:\backslash sigma\; \}"\; aria-hidden="true"\; class="mwe-math-fallback-image-inline"\; src="https://wikimedia.org/api/rest\_v1/media/math/render/svg/d19edef7b46722a36691321bc46d47dfb44ed7a9"\; style="vertical-align:\; -0.338ex;\; width:5.709ex;\; height:2.176ex;">}}$ :$$（ \ $displaystyle$ M : \ $tau$ 。
유니언	$\displaystyle \cup \cup \cup }$	$M{\displaystyle }$: ${\displaystyle \mathrm{\sigma displaydisplay}}$（ \ $displaystyle$ M : \$sigma$\$tau$ 、 $M{\displaystyle }$ :${\displaystyle }$（$$\ $displaystyle$ M : \ $sigma$ ）$$$orた$ m M :$$（ \ $displaystyle$ M : \ $tau$ 。
기록.	$\displaystyle x:\displaystyle \rangle }$	M${\displaystyle }$: ${\displaystyle :}$x :$displaydisplay$ （ \ $displaystyle$ M : \ $langle$ x : \ $tau$\$rangle$ ）의 경우 M에는 $멤버x{\displaystyle }$ :$（$ \ $displaystyle$ x : \ $tau$가 있습니다.
다형성	$\displaystyle \forall {}\alpha .\displays }$	M${\displaystyle }$:${\displaystyle \mathrm{}\alpha }$ $τdisplay$ （ \ $displaystyle$ M : \ $forall$ {$$${\displaystyle \}}$ \ $alpha$. \ $displaystyle$） $、$ M : \ $tau$ [ \ $alpha$ : = \ $displaystyle ]$는 임의의 타입에 대해 ${\displaystyle M}$:${\displaystyle }$. [ \ tau$$\ $displaystyle$ ]입니다.
실존적	$\displaystyle \displaystyle {}\alpha .\displays }$	M${\displaystyle }$:${\displaystyle \mathrm{}\alpha }$.$τdisplay$ （ \ $displaystyle$ M : \ $exists$ {$$${\displaystyle \}}$ \ $alpha$. \ ${\displaystyle \mathrm{exists}}$$$$}$ ） type $、$ : \ $tau$[ \ $alpha$ : $=$ \ $displaystyle$ M : \ $tau ]$。
재귀적	$\displaystyle \mu \alpha .\displays }$	${\displaystyle M}$: ${\displaystyle \mathrm{\mu \alpha }}$.$$ （ \ $display$ $style$$$M : \$$$mu$\ alpha . \ display$$）$$ $M{\displaystyle }$ :$α$ [ \$tau =$ \${\displaystyle \mathrm{mu}}$\ ${\displaystyle \mathrm{alpha}}$. \ $display$ $]]$
종속 함수[b]	$\displaystyle (x:\display)\to\displays }$	$M{\displaystyle }$${\displaystyle }$: (${\displaystyle x}$ : ${\displaystyle )}$ ) $display$ { $displaystyle$ M : ( $x$: \ sigma )\ $to$ \ sigma$$ $}$$n{\displaystyle }$ n${\displaystyle }$N :${\displaystyle \tau }$、 [${\displaystyle x}$ :${\displaystyle =N}$ $]{$ $display style$ M ($N$ ) : \ $tau$[$$x : =$N$
종속 쌍[c]	$\displaystyle (x:\time)\times \times }$	${\displaystyle M}$: (${\displaystyle x}$ : ${\displaystyle )}$) × ${\$ { $displaystyle$ M : ( $x$: \ $sigma$) \ $times$ \ $times$인 $경우{\displaystyle }$ M ${\displaystyle =}$ (${\displaystyle N}$ ,${\displaystyle }$O$$) { $displaystyle$ M = ($N$ , $O )$는 쌍 s.t 입니다.${\displaystyle N}$: $(\displaystyle$ N$:\sigma)$ 및$$${\displaystyle }O{\displaystyle }$ :${\displaystyle \tau }$ [${\displaystyle x}$ : $=$ $]$ (\$displaystyle$ O$:\tau [x$:=$N$
종속 교차로[20]	$\displaystyle (x:\cap)\cap \caps }$	$M{\displaystyle }$: (${\displaystyle x}$ : ${\displaystyle )}$ ) $∩$ { $displaystyle$ M : ( $x$: \ $sigma$$$) \ $cap$\ $cap$ \ sigma$$$\}$ $m{\displaystyle }$${\displaystyle }m{\displaystyle }$ M :$$ m${\displaystyle }$m M :${\displaystyle \tau }$ [ x : $=$ $]{$ $displaystyle$ M : \ $tau$[$$x := M$]$ }$$。
가족교차[20]	$\displaystyle \bigcap _{x:\display}\displaystyle }$	M$$: $\underset{}{}$:$\underset{}{x}$ :$texttexttexttexttexttext$ { $textstyle$ M : \ $bigcap$ _ ${ x$ : \ $display$= $}$일 $경우$${\displaystyle ,}$ M :${\displaystyle \tau }$ [ x : $=$ N$$]{ $displaystyle$ M$$$:\tau$$$[ x :\$sigma$$\}\}$는 $임의$의 조건입니다$.$
가족 결합[20]	$\displaystyle \bigcup _{x:\display}\displaystyle }$	M$$: $\underset{}{}$ $\underset{}{:x}$ :$texttexttexttexttexttexttext{x:\bigcup$}\$display$ $\}$일 경우${\displaystyle }$M :${\displaystyle }$${\displaystyle \tau }$${\displaystyle }$[ x :\$tau$$$ $]{$ $display style$ M :\$tau$ [$x$ : =$N$] }은$$(일부 $용어{\displaystyle }$N $:\displaystyle$ N $:\sigma$에 대해 사용됩니다.

종속 유형

종속 유형은 스칼라 또는 값을 사용하여 다른 값의 유형을 보다 정확하게 기술한다는 개념을 기반으로 합니다.$예$를 들어 m ${\displaystyle \mathrm{t}}$ ${\displaystyle \mathrm{r}}$ ${\displaystyle \mathrm{i}}$x (${\displaystyle 3}$, ${\displaystyle 3}$)$${$displaystyle \mathrm {matrix}$(3,$3$)}는$$3${\displaystyle }$×$$3 $행렬의 유형일$ 수 있습니다.그런 다음 행렬 곱셈에 대한 다음 규칙과 같은 입력 규칙을 정의할 수 있습니다.

$\displaystyle \mathrm {filename} _{\mathrm {filename} (k,m)\times \mathrm {filename} (m,n)\to \mathrm {filename} (k,n)}$

여기서 k, m, n은 임의의 양의 정수 값입니다.Dependent ML이라고 하는 ML의 변형은 이 타입 시스템을 기반으로 작성되었지만, 종래의 의존 타입에 대한 타입 체크를 결정할 수 없기 때문에, 그것들을 사용하는 모든 프로그램이 어떤 종류의 제한 없이 타입 체크를 할 수 있는 것은 아닙니다.종속 ML은 Presburger 산술로 결정할 수 있는 종류의 동등성을 제한합니다.

에피그램과 같은 다른 언어에서는 언어 내의 모든 표현식의 값을 결정할 수 있으므로 유형 확인을 결정할 수 있습니다.그러나 일반적으로 결정 가능성의 증거는 결정할 수 없기 때문에, 많은 프로그램에서는 매우 간단하지 않을 수 있는 손으로 쓴 주석의 주석을 필요로 합니다.이로 인해 개발 프로세스가 지연되기 때문에 많은 언어 구현이 이 조건을 비활성화하는 옵션 형태로 쉬운 방법을 제공합니다.단, 이는 타입 체커가 타입 체크를 하지 않는 프로그램을 공급했을 때 무한 루프에서 실행되어 컴파일 실패의 원인이 되는 비용입니다.

선형 유형

선형 논리 이론에 기초하고 고유성 유형과 밀접하게 관련된 선형 유형은 항상 하나의 참조만 갖는 속성을 가진 값에 할당되는 유형입니다.이들은 파일, 문자열 등의 큰 불변의 값을 기술하는 데 유용합니다.이는 선형 개체를 파괴하는 동시에 유사한 개체를 생성하는 작업이 모두 이루어지기 때문입니다(예: ').str= str + "a"')는 "후드 밑"에서 임플레이스 변이로 최적화할 수 있습니다.일반적으로 이러한 돌연변이는 오브젝트에 대한 다른 참조를 유지하는 프로그램의 일부에 부작용을 일으켜 참조 투명성을 위반할 수 있기 때문에 가능하지 않습니다.또한 프로세스 간 통신을 위해 프로토타입 운영 체제 Singularity에서 사용되며, 프로세스가 경주 조건을 방지하기 위해 공유 메모리의 개체를 공유할 수 없도록 정적으로 보장합니다.Clean Language(Haskell과 유사한 언어)는 이 유형의 시스템을 사용하여 안전성을 유지하면서 (심층 복사를 수행하는 것에 비해) 매우 빠른 속도를 얻을 수 있습니다.

교차로 유형

교차로 유형은 중복되는 값 집합을 가진 다른 두 가지 유형의 모두에 속하는 값을 설명하는 유형입니다.예를 들어 대부분의 C 구현에서 부호 있는 문자는 -128 ~127 범위, 부호 없는 문자는 0 ~255 범위이므로 이들 2가지 유형의 교차 유형은 0 ~127 범위입니다.이러한 교차 유형은 두 가지 유형 모두 호환되므로 부호 있는 문자 또는 부호 없는 문자를 예상하는 함수에 안전하게 전달될 수 있습니다.

교차로 유형은 오버로드된 함수 유형을 설명하는 데 유용합니다. 예를 들어, 다음과 같습니다.int→int"는 정수 인수를 사용하여 정수를 반환하는 함수 유형입니다.float→float"는 float 인수를 사용하여 float를 반환하는 함수 유형입니다.이 두 유형의 교차를 사용하여 주어진 입력 유형에 따라 어느 한쪽을 수행하는 함수를 설명할 수 있습니다.이러한 함수는 "를 기대하는 다른 함수로 전달될 수 있습니다.int→int"는 안전하게 기능하며 단순히 ""를 사용하지 않습니다.float→float「기능.

하위 분류 계층에서는 유형과 상위 유형(예: 상위 유형)의 교차가 가장 파생된 유형입니다.형제 유형의 교차가 비어 있습니다.

Forsythe 언어에는 일반적인 교차 유형 구현이 포함됩니다.제한된 형식은 정제 유형입니다.

유니언 타입

유니언 유형은 두 가지 유형 중 하나에 속하는 값을 설명하는 유형입니다.예를 들어 C에서는 부호 있는 char의 범위는 -128~127이고 부호 없는 char의 범위는 0~255이므로 이들 2종류의 union은 접속하는 union 멤버에 따라 부분적으로 사용되는 -128~255의 전체 "가상" 범위를 가집니다.이 합집합 유형을 처리하는 함수는 이 완전한 범위의 정수를 처리해야 합니다.보다 일반적으로 유니언 타입에서 유효한 조작은 결합되는 두 타입 모두에서 유효한 조작뿐입니다.C의 "연합" 개념은 조합 유형과 유사하지만, 두 가지 유형이 아닌 두 가지 유형 모두에서 유효한 작업을 허용하기 때문에 형식이 안전하지 않다.결합 유형은 프로그램 분석에서 중요하며, 프로그램 분석에서는 정확한 특성(예: 값 또는 유형)을 알 수 없는 기호 값을 나타내기 위해 사용됩니다.

하위 분류 계층에서 유형과 상위 유형(예: 상위 유형)의 결합이 상위 유형입니다.형제 유형의 결합은 공통 조상의 하위 유형입니다(즉, 공통 조상에서 허용된 모든 작업은 결합 유형에서 허용되지만 다른 유효한 작업을 공통으로 가질 수도 있습니다).

실존형

실존 유형은 구현과 인터페이스를 분리할 수 있는 기능 때문에 모듈 및 추상 데이터 유형을 나타내기 위해 레코드 유형과 관련하여 자주 사용됩니다.예를 들어 "T = "X { a: X; f: (X → int); }" 유형은 X 유형의 데이터 멤버 a와 동일한 X 유형의 매개 변수를 가져 정수를 반환하는 함수 f를 가진 모듈 인터페이스를 나타냅니다.이는 다음과 같은 다양한 방법으로 구현할 수 있습니다.

• intT = { a: int; f: (int → int), }
• floatT = { a: float; f: (float → int), }

이들 유형은 모두 보다 일반적인 실존 유형 T의 하위 유형이며 구체적인 구현 유형에 해당하므로 이들 유형 중 하나의 값은 유형 T의 값이 됩니다."T" 타입의 값 "t"가 주어지면 추상형 X의 종류에 관계없이 "t.f(t.a)"가 적절한 유형임을 알 수 있습니다.이것에 의해, 특정의 실장에 적합한 타입을 선택할 수 있는 유연성을 얻을 수 있습니다.인터페이스 타입의 값(존재 타입)만을 사용하는 클라이언트는, 이러한 선택사항으로부터 격리됩니다.

일반적으로 타이프 체커가 특정 모듈이 어떤 존재 유형에 속하는지 추론하는 것은 불가능합니다.위의 예에서 intT { a: int; f: (int → int); }의 유형은 X { a: X; f: (int → int); }일 수도 있습니다.가장 간단한 해결책은 모든 모듈에 의도된 유형으로 주석을 다는 것입니다. 예를 들어 다음과 같습니다.

• intT = { a: int; f: (int → int), xX { a: X; f: (X → int), }

추상 데이터 유형과 모듈이 프로그래밍 언어로 구현된 지는 꽤 되었지만, 존 C는 1988년이 되어서야 비로소 실현되었습니다. 미첼과 고든 플로트킨은 "추상[데이터] 유형은 실존적 ^[21]유형을 가지고 있다"라는 슬로건 아래 공식 이론을 확립했다.이 이론은 시스템 F와 비슷하지만 보편적 수량화 대신 실존적인 2차 유형의 람다 미적분이다.

점진적 타이핑

점진적 타이핑은 컴파일 시(정적 타이핑) 또는 런타임 시(동적 타이핑)에 변수를 할당할 수 있는 타입 시스템입니다.소프트웨어 개발자는 하나의 ^[22]언어 내에서 적절한 타입 패러다임을 선택할 수 있습니다.점진적 입력은 정적으로 알려지지 않은 유형을 나타내기 위해 동적이라는 특별한 유형을 사용하고, 점진적 입력은 동적 유형을 다른 모든 유형과 관련짓는 일관성이라는 새로운 관계로 유형 평등 개념을 대체합니다.일관성 관계는 대칭이지만 ^[23]과도적이지 않습니다.

명시적 또는 암묵적 선언 및 추론

C 및 Java와 같은 많은 정적 유형 시스템은 유형 선언을 필요로 합니다. 프로그래머는 각 변수를 특정 유형과 명시적으로 연관시켜야 합니다.Haskell's와 같은 다른 것들은 유형 추론을 수행합니다: 컴파일러는 프로그래머가 변수를 어떻게 사용하는지에 따라 변수 유형에 대한 결론을 도출합니다.예를 들어, 함수가 주어집니다.f(x, y)그 때문에x그리고.y컴파일러는 함께 그것을 추론할 수 있다.x그리고.y는 숫자여야 합니다. 덧셈은 숫자에 대해서만 정의되기 때문입니다.따라서 에 대한 콜은f프로그램 내의 다른 곳에서 문자열이나 목록 등의 비필수 유형을 인수로 지정하면 오류가 발생합니다.

코드 내의 숫자 및 문자열 상수 및 식은 특정 컨텍스트의 유형을 암시할 수 있습니다.예를 들어 표현식3.14는 부동소수점 유형을 의미할 수 있지만,[1, 2, 3]는 정수 목록(일반적으로 배열)을 의미할 수 있습니다.

해당 유형 시스템에서 계산 가능한 경우 유형 추론이 일반적으로 가능하다.더욱이, 추론이 주어진 유형 시스템에 대해 일반적으로 계산 가능하지 않더라도, 종종 실제 프로그램의 큰 부분 집합에 대해 추론이 가능하다.Hindley-Milner의 버전인 Haskell의 유형 시스템은 유형 추론이 계산 가능한 소위 1등급 다형 유형에 대한 시스템 F†의 제한이다.대부분의 Haskell 컴파일러는 임의 순위 다형성을 확장으로 허용하지만, 이는 유형 추론을 계산할 수 없게 합니다.(다만, 타입 체크는 결정 가능하며, 랭크 1 프로그램은 타입 추론을 가지고 있습니다.명시적인 타입 주석이 주어지지 않는 한 상위 다형 프로그램은 거부됩니다.)

의사결정 문제

유형규칙을 이용하여 유형환경의 용어에 유형을 할당하는 유형시스템은 유형체크, 유형성, ^[24]유형거주의 결정문제와 자연스럽게 관련지어진다.

• Given a type environment ${\displaystyle \Gamma }$, a term ${\displaystyle e}$, and a type ${\displaystyle \tau }$, decide whether the term ${\displaystyle e}$ can be assigned the type ${\displaystyle \tau }$ in the type environment.
• $(\displaystyle$ e$)$라는 용어를 지정하면 e$(\displaystyle$ e$)$라는 $용어$를 $(\displaystyle$ $\$$Gamma$ 유형으로 $할당$할 수 있도록 $환경I$$(\$displaystyle \Gamma$$$)$ $및{\displaystyle \mathrm{}}$ $(\displaystyle$ \$tau$$)$가 존재하는지 여부를 판단합니다.
• 유형 환경$\gamma {\displaystyle \mathrm{}}$ { $displaystyle$\$Gamma$} 및$$ $유형{\displaystyle }$ ${\$ { $displaystyle$\$tau$에 따라 유형 ${\$ { $displaystyle$\$tau$}을(를) 할당할 수 있는 $용어{\displaystyle }$e { $displaystyle$ e$}$가 존재하는지 여부를 판단합니다.

통합형 시스템

C#이나 Scala와 같은 언어에는 통합형 ^[25]시스템이 있습니다.즉, 프리미티브타입을 포함한 모든 C#타입이 단일 루트오브젝트에서 상속됩니다.C#의 모든 유형은 Object 클래스에서 상속됩니다.Java나 Raku와 같은 언어에는 루트 타입이 있지만 오브젝트가 ^[26]아닌 원시 타입이 있습니다.Java는 기본 유형과 함께 존재하는 래퍼 개체 유형을 제공하여 개발자가 래퍼 개체 유형 또는 단순한 비개체 원시 유형을 사용할 수 있도록 합니다.Raku는 메서드에 ^[27]액세스하면 자동으로 원시 유형을 객체로 변환합니다.

호환성: 동등성과 서브타이핑

정적 유형 언어의 유형 검사기는 표현 유형이 해당 표현이 표시되는 컨텍스트에서 예상되는 유형과 일치하는지 확인해야 합니다.예를 들어 양식의 할당 문에서x := e표현식의 추론 유형은 선언 또는 추론된 변수 유형과 일치해야 합니다.x호환성이라고 불리는 이 일관성 개념은 각 프로그래밍 언어에 고유합니다.

의 유형 및 유형이x동일하고, 그 타입에 할당이 허가되어 있는 경우, 이것은 유효한 식입니다.따라서, 가장 단순한 유형 시스템에서, 두 유형이 호환되는지 여부에 대한 질문은 두 유형이 동일한지(또는 동등한지)의 문제로 감소합니다.그러나 언어마다 두 유형의 표현이 동일한 유형을 나타내는 것으로 이해되는 기준은 다릅니다.이러한 유형의 다른 등식 이론은 매우 다양하며, 두 가지 극단적인 경우는 동일한 구조를 가진 값을 기술하는 두 가지 유형이 동일한 구조 유형 시스템과 구문적으로 구별되는 두 가지 유형 표현이 동일한 유형을 나타내지 않는 주격 유형 시스템이다(즉, 유형은 b를 위해 동일한 "이름"을 가져야 한다).e equal).

서브타이핑을 사용하는 언어에서는 호환성 관계가 더 복잡합니다.B의 서브타입입니다.A, 다음으로 type의 값B타입 중 하나가 사용되는 상황에서 사용할 수 있습니다.A는, 그 반대가 true가 아닌 경우에서도, 예기(중요)되고 있습니다.동등성과 마찬가지로 하위 유형 관계는 각 프로그래밍 언어에 대해 다르게 정의되며 많은 변형이 가능합니다.언어에 파라메트릭 또는 애드혹다형성이 존재하는 것도 타입 호환성에 영향을 줄 수 있습니다.

「 」를 참조해 주세요.

• 유형 시스템 비교
• 공분산 및 역분산(컴퓨터 과학)
• 객체 지향 프로그래밍의 다형성
• 유형 규칙
• 서명의 종류
• 유형 이론

메모들

레퍼런스

추가 정보

• Cardelli, Luca; Wegner, Peter (December 1985). "On Understanding Types, Data Abstraction, and Polymorphism" (PDF). ACM Computing Surveys. 17 (4): 471–523. CiteSeerX 10.1.1.117.695. doi:10.1145/6041.6042. S2CID 2921816.
• Pierce, Benjamin C. (2002). Types and Programming Languages. MIT Press. ISBN 978-0-262-16209-8.
• Cardelli, Luca (2004). "Type systems" (PDF). In Allen B. Tucker (ed.). CRC Handbook of Computer Science and Engineering (2nd ed.). CRC Press. ISBN 978-1584883609.
• Tratt, Laurence (July 2009). "5. Dynamically Typed Languages". Advances in Computers. Vol. 77. Elsevier. pp. 149–184. doi:10.1016/S0065-2458(09)01205-4. ISBN 978-0-12-374812-6.

외부 링크

Wikibook Ada Programming에는 다음 항목에 대한 페이지가 있습니다.종류

Wikibook Haskell에는 다음 항목에 대한 페이지가 있습니다.

• Wikimedia Commons의 Type 시스템 관련 미디어
• Smith, Chris (2011). "What to Know Before Debating Type Systems".