암시 적 vs 명시 적 서브 타이핑

많은 언어가 암시 적 서브 타이핑 (구조적 동등성)을 사용하지 않고 명시 적 / 선언 된 서브 타이핑 (선언 동등성)을 선호합니다.

나는 주로 명시 적 subtyping 을 사용하는 프로그래밍 언어를 사용했습니다 . 위의 참고에서 설명한대로 암시 적 하위 유형의 장점은 무엇입니까?

pl.programming-languages type-theory

FAQ에서이 교환의 범위에 대해 : "이 분야에서의 작업은 종종 수학적 기술과 엄격함에 대한 강조로 구별됩니다." 이 질문에 대한 답변에서 엄격한 범위를 볼 수 없기 때문에 하향 조정입니다.

— David Eppstein

안타깝게도이 질문에 답하는 데있어 처음에 기대했던 것보다 훨씬 더 많은 범위가 있습니다. 많은 저명한 사람들이 90 년대의 레슬링을 많이 타서 서브 타이핑에 관한 사소한 질문을 던졌습니다. 불행히도 보상 노력 비율이 매우 낮은 영역입니다.

— Neel Krishnaswami

그렇습니다.이 질문에 답하는 데 수학과 엄격함이 많거나 최소한 암시적인 서브 타이핑 이 무엇인지 수학적으로 설명 할 수있는 여지가 많이 있습니다 . 보상 노력 비율에 대해 잘 모르겠습니다.

— Noam Zeilberger

나는 아마도 그것이 "매우 어렵다"고 말했을 것입니다.

— Neel Krishnaswami

나는 확신한다. downvote를 제거했지만 시스템에서 알려주지 않습니다.

— David Eppstein

답변:

짧은 대답은 "기존 코드의 추가 속성을 확인하는 것"입니다. 더 긴 대답은 다음과 같습니다.

"암시 적"대 "명시 적"이라는 용어가 좋은 용어인지 잘 모르겠습니다. 이 구분을 "구조적"대 "명 목적"하위 유형이라고도합니다. 그런 다음 구조적 서브 타이핑의 가능한 해석에 두 번째 차이점이 있습니다 (곧 설명). 서브 타이핑에 대한 세 가지 해석은 모두 직교이므로 각각의 사용법을 이해하기보다는 서로 비교하는 것이 의미가 없습니다.

구조적 서브 타이핑 관계 A <: B를 해석 할 때의 주요 운영상의 차이점은 (런타임 / 컴파일 타임) 계산 내용으로 실제 강요에 의해 목격되는지 또는 동일성 강요에 의해 목격 될 수 있는지 여부입니다. 전자의 경우 중요한 이론적 속성이 "일관성"인 경우, 즉 A가 B의 하위 구조적 하위 유형임을 나타내는 여러 가지 방법이있는 경우, 수반되는 각 강제 변환은 동일한 계산 내용을 가져야합니다.

당신이 준 링크는 구조적 서브 타입의 두 번째 해석을 염두에 둔 것으로 보입니다. 여기서 A <: B는 정체성 강요에 의해 목격 될 수 있습니다. 이것을 서브 타이핑의 "서브 세트 해석"이라고도하며, 타입이 값 세트를 나타낸다는 순진한 견해를 취하기 때문에 A <: B는 A 타입의 모든 값이 B 타입의 값일 경우를 대비합니다. "refinement typing"이라고도하며 원래 동기 부여를위한 좋은 논문 은 ML에 대한 Freeman & Pfenning의 Refinement 유형입니다 . F #의 최신 화신에 대해서는 안전한 구현을위한 Bengston et al, Refinement 유형을 읽을 수 있습니다.. 기본 개념은 이미 유형을 가지고 있거나 그렇지 않을 수도 있지만 유형이 그다지 많은 것을 보장하지 않는 (예를 들어, 메모리 안전성 만) 존재하는 기존 프로그래밍 언어를 사용하여 프로그램의 하위 집합을 선택하는 두 번째 유형의 계층을 고려하는 것입니다 더 정확한 추가 속성.

(이제 서브 타이핑에 대한이 해석의 수학적 이론은 여전히 이해해야 할만큼 잘 이해되지 않았으며, 아마도 그것의 사용이 예상만큼 널리 인식되지 않았기 때문일 것입니다. 한 가지 문제는 유형에 대한 해석이 너무 순진하기 때문에 때로는 세련되지 않고 포기되기도합니다. 하위 유형 지정에 대한 이러한 해석이 더 많은 수학적주의를 기울여야한다는 또 다른 주장 은 Abstract Stone Duality 의 Paul Taylor의 하위 공간 소개를 읽어보십시오 .)

— 노암 제이 버거
소스

A \times B \times C <: A \times B

$A \times B \times C <: A \times B$

C

$C$

A

$A$

B

$B$

최적의 메모리 레이아웃을 파악하는 것은 옵티마이 저의 작업이므로 ID 인 강제는 실제로 최적화의 결과 여야합니다.

— Andrej Bauer

구체화 타이핑 해석 에서 구체화 유형에 추가 계산 내용이 없으므로 하위 유형 관계는 정의 에 따라 항등식 관계에 의해 항상 목격됩니다 . 다시 말해, A와 B가 X 유형의 두 가지 구체화 ( "하위 집합"/ "속성") 인 경우 A <: B는 x : A이면 x : B 인 경우 X의 모든 값 x에 대해이를 주장합니다. 이러한 명령문은 확인 또는 위조 될 수 있지만 런타임에는 x : A 및 x : B가 존재하지 않는다는 증거이므로 런타임에는 영향을 미치지 않습니다.

— Noam Zeilberger

@Noam : 동의합니다. 그러나 우리가 단일 언어의 복리에 대해 이야기 할 때만 컴파일에 대해 이야기 할 때는 아닙니다. 정체성 강요는 많은 일을하는 절차에 의해 실현 될 수 있고, 비 식별 강요는 아무것도하지 않는 절차에 의해 실현 될 수 있습니다. 구체적으로, 우리가 타입 이라고 가정하자

N

$\mathbb{N}$

{x : N | x < 2^{32}}

$\{x:N\;\;|\;\;x < 2^{32}\}$

N

$N$

{x : N | x < 2^{32}}

$\{x:N | x < 2^{32}\}$

N

$N$

{x : N | x < 2^{32}}

$\{x:N | x < 2^{32}\}$

— Noam Zeilberger

이 답변은 Noam의 탁월한 답변에 대한 최소한의 보충입니다. 관심있는 데이터 포인트 중 하나는 C ++ 개념의 운명인데, 이는 유형의 명목 및 구조 개념을 통합하려는 시도를 바탕으로 설립되었습니다.

여기에 많은 관련 토론에 대한 링크가있는 훌륭한 글이 있습니다 : http://bartoszmilewski.wordpress.com/2010/06/24/c-concepts-a-postmortem/

그러나 위의 글에서 명목 대 구조적 문제에 대해 깊이 논의하지 않았습니다. 여기에 또 다른 글이 있습니다 : http://nerdland.net/2009/07/alas-concepts-we-hardly-knew-ye/

핵심 논문은 Bjarne Stroustrup의“개념 사용 단순화”( http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2906.pdf )입니다. 어느 정도 문제가 발생했습니다.

전체적으로 논의는 엄격한 것보다 실용적입니다. 그러나 특히 큰 기존 언어와 관련하여 이러한 문제와 관련된 종류의 장단점에 대한 통찰력을 제공합니다.

— sclv
소스