판 비교
1번째 줄 근처
추가: ## 개요
추가: 자료형 체계(type system)는 컴퓨터 프로그램의 구성 요소인 변수, 표현식, 함수, 모듈 등에 '자료형(type)'이라는 속성을 부여하는 규칙의 집합이다[1]. 프로그래밍 언어 이론에서는 "계산될 값을 분류하여 특정한 종류의 프로그램 오류가 일어나지 않음을 증명하는 계산 가능한 방법"으로 정의된다[2]. 모든 계산된 값은 자료형을 가지며, 자료형 체계는 프로그램 내 값의 흐름을 검사하여 자료형에 맞지 않는 값이 할당되는 자료형 오류(type error)를 방지한다[2]. 논리적으로 맞지 않는 자료형 사이의 연산이나 잘못된 메모리 접근 등이 대표적인 자료형 오류에 해당하며, 구체적으로 어떤 연산이 오류로 간주되는지는 각 자료형 체계마다 다르다[2].
추가:
추가: 자료형 체계는 컴파일러나 인터프리터에 내장되어 언어 설계의 일부로 명시된다[3]. 선택적 도구를 통해 원래의 자료형 문법과 문법을 사용해 추가 검사를 수행함으로써 확장할 수도 있다[3]. 주요 목적은 값이 프로그램의 서로 다른 부분에서 해석되는 방식의 불일치로 인한 버그 가능성을 줄이는 것이다[3]. 또한 비즈니스 규칙 표현, 컴파일러 최적화 지원, 다중 디스패치 허용, 문서화 역할 등 부가적인 목적도 가진다[3].
추가:
추가: ## 사례
추가:
추가: 자료에 명시된 언어별 자료형 체계 분류 사례는 다음과 같다[2].
추가:
추가: **정적 정형 언어**: 액션스크립트 3, 에이다, C, C++, C#, D, 아이펠, F#, 포트란, Go, 하스켈, JADE, 자바, ML, 오브젝티브-C, OCaml, 파스칼, 펄(스칼라/배열/해시/서브루틴 구별), 스칼라.
추가:
추가: **동적 정형 언어**: APL, 얼랭, 그루비, 자바스크립트, 리스프, 루아, MATLAB/GNU 옥타브, 펄(사용자 정의 자료형), PHP, 프롤로그, 파이썬, 자이썬, 루비, 스몰토크, 클로저, Tcl.
추가:
추가: **혼합/확장 사례**: 자바(하위 형변환·런타임 검사로 동적 기능 지원), 클로저(자료형 힌트로 정적 최적화 선택), C# 4.0+(`dynamic` 키워드로 동적 바인딩), .NET 4.0+(`System.Dynamic` 네임스페이스).
추가:
추가: C 언어의 단순 자료형 체계 예시: 함수 인터페이스가 매개변수 자료형을 선언하고, 호출 시 인자 자료형이 일치하는지 컴파일러가 검사한다[3]. 불일치 시 컴파일 오류/경고를 내며, 일치하면 해당 자료형에 맞는 기계어 명령(부동소수점 연산 등)을 선택해 최적화한다[3].
추가:
추가: ## 규제·논란·평가
추가:
추가: ### 정적 vs 동적 정형의 트레이드오프
추가:
추가: 정적 정형은 컴파일 타임에 자료형 오류를 안정적으로 찾아 프로그램 신뢰성을 높인다[2]. 컴파일러가 정확한 자료형을 알면 최적화된 기계어를 생성해 보통 더 빠른 실행 코드가 나온다[2]. 명시적 자료형 선언은 추가 문서 역할을 하며 컴파일러가 프로그래머의 의도와 어긋나는 변경을 방지한다[2]. 다만 자료형 추론이 부족한 언어에서는 선언 부담이 크다[2].
추가:
추가: 동적 정형은 컴파일 과정이 짧거나 없어 인터프리터가 동적으로 새 코드를 로드하기 쉽고, 편집-컴파일-테스트-디버그 주기를 단축할 수 있다[2]. 정적 검사기가 거부할 구조(예: `eval`로 임의 코드 실행, 목 객체로 자리표시자 데이터 구조 대체 등)를 허용해 프로토타이핑과 실험에 유리하다[2]. `eval`은 정적 자료형으로도 고급 대수적 자료형을 쓰면 가능하지만 복잡하다[2].
추가:
추가: 정적 정형 지지자는 잘 정형된 프로그램이 더 신뢰할 수 있다고 보고, 동적 정형 지지자는 안정적 배포 코드와 작은 버그 데이터베이스를 근거로 든다[2]. 자료형 체계 강도가 높아질수록 정적 정형의 가치는 커지며, 의존적 자료형 언어(ML, 에피그램 등) 지지자는 거의 모든 버그를 자료형 오류로 간주할 수 있다고 주장한다[2].
추가:
추가: ### 정적 검사의 본질적 한계
추가:
추가: 튜링 완전 언어에서 정적 자료형 검사는 본질적으로 보수적이다[3]. 건전성(soundness, 잘못된 프로그램 모두 거부)과 판정가능성(decidability, 알고리즘으로 잘 정형됨 판별 가능)을 모두 만족하면 필연적으로 불완전해진다(즉, 올바른 프로그램도 거부함)[3]. 이는 정지 문제와 연관된다[2].
추가:
추가: 자료형 안전성이 프로그램 정확성에 기여하지만, 자료형 검사 자체가 판정불가능 문제가 될 수 있다(정지 문제)[3]. 컴파일 타임 검사만으로는 0으로 나누기 같은 런타임 오류를 잡지 못하는 것이 일반적이다[3]. 이를 방지하려면 의존적 자료형으로 0이 아닌 수의 자료형을 표현하거나, 프로그램 분석, 소프트웨어 테스트 등 다른 정형/경험적 방법이 필요하다[3].
추가:
추가: ### 다운캐스팅과 동적 검사의 필연성
추가:
추가: 하위형 다형성에서 상위 타입 값을 하위 타입으로 변환하는 다운캐스팅은 정적으로 안전성을 증명하기 어려워 동적 검사가 필수적이다[3]. 이는 다운캐스팅에 대한 주요 비판 지점이기도 하다[3]. 동적 검사는 정의상 런타임 실패를 유발할 수 있으며, 언어에 따라 이를 예외로 복구 가능하게 하거나 치명적 오류로 처리한다[3].
추가:
추가: ### 강한/약한 정형 분류의 모호성
추가:
추가: 강한 정형과 약한 정형의 구분은 학술적으로 엄격하지 않으며[2], 언어마다 허용하는 암시적 변환 범위(포인터 연산, 불리언 컨텍스트에서의 암시적 변환 등)가 달라 스펙트럼상으로 이해하는 것이 적절하다.
추가:
추가: ### 표현력과 복잡성의 긴장
추가:
추가: 자료형 체계가 정교해질수록 더 세밀한 규칙 집합을 얻지만, 자료형 추론 등이 판정불가능해지고 프로그래머가 코드에 주석을 달거나 컴퓨터 연산을 고려해야 하는 부담이 커진다[3]. 모든 프로그래밍 관행을 자료형 안전하게 만족시키는 충분히 표현력 있는 자료형 체계를 찾는 것은 어려운 과제다[3].
추가:
추가: 이 문서는 GGWiki AI가 공개 자료(아래 출처)를 조사해 새로 쓴 초안입니다. 틀린 내용은 편집하거나 이의 제기로 알려 주세요.
