자료형 체계

컴퓨터 과학에서, 자료형 체계는 "계산한 값의 종류에 따라 구문을 분류하기 위해 다루기 쉬운 구문의 프레임워크"로 정의된다. 자료형 체계는 각각의 계산된 값이 자료형과 함께 연합한다. 이러한 값의 유출을 검토함으로써, 자료형 체계는 자료형 오류가 발생할 수 없다는 것을 증명하려고 시도한다. 문제의 자료형 체계는 입력 오류의 구성을 결정하지만, 자료형 체계는 일반적으로 값의 특정 종류를 기대하고 작업이 그 작업을 이해하지 않는 값을 함께 사용하지 않는 보장을 추구한다.

컴파일러는 필요로 하는 저장 용량과 값에서 작업을 위한 알고리즘의 선택을 최적화하는 값의 정적 자료형을 사용할 수도 있다. 수많은 C 컴파일러의 "부동" 자료형에서, 예를 들어, 단일 정밀도 부동 소수점 숫자에 대한 IEEE 사양과 함께 조화롭게 32 비트에 표시된다. C는 예를 들면 이러한 값 (부동 소수점 또한, 곱셈 등)에 대한 부동 소수점 특정 작업을 사용한다.

형식 제약의 깊이와 그 평가의 방법은 언어의 정형에 영향을 미친다. 프로그래밍 언어 추가 자료형 다형성의 경우 각 자료형에 대한 다양한 구체적인 알고리즘과 함께 작업을 연결할 수 있다. 자료형 이론은 비록 프로그래밍 언어의 구체적인 자료형 체계가 컴퓨터 아키텍처, 컴파일러 구현 및 언어 디자인의 실용적인 문제에서 발생하는 자료형 체계의 연구이다.

기본

할당 자료형(정형)은 비트의 순서에 의미를 준다. 자료형은 보통 메모리에 함께 있는 값들 중 하나 또는 변수와 같은 객체가 연관이 있다. 모든 값은 단순히 컴퓨터에 비트 순서로 구성되어 있기 때문에, 하드웨어는 심지어 메모리 주소, 명령어 코드, 문자, 정수와 부동소수점 사이는, 본질적으로 혼자서 비트 패턴을 기반으로 그것들 사이를 구별하지 않게 된다. 비트의 순서와 형을 연결하는 것은 프로그램과 프로그래머가 어떻게 이 비트의 순서를 이해해야 하는지 알려준다.

자료형 체계가 제공하는 주 기능은 다음과 같다:

• 안전 – 자료형의 사용은 무의미하거나 아마도 잘못된 코드를 감지할 수 있게 컴파일러가 허용할 것이다. 예를 들어, 산술의 규칙에서 정수에 문자열을 나눌 방법을 지정하지 않았기 때문에 우리는 잘못된 3 / "Hello, World" 와 같은 표현식을 확인할 수 있다. 아래에서 설명한 대로, 강력한 정형은 안전을 더 제공하지만, 일반적으로 완벽한 안전을 보장하지 않는다(자료형 안전문서 참조).
• 최적화 – 정적 형 검사가 유용한 컴파일 시간 정보를 제공할 수 있다. 예를 들어, 만약 자료형이 메모리 안에 4 바이트의 배수 값을 정렬하는 것이 필요하면, 컴파일러는 보다 효율적인 기계 명령을 사용할 수 있다.
• 문서화 – 더 많은 표현 형 체계, 자료형은 문서의 형태로 제공, 이후 자료형은 프로그래머의 의도를 보여줄 수 있다. 예를 들어, 시간 기록은 정수로 나타낼 수 있다—하지만 프로그래머는 단지 정수 형보다는 시간 기록 형식을 반환으로 함수를 선언하는 경우, 함수의 의미는 문서의 일부가 된다.
• 추상화 (또는 압축) – 자료형은 프로그래머들이 비트 또는 바이트보다 높은 수준에서 프로그램에 대한 생각, 낮은 수준의 구현으로 신경 쓰이게 하지 않는 것을 허용한다. 예를 들어, 프로그래머는 바이트의 단순한 배열 대신 문자 값의 모음으로 문자열을 생각할 수 있다. 또는, 자료형은 프로그래머가 두 하위 체계 사이의 인터페이스 표현을 허용할 수 있다. 이것은 하위 체계의 상호 운용에 필요한 정의를 배치하는 데 도와주고 불일치하면 그 하위 체계의 통신이 되지 않는다.

자료형 검사

검증 과정과 자료형의 제약 조건 – 자료형 검사 – 시행은 컴파일 시간 (정적 검사) 또는 런타임 (동적 검사) 중 하나가 발생할 수 있다. 만약 언어 명세서가 강하게 그 분류 규칙을 필요로 한다면 (즉, 더 많거나 적은 정보를 잃지 않는 것만 자동 자료형 전환을 허용한다), 강력한 정형으로, 그렇지 않다면, 약한 정형으로 하나의 프로세스를 참조할 수 있다. 조건은 엄격한 의미에서 사용되지 않는다.

정적 정형

프로그래밍 언어는 자료형 검사가 실행 시간과 반대로 컴파일 시간 동안 수행했을 때 정적 정형을 사용했다고 말한다. 정적으로 정형된 언어는 액션스크립트 3, 에이다, C, C++, C#, D, Eiffel, F#, 포트란, Go, 하스켈, JADE, 자바, ML, 오브젝티브-C, OCaml, 파스칼, 펄 (스칼라, 배열, 해시 및 서브루틴의 구별에 대하여) 그리고 스칼라를 포함한다.

정적 정형은 프로그램 확인의 제한된 형태이다 (형 안전 참조): 따라서, 그것은 많은 자료형 오류가 개발주기에 일찍 잡힐 수 있다. 정적 형 검사기는 오직 자료형 정보가 컴파일 시간에 결정될 수 있음을 평가하지만, 프로그램의 가능한 모든 실행에 대한 검사 조건 보유를 확인할 수 있고, 프로그램이 실행될 때마다 매번 자료형 검사를 반복할 필요가 없다. 실행 자료형 검사를 생략하고 다른 최적화를 활성화함으로써 프로그램 실행도 보다 효율적으로 (즉, 빠르게 또는 감소된 메모리를 사용) 만들 수 있다.

왜냐하면 그것이 컴파일되는 동안 자료형 정보를 평가하기 때문에, 따라서 부족한 자료형 정보는 오직 런타임에서만 구할 수 있다, 정적 형 검사기는 보수적이다. 그것들은 런타임에서 충분히 실행하는 일부 프로그램을 거부할 수 있을 것이다, 그러나 그것은 정적으로 충분히 정형된 것으로 결정할 수 없다. 예를 들어, 표현식 <complex test>는 항상 실행 시간에서 true를 평가하고, 이 코드를 포함하는 프로그램이다

if <complex test> then 42 else <type error>

는 나쁜 자료형으로서 거부될 것이며, 왜냐하면 정적 분석은 else 분기가 이동될 수 없는 것을 확인할 수 없기 때문이다. 정적 자료형 검사기의 보수적인 동작은 가끔씩 <complex test>를 false로 평가할 때 유익하다: 정적 자료형 검사기는 드물게 사용되는 코드 경로에서 자료형 오류를 감지할 수 있다. 정적 자료형 검사없이, 100% 범위에서도 코드 범위 테스트는 이러한 자료형 오류를 발견하지 못할 수 있다. 테스트는 이러한 유형의 오류를 감지하지 못할 수 있기 때문에 값은 생성된 모든 위치의 조합이고 어떤 값은 반영되어야 하는데 사용된 모든 위치이다.

가장 널리 사용되는 정적으로 정형된 언어의 경우는 공식적으로 형 안전이 없다. 그것들은 사용하는 프로그래밍 언어 규격 안에서 "허점" 코드를 작성하는 프로그래머들은 정적 형 검사 그리고 문제의 넓은 범위의 주소에 의해 그 수행 확인을 회피한다. 예를 들어, 대부분의 C 스타일 언어는 자료형 장난을 가지고, 하스켈은 unsafePerformIO 같은 기능을 가지고 있다: 이러한 작업은 런타임에 안전하지 않을 수 있고, 거기에 그것들은 프로그램이 실행 값의 잘못된 입력으로 인해 원하지 않는 동작을 일으킬 수 있다.

동적 정형

프로그래밍 언어는 동적으로 정형된 그 자료형 검사의 대부분이 컴파일 시간에서는 반대인 실행 시간에서 수행되었을 때라고 말한다. 동적 정형에서, 값은 자료형을 가지고 있지만 변수는 그렇지 않다; 즉, 변수는 모든 자료형의 값을 참조할 수 있다. 동적으로 정형된 언어의 경우는 APL, 얼랑, 그루비, 자바스크립트, 리스프, 루아, MATLAB/GNU 옥타브, 펄 (사용자 정의를 위한 자료형이지만 기본이 아닌 자료형), PHP, 프롤로그, 파이썬, 자이썬, 루비, 스몰토크, 클로슈어 그리고 Tcl을 포함한다.

동적으로 정형된 언어의 구현은 일반적으로 그것들의 자료형 정보를 포함하는 "태그"로 런타임 개체를 연결한다. 이 런타임 분류는 자료형 검사를 구현하고 다중 정의된 함수를 발송한 다음에 사용되지만, 또한 동적 발송의 전반적 사용을 활성화할 수 있고, 잘해야 정적으로 정형된 언어에서 후기 바인딩과 유사한 관용어는 번거로울 것이고, 변종 자료형 또는 이와 유사한 기능의 사용을 요구한다.

더 넓게, 아래에서 설명한 것처럼, 동적 정형은 동적 프로그래밍 언어 기능에 대한 지원을 향상시킬 수 있고, 런타임 데이터를 기반으로 한 기능과 자료형을 창출하는 것 등이 있다. (그럼에도 불구하고, 동적으로 정형된 언어는 일부 또는 전부 같은 기능을 지원하지 않아도, 일부 동적 프로그래밍 언어는 정적으로 정형되어 있다.) 한편, 동적 정형은 적은 선천적 보장을 제공한다: 동적으로 정형된 언어는 정적 자료형 검사기에 의해 무효로 지배될 일부 프로그램을 실행하려고 허용 및 시도하는데, 프로그램의 오류 때문이거나 정적 자료형 검사가 너무 보수적으로 되기 때문이다. 동적 정형은 런타임 자료형 오류가 발생할 수 있다—즉, 런타임에서, 값은 예상치 못한 유형이 있을 수 있고, 그 자료형에 대한 무의미한 작업이 적용된다. 이런 오류가 프로그래밍 실수 구문에서 오랜 시간 후에 발생할 수 있다—즉, 데이터의 잘못된 자료형의 장소로 전달되는 구문은 작성하지 않아야 한다. 이것은 버그를 찾기 어려울 수도 있다.

동적 정형 언어 체계들의 런타임 검사는 잠재적으로 정적으로 정형된 언어의 경우보다 더 정교할 수 있고, 그들은 동적인 정보뿐만 아니라 소스 코드로부터 정보를 사용할 수 있다. 한편, 런타임 검사는 오직 프로그램의 특정 실행에서 조건을 잡는 것을 주장하고, 검사는 매번 프로그램을 실행하는 동안 반복된다.

동적으로 정형된 언어의 개발은 자주 단위 테스트와 같은 프로그래밍 정책에 의해 지원된다. 테스트는 전문 소프트웨어 개발에서 핵심 방법이고, 동적으로 정형된 언어의 경우에 특히 중요하다. 실제로, 올바른 프로그램이 작동을 보장하기 위해 했던 테스트는 정적 자료형 검사보다 훨씬 넓은 오류 범위를 감지할 수 있지만, 반대로 정적 자료형 검사가 감지할 수 있는 오류를 종합적으로 검색할 수 없다.

동적 및 정적 정형의 조합

프로그래밍 언어의 정적 정형의 존재는 반드시 모든 동적 정형 구조가 없는 상태를 의미하는 것은 아니다. 예를 들어, 자바와 다른 표면에서 정적으로 정형된 언어의 경우, 하위 형변환 및 런타임 자료형 검사에 따라 다른 종류의 작업을, 동적 정형의 형태로 지원한다. 더 일반적으로, 대부분의 프로그래밍 언어는 데이터를 서로 다른 '종류'를 통해, 서로소 합집합과, 변형 자료형 및 다형성 개체와 같은 파견에 대한 방식을 포함한다: 자료형 주석 또는 자료형 검사와 상호 작용조차 하지 않을 때 이러한 방식은 동적 정형 구현에서 실질적으로 유사하다. 정적 및 동적 정형 사이의 상호 작용에 대한 자세한 내용을 보려면 프로그래밍 언어를 참조한다.

특정 언어, 예를 들어 클로슈어는, 기본적으로는 동적으로 정하지만, 이 동작을 허용하는 것은 정적 정형에서의 결과로 명시적인 자료형의 사용 힌트를 통해 무시한다. 이러한 힌트를 사용하는 이유 중 하나는 코드의 성능에 민감한 부분에서 정적 정형의 성능 이점을 달성하는 것이다.

4.0의 출시로, 닷넷 프레임워크 '동적' 자료형의 '정적' 개체는 개체 참조를 해결하기 위해 동적 설비를 심문하는 닷넷 런타임에 대한 자리표시자에 의하여 System.Dynamic 이름공간을 통해 동적 정형의 정의 변종을 지원한다.

실제로 정적 및 동적 자료형 검사하기

정적 및 동적 정형 사이의 선택은 트레이드오프를 필요로 한다.

정적 정형은 컴파일 시간에 안정적으로 자료형 오류를 찾을 수 있다. 이것은 제공되는 프로그램의 신뢰성이 증가할 것이다. 그러나, 프로그래머는 일반적으로 자료형 오류가 발생하는 방법을 통해 반대하고, 따라서 적절하게 코드에서 설계된 자료형을 대표해서 잡은 것으로 코딩한 이 버그의 비율을 통해 반대한다. 정적 정형 지지자들은 자료형 검사가 잘 되어있을 때 프로그램이 더 신뢰할 수 있다고 믿고, 동적 정형 지지자들은 안정적이고 작은 데이터베이스 버그가 증명된 배포 코드를 가리킨다. 자료형 체계의 강도가 증가된 다음에 정적 정형의 값은 아마도 증가할 것이다. 만약 프로그램에 사용되는 자료형이 프로그래머에 의해 제대로 선언되거나 정확하게 컴파일러에 유추되는 경우, 이러한 종속 ML과 에피그램으로 의존적으로 정형된 언어의 지지자들은 거의 모든 버그가 자료형 오류로 간주될 수 있는 제안을 한다.

정적 정형은 보통 더 빠르게 실행하는 컴파일된 코드에서 발생한다. 컴파일러가 사용하는 정확한 자료형을 알고있을 때, 그것은 최적화된 기계 코드를 생성할 수 있다. 더 나아가, 정적으로 정형된 언어를 위한 컴파일러는 어셈블러보다 쉽게 ​​단축키를 찾을 수 있다. 일부 동적으로 정형된 언어와 같은 커먼 리스프는 매우 합리적인 최적화를 위한 옵션 정형을 허용한다. 정적 정형은 이것을 보급한다. 최적화를 참조한다.

반대로, 동적 정형은 컴파일러가 더 빠르게 실행할 것과 인터프리터가 동적으로 새로운 코드를 불러오는 것을 허용할 수 있고, 동적으로 정형된 언어에서의 소스 코드에 대한 변경 사항 때문에 수행하기 위해 덜 검사한 것과 코드를 되짚는 것에서 발생할 수 있다. 이것도 편집 - 컴파일 - 테스트 - 디버그 주기를 줄일 수 있다.

정적으로 정형된 언어의 경우 부족한 자료형 추론 (예: C와 Java 등)은 프로그래머들이 메서드나 함수를 사용하고자 하는 자료형을 선언할 것을 요구한다. 이것은 어느 컴파일러가 프로그래머가 동기화 중에 표류할 것을 무시하거나 허용하도록 허가하지 않을 것을 프로그램을 위한 추가 문서로 검색할 수 있다. 그러나, 언어는 정적으로 자료형 선언 없이 정형될 수 있다 (예시는 하스켈, 스칼라 그리고 낮은 정도의 C#를 포함한다), 그래서 명시적인 자료형 선언은 모든 언어에서 정적 정형을 위한 요구 사항을 필요로 하지 않는다.

동적 정형은 몇몇 정적 자료형 검사가 불법으로 거부할 것이라는 구조를 허용한다. 예를 들어, 코드로 임의의 데이터를 실행하는 eval 함수가 가능하게 된다. eval 함수는 정적 자료형으로 가능하지만, 고급 대수적 데이터 자료형의 사용이 필요하다. 또한, 동적 정형이 자리 표시자 데이터 구조 본격적인 자료 구조 (보통 실험 및 시험의 목적) 대신에 투명하게 사용된 (모의 객체)를 허용하는 등 전환 코드와 프로토 타입을 수용하는 것보다 낫다.

강한 및 악한 정형: 리스코브 정의

이 부분의 본문은 약한 및 강한 정형입니다.

강한 및 약한 정형

이 부분의 본문은 강하게 정형된 프로그래밍 언어입니다.

안전하게 및 불안전하게 정형된 체계들

이 부분의 본문은 자료형 안전입니다.

다형성 및 자료형들

이 부분의 본문은 자료형 다형성입니다.

오리 정형

이 부분의 본문은 오리 정형입니다.

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

이 주제의 자세한 내용은 자료형 추론 문서를 보십시오.

자료형들의 유형들

이 부분의 본문은 자료형입니다.

같이 보기

• 자료형 규칙
• 공분산과 역분산 (컴퓨터 과학)
• 연산자 오버로딩
• 객체 지향 프로그래밍에서의 다형성
• 프로그래밍 언어
• 부호를 지닌 것
• 자료형 체계 상호 참조 목록
• 자료형 서명
• 자료형 이론