정적 유형 시스템은 프로토 타입 기반 언어의 디자인에 어떤 영향을 줍니까?

프로토 타입 기반 언어에 대한 Wikipedia 기사 에는 다음 단락이 포함되어 있습니다.

거의 모든 프로토 타입 기반 시스템은 해석되고 동적으로 유형이 지정된 언어를 기반으로합니다. 그러나 정적으로 형식화 된 언어를 기반으로하는 시스템은 기술적으로 가능합니다.

정적 유형 시스템은 어떤 방식으로 제한을 부과하거나 프로토 타입 기반 언어에 복잡성을 도입합니까? 왜 더 동적으로 유형화 된 프로토 타입 언어가 있습니까?

기본 유형과 객체의 경계가 흐려지고 종종 인위적으로 도입됩니다. 예를 들어, C에서 구조체는 레코드가 아닌 파생 된 비 객체 유형입니다. C ++에서 구조체는 모든 필드가 공용 인 객체 인 클래스입니다. 여전히 C ++은 C와 거의 역 호환이 가능합니다. 여기서 테두리가 부드럽습니다.

프로토 타입 기반 프로그래밍의 경우 런타임시 객체를 변경할 수 있어야합니다. 런타임시 각각의 유형이 변경되므로 한 유형의 클래스가 다른 유형으로 변경되므로 유형이 변경되므로 반드시 소프트 유형이어야합니다.

그러나 기본 및 파생 된 비 개체 유형을 정적으로 유지할 수 있습니다. 그러나 이것은 이상한 불일치를 초래하고, 객체는 소프트 타입이고, 비 오브젝트는 정적 타입이며, 둘 사이에 하드 바리어가 설정되어야합니다. 구조를 변형 할 수 있어야합니까? 끈? Number는 클래스 또는 기본 유형이거나 기본 유형 집합, int / float / bignum / etc 여야합니까?

이 유니폼을 갖기 위해서는 더 자연스럽고 배우기 쉽고 사용하고 쓰기가 쉬우 며 모든 유형은 변경 가능하거나 런타임에 유형을 변경할 수 없습니다. 하나의 유형 (객체) 만 변경할 수 있다고 선언하면 두통과 두 세계의 문제가 생깁니다.

정적 유형은 다음과 같습니다.

• 구현하기 쉬움
• 더 빠르고 효율적
• 더 안전한
• 추상화로 인해 큰 시스템을 쉽게 유지 관리 / 문서화 할 수 있습니다.

동적 유형은 다음과 같습니다.

• 더 빨리 쓰기
• 더 간결한
• 배우기 쉬운 언어
• 디자인 오류에 대한 더 많은 용서.

이 두 가지를 혼합하면 많은 희생을 겪게됩니다.

• 이전 두 가지보다 구현이 어려워졌습니다.
• 소프트 타입 사용 여부에 따라 속도가 달라집니다 ... 사용하면 속도가 낮고, 사용하지 않으면 언어를 선택하는 이유는 무엇입니까?
• 유형 안전은 모든 객체 유형의 창 밖입니다.
• 한 유형이 다른 유형으로 변형되는 방식을 따르는 것은 매우 어려운 작업입니다. 그것을 문서화-매우 어렵다.
• 간결함과 쓰기 속도를 없애는 기본 유형으로 모든 부기를 계속해야합니다.
• 언어의 복잡성은 "특정"언어보다 높습니다 (배우기가 더 어렵습니다).
• 동적 유형의 "용서"는 일치하지 않는 속성 유형에서 매우 까다로운 오류 경향으로 대체됩니다.

어려운 점은 다음과 같습니다. 객체를 메서드의 사전 또는 메시지에 응답하는 것으로 간주하여 일반적인 정적 형식의 OO 언어에 대해 다음을 관찰하십시오.

• 모든 사전 키 / 메시지는 일반적으로 정적으로 선언 된 식별자를 사용하여 미리 선언됩니다.

• 특정 메시지 세트가 미리 선언되어 있으며 응답하는 메시지를 판별하기 위해 오브젝트가이 세트와 연관되어 있습니다.

• 한 세트의 메시지가 다른 세트의 하위 세트 인 포함 관계는 정적으로 명시 적으로 선언됩니다. 선언되지 않았지만 논리적 하위 집합이 유효하지 않습니다.

• 유형 검사는 모든 메시지가 응답하는 객체로만 전송되도록합니다.

이러한 모든 것은 프로토 타입 기반 시스템과 어느 정도 상충됩니다.

• 메시지 이름은 "원자"또는 인턴 된 문자열 등의 형태로 미리 선언 할 수 있지만 그 밖의 것은 거의 없습니다. 객체의 가소성은 유형을 메소드에 지정하는 것이 어색하다는 것을 의미합니다.

• 메시지 집합이 다른 방식이 아닌 개체가 응답하는 방식으로 정의되는 것은 프로토 타입 기반 시스템의 필수 기능 일 것입니다. 컴파일 타임에 특정 조합에 별칭을 할당하는 것이 합리적이지만 런타임에 결정된 메시지 세트가 가능해야합니다.

• 위 두 가지의 실제 영향은 명시 적 선언이 완전히 실행 불가능한 포함 관계로 인해 발생합니다. 정적, 공칭 서브 타이핑 의미의 상속은 프로토 타입 기반 시스템과는 반대입니다.

우리 가 실제로 바꾸고 싶지 않은 마지막 요점을 알려 줍니다. 우리는 여전히 메시지가 응답하는 객체로만 메시지가 전송되도록하고 싶습니다. 하나:

• 어떤 메시지가 그룹화 될 수 있는지 정적으로 알 수 없습니다.
• 어떤 그룹이 다른 그룹의 하위 그룹인지 알 수 없습니다.
• 어떤 그룹이 가능한지 알 수 없습니다.
• 단일 메시지와 함께 어떤 종류의 인수가 전송되는지 지정할 수도 없습니다.
• 기본적으로 우리는 완전히 일반적인 경우에 많은 것을 지정할 수 없다는 것을 알았습니다.

어떻게이 문제를 해결할 수 있습니까? 전체 일반성을 어떻게 든 제한하거나 (불쾌하고 프로토 타입 기반 시스템 사용의 이점을 신속하게 죽일 수 있음), 타입 시스템을 정확한 타입 보다는 훨씬 유동적이고 제한 적인 표현으로 만듭니다.

구속 조건 기반 유형 시스템은 구조 하위 유형의 개념으로 빠르게 이어지는데 , 이는 매우 느슨한 의미에서 "덕 유형"과 정적으로 동등한 것으로 간주 될 수 있습니다. 여기서 가장 큰 장애물은 이러한 시스템이 유형 검사에 훨씬 더 복잡하고 잘 알려져 있지 않다는 것입니다 (이는 사전 연구가 거의 필요하지 않음).

요약 : 가능하면 공칭 정적 유형 시스템이나 런타임 메타 데이터를 기반으로하는 동적 시스템보다 수행하기가 더 어려워서 귀찮은 사람이 거의 없습니다.

정적으로 형식화 된 프로토 타입 기반 언어를 달성하는 방법은 템플릿 및 개념을 중심으로 언어를 작성하는 것입니다.

개념은 한 번 C ++ 0x에 계획된 기능이었습니다. C ++ 템플릿 일반 코드는 이미 사실상의 "입력 오리 - 정적". Concepts의 개념은 관계에 기반을 둔 클래스 상속 모델을 요구하거나 암시하지 않고 필요한 멤버 및 유형의 특성에 대해 말할 수있는 것입니다 (이미 "정적으로 오리 유형"인 기존 템플릿 코드로 작업해야했기 때문에) ).

템플릿과 개념을 기초로 한 언어에서는 프로토 타입 기반의 개념이 될 것이며 템플릿은 값 유형을 구현하는 데 사용되거나 사용되지 않을 수있는 클래스 모델을 신경 쓰지 않아도됩니다.

언어가 자체 메타 언어가 될 수 있도록 단계적 컴파일을 사용하는 비법 외에도, 이러한 개념의 프로토 타입 파생물은 일단 생성 된 후에는 반드시 변경할 수 없습니다. 그러나 프로토 타입 기반이 아닌 반대 의견은 빨간 청어입니다. 단순히 기능적인 언어 일 것입니다. 또한 작동 하는 동적 프로토 타입 기반 언어 가 시도되었습니다 .