Design: call_indirect 대 추상화

자세한 글을 써주셔서 감사합니다, Ross! 작은 질문이 있습니다. " call_indirect 및 유형 가져오기" 섹션에 다음과 같이 작성합니다.

기술 1을 선호하는 경우 Typed Function References를 추가하면 다시 한 번 작동하지 않는다는 점을 알아두십시오.

이것은 또한 유형이 지정된 함수 참조에 변형 하위 유형을 추가한 후에만 문제가 존재한다는 이전 섹션의 경고의 대상입니까?

그렇지 않다. 하위 유형 섹션의 모든 문제는 유형 가져오기와 무관하고 유형 가져오기 섹션의 모든 문제는 하위 유형과 무관합니다. 귀하가 묻는 특정 문제와 관련하여 ref ([] -> [capability]) 유형의 값이 내보낸 함수에 의해 ref ([] -> [$handle]) 유형의 값으로 반환될 수 있음을 고려하십시오. funcref 및 간접적으로 호출됩니다. 내보낸 함수와 달리 이러한 관점에서의 값 변경은 링크 시간이 아닌 런타임에 발생하므로 함수 참조 자체를 가져온 적이 없기 때문에 가져오기 서명과 비교하여 이를 해결할 수 없습니다.

module instance IC defines a type capability and exports the type but not its definition as $handle
어떻게 작동합니까? capability 와 $handle 를 연결하는 무언가가 있어야 IC가 이를 처리하는 방법을 알 수 있습니다.
또한 https://github.com/WebAssembly/proposal-type-imports/blob/master/proposals/type-imports/Overview.md#exports 기반으로 가져온 유형은 완전히 추상적입니다. 따라서 $capability 를 내보내더라도 추상적입니다. 아마도 내가 뭔가를 오해하고 있는 것 같습니다.

module instance IC exports a function $do_stuff that was defined with type [capability] -> [] but exported with type [$handle] -> [] 수출에 대한 유사한 질문입니다.

여기에 사용되는 일종의 하위 유형 관계를 상상할 수 있습니다. 예를 들어 $capability <: $handle 이면 export $capability as $handle 할 수 있습니다. 하지만 이 섹션의 시작 부분에서 서브타이핑을 제쳐두라고 언급했기 때문에 그건 제쳐두고... 하지만 나는 또한 그것에 대해 조금 더 생각했습니다.
$capability <: $handle 이면 export $capability as $handle 할 수 있지만 export ([$capability] -> []) as ([$handle] -> []) 는 인수에서 반공변(contravariant) 함수이기 때문에 "실패"해야 합니다.

유형 내보내기를 사용하여 모듈은 type $handle; func $do_stuff_export : [$handle] -> [] 와 같은 서명을 지정한 다음 type $handle := capability; func $do_stuff_export := $do_stuff 와 같은 서명을 인스턴스화합니다. (특정 구문을 완전히 무시하십시오.) 그런 다음 유형 검사기는 " $handle capability 가 이 모듈에서 func $do_stuff_export := $do_stuff 내보내기가 유효한가요?"를 확인합니다. $do_stuff 의 유형이 [capability] -> [] 이므로 $handle 를 capability 인스턴스화한 후 서명은 $do_stuff_export 의 유형과 정확히 일치합니다. 확인 성공. (여기에는 하위 유형이 포함되지 않고 변수 대체만 있습니다.)

그러나 서명 자체는 $handle 대해 아무 것도 말하지 않습니다. 이것은 다른 모든 사람들이 $handle 를 추상 유형으로 취급해야 한다는 것을 의미합니다. 즉, 서명은 의도적으로 모듈 구현의 세부 사항을 추상화하고 다른 모든 사람은 해당 추상화를 존중해야 합니다. 이 문제의 목적은 call_indirect 를 사용하여 해당 추상화를 우회할 수 있음을 설명하는 것입니다.

문제가 조금 해결되기를 바랍니다!

덕분에 상황이 명확해졌습니다. 하위 입력 섹션에 대해 질문이 있습니다(이동하여 죄송합니다).

저는 call_indirect "정의 서명이 아닌 가져오기 서명과 비교"하도록 하여 call_indirect[ -> tsuper](ref.func($fsuper)) 를 실행하는 IB가 성공하기를 원하는 시나리오를 따르고 있습니다.

그리고 당신은 (유형화된 함수 참조로 인해) 우리도 필요하다고 추가했습니다.

1. 예상 서명과 정의 서명의 하위 유형 호환성에 대해 최소 선형 시간 런타임 검사를 수행합니다.

이것이 "예상 서명과 가져오기 서명 " 간의 호환성이어야 합니까? call_indirect가 가져오기 서명을 예상 서명과 비교하도록 만들었다고 가정하기 때문에.

예상된 것과 가져오기 간에 호환성이 확인되면 나중에 call_indirect[ -> tsub]($fsuper) 가 실패합니다.

기술 1과 2는 간접 호출을 작동시키는 두 가지 직교 방법으로 제공됩니다. 불행히도 기술 1은 형식화된 함수 참조와 호환되지 않으며 기술 2는 너무 비쌀 수 있습니다. 따라서 이들 중 어느 것도 해결되지 않을 것 같습니다. 따라서 섹션의 나머지 부분에서는 이들 중 어느 것도 사용하지 않고 예상 서명과 정의된 서명 간의 단순한 동등 비교만 고수하면 어떻게 되는지 고려합니다. 혼란을 드려 죄송합니다; 계획된 의미가 없다는 것은 내가 세 가지 잠재적 의미를 논의해야 한다는 것을 의미합니다.

너무 많은 결론을 내리지 않도록 주의하십시오. ;)

내 가정은 call_indirect 가 오늘날처럼 빠르게 유지되어야 하므로 언어에 얼마나 많은 하위 유형을 추가하더라도 유형 동등성 테스트만 필요하다는 것입니다. 동시에 런타임 검사는 정적 유형 시스템과 일관성이 있어야 합니다. 즉, 하위 유형 지정 관계를 존중해야 합니다.

이제 call_indirect 와 함께 사용할 수 있는 유형이 항상 하위 유형 계층 구조의 리프에 있는지 확인하는 한 이러한 겉보기에 상충되는 요구 사항은 실제로 상당히 쉽게 조정될 수 있습니다.

이를 시행하는 한 가지 확립된 방법은 _exact_ 유형의 개념을 유형 시스템에 도입하는 것입니다. 정확한 유형에는 하위 유형이 없고 상위 유형만 있으며 (exact T) <: T 있습니다.

이를 통해 call_indirect 의 대상 유형이 정확한 유형이 되도록 요구할 수 있습니다. 또한, 함수 자체의 유형은 이미 해당 함수의 정확한 유형입니다.

모듈은 의도한 런타임 검사에 성공한 함수로만 인스턴스화할 수 있도록 하려는 경우 함수 가져오기에 정확한 유형을 요구할 수도 있습니다.

이것이 정규화된 함수 유형에 대한 간단한 포인터 비교의 현재 구현 기술이 유효한지 확인하는 데 필요한 전부입니다. 다른 하위 유형이 무엇인지 또는 함수 하위 유형을 얼마나 멋지게 만드는지와는 무관합니다. (FWIW, 나는 얼마 전에 이것을 Luke와 논의했고 PR을 만들 계획이었지만, subtyping 스토리에 대한 보류 중인 변경 사항과 현재 이동하는 제안으로 인해 차단되었습니다.)

(한 가지 단점은 함수 정의를 하위 유형으로 구체화하는 것이 일반적으로 더 이상 이전 버전과 호환되는 변경이 아니라는 것입니다. 적어도 정확한 유형이 어디에서나 사용된 경우에는 그렇지 않습니다. 그러나 그 단점은 우리가 얼마나 정확하게 적용하는지에 관계없이 우리의 제약 조건에서 피할 수 없습니다. 그들을.)

몇 가지 측면:

대안은 call_indirect 및 func.ref를 그대로 두는 것입니다.

AFAICS, 참조 유형을 포함하는 함수에서 ref.func를 허용하지 않는 것은 실현 가능하지 않습니다. 이는 많은 사용 사례, 즉 externref (콜백, 후크 등)에서 작동하는 일류 함수와 관련된 모든 것을 심각하게 손상시킵니다.

이것은 우리가 도달한 솔루션에 따라 실제 유형 가져오기와 같이 externref가 인스턴스화할 수 없거나 externref가 (아이러니하게도) 어떤 상위 유형도 가질 수 없다는 것을 의미할 수 있습니다(예: 결국 anyref를 추가하기로 결정하면 anyref의 하위 유형이 될 수 있음).

자세히 설명해 주시겠습니까? 연결이 안 보이네요.

너무 많은 결론을 내리지 않도록 주의하십시오. ;)

어떤 결론을 말씀하시는지 모르겠습니다. 내가 언급한 결론은 call_indirect 대해 우리가 인지해야 하고 계획을 시작해야 하는 많은 문제가 있다는 것입니다. 당신은 해결책을 염두에 두고 있기 때문에 이러한 문제가 중요하지 않다고 제안하는 것 같습니다. 그러나 해당 솔루션은 CG에서 검토하거나 승인하지 않았으므로 검토가 완료될 때까지 계획을 세워서는 안 됩니다. 솔루션을 평가하고 비교하는 데 시간이 걸리고 이러한 평가와 비교를 적절하게 수행할 시간이 있기 전에 결정을 내려야 하기 때문에 솔루션에 대해 논의하지 않기를 특별히 요청했습니다. 그러나 사람들이 이 문제가 해결되었다는 인식을 형성하고 결과적으로 긴급한 결정을 피하기 위해 잠시 시간을 내어 귀하의 솔루션에 대해 신속하게 논의하겠습니다.

이를 시행하는 확립된 방법 중 하나는 정확한 유형의 개념을 유형 시스템에 도입하는 것입니다.

정확한 유형은 거의 확립된 솔루션이 아닙니다. 어떤 것이든 정확한 유형은 그 지지자들이 여전히 해결하기 위해 노력하고 있는 문제를 설정했습니다. 흥미롭게도 여기 에 TypeScript 팀이 원래 제안하는 양식의 정확한 유형이 몇 가지 문제를 해결할 수 있는 방법을 보았지만 결국 [실현](https://github.com/microsoft/TypeScript/issues/12936)한 스레드가 있습니다. #issuecomment-284590083) 정확한 유형은 해결한 것보다 더 많은 문제를 야기했습니다. (상황에 대한 참고 사항: Flow의 정확한 객체 유형에 의해 논의가 촉발되었습니다. 이

이러한 종류의 문제가 WebAssembly에서 어떻게 발생할 수 있는지에 대한 예로, 하위 유형 지정을 연기하지 않았다고 가정합니다. ref.null 의 유형은 정확한 유형을 사용하는 exact nullref 입니다. 그러나 exact nullref 는 exact anyref 의 하위 유형이 아닙니다. 사실, 정확한 유형의 일반적인 의미론에 따르면 값의 런타임 유형이 정확히 anyref 가 아닐 가능성이 높기 때문에 exact anyref 에 속하는 값은 없을 것입니다. 이것은 anyref s에 대해 call_indirect 완전히 사용할 수 없게 만듭니다.

이제 정확한 유형의 다른 버전을 염두에 두고 있을 수 있지만 이 다른 버전이 정확한 유형과 관련된 많은 미해결 문제를 어떻게든 해결하는지 확인하는 데 시간이 걸릴 것입니다. 여기 내 요점은이 솔루션을 던져하지만이 솔루션이며, 그 기대와 의사 결정을하지 분명 아니라고 인식되지 않도록.

자세히 설명해 주시겠습니까? 연결이 안 보이네요.

긴 문장을 언급하고 있습니다. 어떤 부분에 대해 자세히 설명해 주시겠습니까? 한 가지 추측은 call_indirect 및 유형 가져오기에 대한 전반적인 문제를 놓치고 있을 수 있다는 것입니다. 귀하의 정확한 유형 제안은 하위 입력 문제만 해결하지만, 위에서 call_indirect 하위 입력이 없어도 문제가 있음을 확인했습니다.

이는 많은 사용 사례, 즉 externref (콜백, 후크 등)에서 작동하는 일급 함수와 관련된 모든 것을 심각하게 손상시킬 것입니다.

예, 이것은 내가 더 많은 정보를 얻고자 했던 것입니다. 내 이해는 call_indirect 의 주요 사용 사례는 C/C++ 함수 포인터와 C++ 가상 메서드를 지원하는 것입니다. 또한 이 사용 사례는 현재 숫자 서명으로 제한되어 있음을 이해합니다. call_indirect 의 더 많은 잠재적인 용도를 알고 있지만 언급했듯이 임시 제한을 제안한 것이므로 call_indirect 의 현재 용도가 무엇인지가 중요합니다. call_indirect 가 단순히 funcref 아닌 테이블과 인덱스가 여전히 필요하다는 점을 감안할 때 콜백 지원을 위해 특별히 잘 설계된 것 같지 않습니다. 현재 는 이 용도로 사용하고 있지 않기 때문인지 모르겠습니다.

여러분 모두는 이 기능을 대상으로 하는 코드 기반을 저보다 훨씬 잘 알고 있으므로 지금 이 기능이 필요한 실제 프로그램을 알고 있다면 여기에 필요한 사용 패턴의 몇 가지 예를 제공하는 것이 매우 도움이 될 것입니다. 지금 이 기능을 지원해야 하는지 여부를 파악하는 데 유용할 뿐만 아니라 기능이 지금 필요한 경우 이러한 예제는 위의 문제를 해결하면서 신속하게 제공하는 최선의 방법을 알려주는 데 도움이 될 것입니다.

@RossTate :

어떤 것이든 정확한 유형은 그 지지자들이 여전히 해결하기 위해 노력하고 있는 문제를 설정했습니다. 흥미롭게도 여기에 TypeScript 팀이 원래 제안하는 양식의 정확한 유형이 일부 문제를 해결할 수 있는 방법을 보았지만 결국 정확한 유형이 해결한 것보다 더 많은 문제를 야기한다는 것을 깨달았던 스레드가 있습니다. (맥락에 대한 참고 사항: Flow의 정확한 객체 유형에 의해 논의가 촉발되었습니다. 이 유형은 실제로 정확한 유형의 형태가 아니라(이론적 의미에서) 접두사 하위 유형 지정의 객체 아날로그를 허용하지 않습니다.) 우리가 해당 스레드를 재생하는 것을 상상할 수 있습니다. 여기.

여기에서 괄호가 핵심입니다. 그들이 그 스레드에서 정확히 무엇을 염두에 두고 있는지는 모르겠지만 같은 것은 아닌 것 같습니다. 그렇지 않으면 " T & U 유형은 항상 T 할당할 수 있다고 가정하지만 T 가 정확한 유형이면 실패합니다"와 같은 문장은 의미가 없습니다. T & U 가 유효하지 않거나 맨 아래에 있으므로 실패합니다. 다른 질문은 주로 화용론에 관한 것입니다. 예를 들어 프로그래머가 어디에서 (객체에 대해) 그것들을 사용하기를 원할까요? 우리의 경우에는 적용되지 않습니다.

저수준 유형 시스템의 경우, 귀하의 일부 논문에서도 정확한 유형이 중요한 요소가 아니었나요?

이러한 종류의 문제가 WebAssembly에서 어떻게 발생할 수 있는지에 대한 예로, 하위 유형 지정을 연기하지 않았다고 가정합니다. ref.null의 유형은 정확한 유형을 사용하는 정확한 nullref입니다. 그러나 정확한 nullref는 정확한 anyref의 하위 유형이 아닙니다.

여기에는 이견이 없습니다. 하위 유형이 없는 것이 정확한 유형의 목적입니다.

사실, 정확한 유형의 일반적인 의미론에 따르면 값의 런타임 유형이 정확히 anyref가 아닐 가능성이 높기 때문에 정확한 anyref에 속하는 값이 없을 가능성이 높습니다.

네, (exact anyref) 조합은 anyref의 유일한 목적이 상위 유형이 되는 것이므로 유용한 유형이 아닙니다. 근데 그게 왜 문제야?

이것은 call_indirect를 anyref에 대해 완전히 사용할 수 없게 만듭니다.

당신은 지금 혼란스러운 수준이 아니라고 확신합니까? (exact (func ... -> anyref)) 함수 유형은 완벽하게 유용합니다. (func ... -> (ref $T)) 와 같은 유형과 호환되지 않습니다. 즉, exact 는 함수 유형에 대한 사소한 하위 입력을 방지합니다. 그러나 그것이 요점입니다!

(exact (func ... -> anyref)) 와 (func ... -> exact anyref) ? 이들은 관련이 없는 유형입니다.

귀하의 정확한 유형 제안은 하위 유형의 문제만 해결하지만 위에서 call_indirect는 하위 유형이 없어도 문제가 있음을 확인했습니다.

추상 데이터 유형을 정의하는 수단으로 정의 없이 유형을 내보낼 수 있다고 어떻게든 가정하고 있습니다. 분명히 그 접근 방식은 동적 유형 캐스트(call_indirect 또는 기타)가 있는 경우 작동하지 않습니다. 그렇기 때문에 ML 스타일 유형 추상화가 아니라 newtype 스타일 유형 추상화가 필요하다고 계속 말하는 이유입니다.

내 이해는 call_indirect의 주요 사용 사례는 C/C++ 함수 포인터를 지원하는 것입니다

예, 하지만 이것이 제가 언급한 ref.func 의 유일한 사용 사례가 아닙니다. 제안한 제한 사항에 포함했기 때문입니다(불필요하게 그럴 수도 있습니까?). 특히 유형 검사를 포함하지 않는 call_ref 가 있습니다.

추상 데이터 유형을 정의하는 수단으로 정의 없이 유형을 내보낼 수 있다고 어떻게든 가정하고 있습니다. 분명히 그 접근 방식은 동적 유형 캐스트(call_indirect 또는 기타)가 있는 경우 작동하지 않습니다. 그렇기 때문에 ML 스타일 유형 추상화가 아니라 newtype 스타일 유형 추상화가 필요하다고 계속 말하는 이유입니다.

좋습니다. call_indirect 및 유형 가져오기 문제를 해결하기 위해 정확한 유형은 아무 것도 하지 않는다는 데 동의하는 것 같습니다. 그러나 런타임 캐스트로 인해 어쨌든 문제가 될 것이기 때문에 해당 문제를 해결할 의미가 없다고 말씀하셨습니다. 이 문제를 방지하는 쉬운 방법이 있습니다. 사람들이 추상 유형에 대해 런타임 캐스트를 수행하도록 허용하지 마십시오(추상 유형이 명시적으로 캐스트 가능하다고 명시하지 않는 한). 결국, 그것은 불투명한 유형이므로 우리는 그것이 캐스트를 수행하는 데 필요한 구조를 나타낸다고 가정할 수 없습니다. 따라서 정확한 유형이 하위 유형 문제를 해결할 가능성이 있더라도 문제의 나머지 절반을 무시하는 것은 시기상조입니다.

내가 말했듯이 모든 솔루션에는 장단점이 있습니다. 귀하는 귀하의 솔루션에 귀하가 식별한 장단점만 있다고 가정하고 CG가 다른 솔루션보다 귀하의 솔루션을 선호할 것이라고 가정하는 것 같습니다. 나 역시 이 문제에 대한 잠재적인 해결책이 있습니다. 상시 점검을 보장하고, 이미 가상 머신에서 사용되는 기술을 기반으로 하며, 여기에서 모든 문제를 해결하고(내 생각에), 새로운 유형을 추가할 필요가 없으며, 실제로 알려진 애플리케이션을 사용하여 WebAssembly에 추가 기능을 추가합니다. 그러나 나는 그것이 내가 예상한 대로 작동하고 당신과 다른 사람들이 그것을 살펴볼 기회가 없었기 때문에 내가 몇 가지 결점을 간과하지 않았다고 추정하지 않습니다. 나는 또한 CG가 대체 옵션보다 트레이드오프를 선호할 것이라고 가정하지 않습니다. 그 대신, 저뿐만 아니라 CG가 이 교차 주제에 대해 정보에 입각한 결정을 내릴 수 있도록 옵션을 분석할 시간을 주기 위해 우리가 무엇을 할 수 있는지 알아내려고 노력하고 있습니다.

특히 유형 검사를 포함하지 않는 call_ref 가 있습니다.

문장의 핵심 단어는 will 입니다. 나는 사람들이 지원하기 를 원하는 숫자가 아닌 유형의 call_indirect 응용 프로그램이 있다는 것을 완전히 알고 있습니다. 그리고 나는 우리 가 그 기능을 지원하고 위의 문제를 해결하는 디자인을 내놓을 것이라고 기대합니다. 그러나 내가 말했듯이 이상적으로는 우리가 이러한 의미를 조사할 기회를 갖기 전에 크로스-컷팅 의미가 있는 기능을 신속하게 출시하지 않도록 해당 디자인을 개발할 시간을 가질 수 있습니다. 그래서 제 질문 은 지금 그 기능 을 필요 로 하는 주요 프로그램 이 있다는 것입 니다 . 있다면 가정할 필요가 없습니다. 일부를 가리키고 현재 이 기능에 어떻게 의존하는지 설명하십시오.

추상 데이터 유형을 정의하는 수단으로 정의 없이 유형을 내보낼 수 있다고 어떻게든 가정하고 있습니다. 분명히 그 접근 방식은 동적 유형 캐스트(call_indirect 또는 기타)가 있는 경우 작동하지 않습니다. 그렇기 때문에 ML 스타일 유형 추상화가 아니라 newtype 스타일 유형 추상화가 필요하다고 계속 말하는 이유입니다.

이것은 나에게 근본적인 문제처럼 보입니다. 내보낸 유형 정의의 기밀성을 활성화하는 것이 유형 가져오기 제안의 목표입니까? 이 스레드에서 @RossTate 는 목표가 되어야 한다고 생각하고 @rossberg 는 현재 목표가

@RossTate :

좋습니다. 따라서 정확한 유형은 call_indirect 및 유형 가져오기 문제를 해결하는 데 아무 것도 하지 않는다는 데 동의하는 것 같습니다.

예, 추상 데이터 유형을 정의하기 위한 기능을 추가하는 방법에 대한 질문을 의미한다면 그렇습니다. 유형 추상화가 일관되게 작동하는 방법에는 여러 가지가 있지만 그러한 기능은 더 나아가야 합니다.

당신의 문장의 핵심 단어는 의지입니다. 사람들이 지원하기를 원하는 숫자가 아닌 유형의 call_indirect 애플리케이션이 있다는 것을 충분히 알고 있습니다.

call_ref 명령어는 함수 ref 제안에 있으므로 어떤 경우에도 잠재적인 추상 데이터 유형 메커니즘 이전에 매우 가깝습니다. 그때까지 보류하자는 건가요?

@tlively :

내보낸 유형 정의의 기밀성을 활성화하는 것이 유형 가져오기 제안의 목표입니까? 이 스레드에서 @RossTate 는 목표가 되어야 한다고 생각하고 @rossberg 는 현재 목표가

목표이지만 추상 데이터 유형 메커니즘은 별도의 기능입니다. 그리고 이러한 메커니즘은 수입품의 설계에 영향을 미치지 않도록 설계되어야 합니다. 만약 그렇다면, 우리는 그것을 매우 잘못하고 있을 것입니다. 추상화는 사용 사이트가 아니라 정의 사이트에서 보장되어야 합니다. 그러나 다행스럽게도 이것은 로켓 과학이 아니며 디자인 공간은 상당히 잘 알려져 있습니다.

감사합니다, @rossberg , 그것은 의미가 있습니다. 유형 가져오기 및 내보내기 후에 후속 제안에 추상화 기본요소를 추가하는 것이 나에게는 괜찮게 들릴지 모르지만, 우리가 그것을 어디선가 곧 할 계획에 대한 세부사항을 기록할 수 있다면 좋을 것입니다. 유형 가져오기 및 내보내기의 디자인은 추상 유형 가져오기 및 내보내기의 디자인을 제한하고 정보를 제공하므로 초기 디자인을 완료하기 전에 추상화가 향후 어떻게 작동할지에 대한 좋은 아이디어를 갖는 것이 중요합니다.

그 계획을 자세히 설명하는 것 외에도 call_indirect 에 대한 이 문제는 긴급한 결정에 영향을 미친다는 것을 보여주므로 추상 유형을 캐스팅할 수 없도록 명시적으로 제한하지 않는 한 내 제안을 거부하는 것처럼 보이는 이유를 설명할 수 있습니까? )? 그것들은 불투명하므로 제안은 추상 유형의 일반적인 관행과 일치하는 것처럼 보입니다.

@tlively 네, 동의합니다. 그외에 제가 잠시 쓰려고 했던 다양한 다른 것들. #69 의 모든 낙진을 해결한 후에 할 것입니다. ;)

@RossTate , 추상 데이터 유형이 캐스트와 호환되지 않기 때문입니다. 다른 사람들이 추상 유형을 _통해_ 볼 수 없도록 하고 싶다고 해서 그들(또는 나 자신)이 추상 유형을 _변환하지 못하도록 막고 싶은 것은 아닙니다. 이러한 잘못된 이분법을 만드는 것은 캐스트의 중심 사용 사례를 깨뜨릴 것입니다. 예를 들어, 물론 추상 유형의 값을 다형성 함수에 전달할 수 있기를 원합니다.

@rossberg 염두에 두고 있는 이 중앙 사용 사례가 무엇인지 명확히

@RossTate , 다형성 함수를 고려하십시오. Wasm-generics가 부족하면 anyref에서 up/down 캐스트를 사용하여 컴파일할 때 다른 객체로 추가 래핑하지 않고도 다른 것과 마찬가지로 추상 유형의 값과 함께 사용할 수 있어야 합니다. 일반적으로 다른 것과 마찬가지로 추상 유형의 값을 처리할 수 있기를 원합니다.

자, 다형성 함수를 고려하고 가져온 유형이 Handle 라고 가정해 보겠습니다.

1. Java에는 다형성 기능이 있습니다. 다형성 함수는 모든(Java 참조) 값이 객체일 것으로 예상합니다. 특히 v-table이 있어야 합니다. Handle을 사용하는 Java 모듈은 인터페이스를 구현하는 Java 클래스 CHandle 지정할 가능성이 높습니다. 이 클래스의 인스턴스에는 Handle 유형의 (wasm 수준) 멤버와 다양한 클래스 및 인터페이스 메서드 구현에 대한 함수 포인터를 제공하는 v-테이블이 있습니다. wasm 수준에서 객체에 대한 함수일 뿐인 표면 수준 다형성 함수에 제공되면 모듈은 CHandle 로 캐스팅하기 위해 다른 클래스로 캐스팅하는 데 사용하는 것과 동일한 메커니즘을 사용할 수 있습니다.
2. OCaml에는 다형성 기능이 있습니다. 그것의 다형성 함수는 모든 OCaml 값이 물리적 평등을 지원하기를 기대합니다. wasm은 OCaml의 유형 안전성에 대해 추론할 수 없기 때문에 다형성 기능도 캐스트를 많이 사용해야 할 것입니다. 특수 주조 구조를 사용하면 이를 보다 효율적으로 만들 수 있습니다. 이러한 이유 중 하나 때문에 OCaml 모듈은 이러한 규범에 적합하고 Handle 유형의 (wasm 수준) 멤버가 있는 대수 데이터 유형 또는 레코드 유형 THandle 을 지정할 수 있습니다. 다형성 함수는 다른 대수 데이터 유형이나 레코드 유형과 마찬가지로 OCaml 값을 THandle 합니다.

즉, 모듈은 다형성 함수와 같은 것을 구현하기 위해 표면 수준 값이 표현되는 방식에 대한 규범에 의존하고 Handle과 같은 추상 가져오기 형식은 이러한 규범을 충족하지 않기 때문에 값의 래핑이 불가피합니다. 이것은 anyref 에 대한 원래 응용 프로그램 중 하나가 인터페이스 유형으로 대체된 것과 같은 이유입니다. 그리고 우리는 anyref 가 다형성 기능을 지원하는 데 필요하지도 않고 적절하지도 않다는 것을 보여주는 사례 연구 를 개발했습니다.

반면에 정적 추상화 메커니즘을 우회하는 데 캐스팅 가능한 anyref 사용할 수 있음을 보여주었습니다. 당신이 언급한 추상화 메커니즘 계획은 동적 추상화 메커니즘을 통해 이 문제를 패치하려는 시도입니다. 그러나 동적 추상화 메커니즘에는 많은 문제가 있습니다. 예를 들어, anyref 하고 핸들을 위조하기 위해 캐스팅(예: 기능)하는 다른 모듈의 위험 없이 i31ref 유형을 추상 Handle 유형으로 내보낼 수 없습니다. 대신에 표준 정적 추상화만 보장했다면 불필요한 추가 고리와 오버헤드를 건너뛰어야 합니다.

또한 (내 생각에) 정확한 유형을 사용하려는 방법을 더 잘 이해했기 때문에 call_indirect 및 하위 유형으로 주의를 환기시킨 두 가지 주요 문제 중 어느 것도 귀하의 의도가 해결되지 않는다는 것을 깨달았습니다.

1. call_indirect 서브타이핑을 존중하도록 하는 데 도움이 되지 않습니다(이미 명시적으로 말한 것 같습니다).
2. 내보낸 서명이 아닌 정의된 서명이 있는 내보낸 함수를 사용하는 데 call_indirect 가 사용되는 것을 방지하지 않습니다.

따라서 이것은 간단히 해결할 수 있는 문제가 아닙니다. 그렇기 때문에 시간 제약이 있는 경우 문제를 적절하게 해결할 시간을 주는 방법을 평가하는 데 중점을 두는 것이 좋습니다. anyref 가 정적 추상화를 버릴 가치가 있는지 여부에 대해 먼저 논의할 필요가 없다고 생각합니다. 그것은 내가 일을 더 미루지 않기 위해 피하고 싶었던 일종의 큰 토론이었습니다.

반면에 정적 추상화 메커니즘을 우회하는 데 캐스팅 가능한 anyref를 사용할 수 있음을 시연했습니다.

동적 유형 캐스트가 있는 언어에서는 정적 유형 추상화가 충분하지 않습니다. 정적 추상화는 매개변수에 의존하고 캐스트는 이를 깨기 때문입니다. 그것에 대해 새로운 것은 없으며 그것에 대해 문서가 작성되었습니다. 이러한 컨텍스트에서는 다른 추상화 메커니즘이 필요합니다.

추상 유형의 사용을 제한하여 이 문제를 해결하려고 하면 목적이 무효화됩니다. WASI 사용 사례를 고려하십시오. WASI 모듈과 WASI 모듈이 내보내는 모든 유형이 호스트에 의해 구현되는지 또는 Wasm에서 구현되는지는 중요하지 않습니다. 사용자 정의 추상 유형을 임의로 제한하면 Wasm 구현은 일반적으로 호스트 구현과 더 이상 호환되지 않습니다.

1. call_indirect가 하위 유형을 존중하도록 만드는 데 도움이 되지 않습니다(이미 명시적으로 말한 것 같습니다).

뭐? 정의에 따라 하위 유형 지정 규칙의 일부입니다.

1. 내보낸 서명이 아닌 정의된 서명이 있는 내보낸 함수를 사용하는 데 call_indirect가 사용되는 것을 방지하지 않습니다.

했다고 말하지 않았습니다. 나는 이것이 call_indirect 자체의 문제가 아니라 캐스트가 있는 언어에 적합한 유형 추상화 메커니즘을 선택하는 문제라고 말했습니다.

제쳐두고, OCaml(또는 유사한 언어)을 컴파일할 때 변형 유형을 도입해야 하는 설득력 있는 이유는 없습니다. 그것이 이론상 약간 더 빠를 수 있다 하더라도(현재 세대 엔진의 경우는 의심스럽습니다. 그 반대일 가능성이 더 높음), 변형 유형은 MVP에 필요하지 않아야 하는 중요한 합병증입니다. 나는 당신의 조기 복잡성에 대한 욕구에 동의하지 않습니다. ;)

함수에 대한 동등성: Haskell 또는 SML과 같은 언어가 이를 지원하지 않으므로 func refs의 직접적인 이점을 얻을 수 있습니다. OCaml은 구조적 평등을 위해 던지고 물리적인 것에 대한 구현 정의 동작을 명시적으로 가지고 있습니다. 항상 false를 반환하거나 함수에 대해 throw하는 것을 허용하는지 여부는 열려 있지만 실제로는 충분할 수 있으며 값비싼 추가 래핑을 커밋하기 전에 탐색할 가치가 있습니다.

[메타 논평으로서, 나는 당신이 당신의 강의의 톤을 낮추고 아마도 이것이 아마도 유능한 사람들의 집합이 싱글 톤이 아니며 이전에 때때로 두뇌의 흔적이 적용된 세계라는 아이디어를 고려했다면 정말 감사하겠습니다.]

메타 댓글로서 강의를 좀 자제해 주시면 감사하겠습니다.

들었다.

그리고 아마도 이것은 유능한 사람들의 집합이 싱글톤이 아니고 두뇌의 흔적이 이전에 때때로 적용되었던 세계라는 생각을 고려했을 것입니다.

제 조언은 여러 전문가와의 상담을 기반으로 합니다.

동적 유형 캐스트가 있는 언어에서는 정적 유형 추상화가 충분하지 않습니다. 정적 추상화는 매개변수에 의존하고 캐스트는 이를 깨기 때문입니다. 그것에 대해 새로운 것은 없으며 그것에 대해 문서가 작성되었습니다. 이러한 컨텍스트에서는 다른 추상화 메커니즘이 필요합니다.

내가 상담한 이 전문가들은 일부 논문의 저자를 포함합니다.

이제 내가 그들의 조언을 올바르게 합성했는지 확인하기 위해 이전에 이 주제에 대해 논의한 적이 없는 일부 해당 논문의 다른 저자에게 이메일을 보냈습니다. 제가 질문한 내용은 다음과 같습니다.

다형성 함수 f가 있다고 가정합니다.(...). 내 입력 언어에는 (가정) 하위 유형 지정 및 명시적 캐스팅이 있습니다. 그러나 t1에서 t2로의 캐스트는 t2가 t1의 하위 유형인지 여부만 확인합니다. 기본적으로 X와 같은 유형 변수에 하위 유형이나 상위 유형이 없다고 가정합니다(물론 자체 제외). f가 X에 대해 관계적으로 모수적이라고 예상하시겠습니까?

그들의 응답은 다음과 같습니다.

예, 이것이 제공하는 유일한 기능은 이미 관계적으로 매개변수인 항등 함수와 동일한 X에 캐스트를 작성하는 것이기 때문에 이것이 매개변수라고 생각합니다.

이것은 내 조언과 일치합니다. 물론 이것은 당면한 문제의 단순화이지만 WebAssembly에 대해 보다 구체적으로 문제를 조사하기 위해 노력했으며 지금까지 우리의 탐색은 이러한 기대가 WebAssembly 규모에서도 계속 유지된다고 제안했습니다. call_indirect 제외하고 이 문제가 발생합니다.

언급하고 있는 정리는 모든 값을 캐스팅할 수 있는 언어에 적용됩니다. 이 관찰은 캐스팅 가능성을 제한하는 아이디어를 얻은 곳입니다.

WASI 사용 사례를 고려하십시오.

나는 당신이 주장하는 것을 이해하지 못합니다. 우리는 WASI 사용 사례를 고려했습니다. 우리는 보안 및 특히 기능 기반 보안 분야의 여러 전문가를 포함합니다.

메타 의견으로서 권위자나 CG에 호소하여 내 제안을 들어줄 필요가 없다는 점에 정말 감사드립니다. 캐스트를 제한하면 캐스트가 있는 경우에도 정적 매개변수성을 보장할 수 있다고 제안했습니다. 당신은 즉시 그 제안을 무시하고 해고를 정당화하기 위해 이전 문서에 호소했습니다. 그러나 내가 그 논문의 저자에게 동일한 제안을 했을 때 그들은 즉시 나와 당신이 할 수 있었던 것과 같은 결론에 도달했습니다. 그 전에는 잠재적인 솔루션을 평가하는 것이 긴 과정이 될 것이라고 제안했습니다. 당신은 그 제안을 무시하고 당신이 (당신 스스로) 문제를 해결했다고 주장하여 우리 둘을 이 긴 대화로 끌어들였습니다. 한 사람의 제안이 너무 무심코 반복적으로 묵살되면 진전을 이루고 좌절하지 않기가 매우 어렵습니다. (여기서 귀하의 제안을 가능한 해결책으로 무시하려는 것이 아님을 분명히 해야 합니다. 저는 이것이 유일한 해결책이 아니므로 다양한 다른 사람들과 함께 평가되어야 함을 보여주려고 합니다.)

이 문제에서 제기된 문제를 해결하기 위해 세부적인 디자인을 정하고 면밀히 검토하는 것이 중요하고 시의적절하다고 생각합니다. 저는 실제로 추상 유형이 더 먼 기능으로 간주되어야 한다고 생각하지 않습니다. WASI는 지금 그것들이 필요합니다.

나는 또한 exact + newtype 가 문제를 해결할 수 있기를 희망하지만, 다음과 같은 경우 성급하게 설계에 전념함으로써 현 시점에서 농장에 단순히 이 직감에 베팅할 수 없다는 데 동의합니다. 우리는 (곧) 참조 유형을 배송합니다. 이에 대해 제대로 논의할 시간이 필요합니다.

즉, 참조 유형 제안에서 call_indirect 서명에 externref 를 허용하는 것이 위험하다고 생각하지 않습니다. 예, 모듈이 externref 값을 내보내는 경우(const 전역으로 또는 함수에서 반환하는 ...), 해당 externref 다운캐스트할 수 있는지 여부를 결정하지 않았습니다. 그러나 call_indirect 는 externref 다운캐스팅하지 않습니다. funcref 다운캐스팅하고 externref 는 funcref-type-equality 검사를 수행하는 i32 와 다른 역할을 합니다. 따라서 유형 가져오기, 유형 내보내기 및 call_indirect 에서 재생 중인 하위 입력이 없는 경우 MVP에서 아직 커밋하지 않은 새로운 디자인 선택을 어떻게 커밋하는지 알 수 없습니다. .

위험이 없다면 아마도 이 격렬한 토론을 Type Imports 제안에서 덜 집중적인 토론으로 줄일 수 있을 것입니다(여기서 나는 여전히 적절한 추상 유형 지원을 포함해야 한다고 생각합니다)?

확신하는. 위험요소가 있는지 없는지 살펴보는 것이 좋을 것 같아요.

WASI와 관련하여 디자인은 여전히 ​​유동적이지만 여전히 실행 가능한 것으로 보이는 한 가지 옵션은 동적 메모리 할당이 필요하지 않기 때문에 "핸들"에 i31ref 와 같은 것을 사용하는 것입니다. WASI는 다른 옵션을 결정할 수 있지만 요점은 현재로서는 아무도 모르며 지금 내리는 결정이 이러한 결정에 영향을 미치지 않는 것이 좋을 것입니다.

현재 externref 는 사용 가능한 유일한 추상 유형이므로 WASI 기반 호스트는 i31ref (또는 WASI "핸들"이 무엇이든)로 externref 를 인스턴스화합니다. 그러나 내 이해는 WASI가 호스트 종속 코드를 줄이기 위해 가능한 한 WebAssembly로 구현을 옮기고 싶어한다는 것입니다. 이를 용이하게 하기 위해 어느 시점에서 WASI 시스템은 externref 다른 유형 가져오기와 마찬가지로 취급하고 WASI의 추상 내보낸 Handle 유형으로 인스턴스화하기를 원할 수 있습니다. 그러나 Handle 가 i31ref 이면 모듈 경계를 넘어 작동하도록 하는 데 필요한 위의 call_indirect 구현을 사용하여 사람들이 externref 를 통해 핸들을 위조하도록 할 수도 있습니다.

그래서 제 질문 중 하나가 제 원래 게시물에 명확하게 명시되지 않았음을 알 수 있습니다. 사람들이 externref 를 다른 추상 유형 가져오기처럼 인스턴스화할 수 있기를 원합니까?

그래서 내 질문 중 하나는, 이제 내 원래 게시물에 명확하게 명시되지 않았으며, 사람들이 externref 를 다른 추상 유형 가져오기와 마찬가지로 인스턴스화할 수 있기를 원합니까?

이 질문을 명시적으로 제기해 주셔서 감사합니다. FWIW, externref 가 WebAssembly 모듈 내부에서 인스턴스화할 수 있다는 것을 이해한 적이 없습니다. 이는 WASI가 externref 를 핸들로 사용하려는 경우 가상화에 호스트 참여를 의미하지만, 나에게는 괜찮아 보이거나 최소한 분리 가능한 토론으로 보입니다.

흠, 내가 명확히 할 수 있는지 보자. 나는 당신이 이미 다음과 같은 많은 것을 이해하고 있다고 생각하지만 처음부터 시작하는 것이 더 쉽습니다.

wasm 모듈의 관점에서 externref 는 호스트 참조를 의미하지 않습니다. 모듈이 아무것도 모르는 불투명한 유형일 뿐입니다. 오히려 호스트 참조로 해석하는 것은 externref 주변의 규칙입니다. 예를 들어, externref 를 사용하여 DOM과 상호 작용하는 모듈의 규칙은 parentNode : [externref] -> [externref] 및 childNode : [externref, i32] -> [externref] 와 같이 모듈이 가져오는 externref 와 관련된 함수에서 분명합니다. childNode : [externref, i32] -> [externref] . 호스트 자체와 같은 모듈의 환경은 실제로 externref 의 해석을 호스트 참조로 제공하고 해당 해석을 확증하는 가져온 메소드의 구현을 제공합니다.

그러나, 모듈의 환경은 호스트로하지 않고 externref 호스트 참조 할 필요가 없습니다. 환경은 예상되는 규칙을 나타내는 호스트 참조처럼 보이는 일부 유형에 대한 기능을 제공하는 또 다른 모듈일 수 있습니다. 모듈 E가 모듈 M의 환경이고 그 모듈 M이 위와 같이 parentNode 및 childNode 를 가져왔다고 가정해 보겠습니다. E가 M 모듈을 사용하기를 원하지만 DOM에 대한 M의 액세스를 제한하기를 원한다고 가정해 봅시다. 예를 들어 E가 M을 제한적으로 신뢰하거나 E가 M이 가질 수 있는 버그를 제한하고 M의 요구가 이러한 제한을 초과해서는 안 된다는 것을 알고 있기 때문입니다. E가 할 수 있는 일은 M의 externref 로 "MonitoredRef"를 사용하여 M을 인스턴스화하는 것입니다. 특히 E가 M DOM 노드를 제공하려고 하지만 M이 DOM 트리 위로 올라가지 않도록 하려고 한다고 가정해 보겠습니다. 그러면 E의 MonitoredRef는 구체적으로 ref (struct externref externref) 일 수 있습니다. 여기서 두 번째 externref (E의 관점에서)는 M이 작동하는 DOM 노드이지만 첫 번째 externref 는 의 조상입니다. M이 지나갈 수 없는 노드입니다. 그런 다음 E는 M의 parentNode 를 인스턴스화하여 이 두 참조가 동일한 경우 오류가 발생하도록 할 수 있습니다. E 자체는 자체 parentNode 및 childNode 함수를 가져와서 E를 DOM 상호작용의 런타임 모니터로 효과적으로 만듭니다.

세부 사항에 대해 길을 잃기에는 너무 구체적이지 않으면서 올바른 그림을 그릴 수 있을 만큼 충분히 구체적이기를 바랍니다. 분명히 이와 같은 패턴이 많이 있습니다. 따라서 질문을 표현하는 또 다른 방법은 externref 가 정확히 호스트 참조만 나타내기를 원합니까?

나에게 의심스럽게 들리는 유일한 부분은 "E가 할 수 있는 일은 M의 externref 로 "MonitoredRef"를 사용하여 M을 인스턴스화하는 것입니다." 추상화하는 것을 다른 모듈에서 externref 로 표시하도록 허용할 계획이 있다는 인상을 받지는 않습니다. 내 이해는 externref 가 추상화 도구가 전혀 아니라는 것입니다.

나도 그런 계획을 모른다. 나는 또한 누군가가 옵션을 고려했는지 모르겠습니다. 즉, externref 는 i32 와 같은 "기본" 유형이어야 합니까, 아니면 가져온 유형과 같은 "인스턴스화 가능한" 유형이어야 합니까?

내 원래 게시물에서 어느 쪽이든 관리할 수 있다고 표시했습니다. "원시적" 해석으로 가는 절충안은 externref 가 가져온 유형보다 훨씬 덜 유용하거나 구성 가능하다는 것입니다. 후자는 externref 의 사용 사례와 위의 패턴을 지원하기 때문입니다. 따라서 "primitive" externref 는 이전 버전과의 호환성을 위해서만 존재하며 흔적이 남을 것 같습니다. 그러나 그것은 특별히 문제가 될 것 같지는 않으며 단지 성가신 일입니다. 내가 볼 수있는 가장 큰 문제는 단지의 잘 behavedness처럼, 즉 call_indirect 숫자 유형에 그들은 더 슈퍼 타입의 잘 behavedness이 없기 때문에 밖으로 작동 call_indirect 에 따라 끝낼 수 있습니다 externref 슈퍼타입도 없습니다.

아하, 예, 이것은 이해의 차이를 설명합니다. externref 가 전혀 추상적이지 않고 " externref 를 유형으로 인스턴스화"한다는 개념이 없다는 @tlively의 의견에 동의합니다. 우리는 앞으로 이것에 대해 꽤 확신할 수 있다고 생각합니다. ( externref 는 명시적으로 선언된 유형 매개변수와 달리 기본 유형이므로 모듈별로 인스턴스화를 시도하는 방법이 명확하지 않습니다.)

다운캐스트가 없는 경우 이 사실은 WASI API를 구현/가상화하는 데 wasm을 거의 쓸모가 없게 만듭니다. 이것이 WASI에 대한 계획이 i32 핸들에서 Type Imports로 직접 전환하는 것이었습니다(그리고 내가 type-imports를 제출한 이유

externref 는 명시적으로 선언된 유형 매개변수와 달리 기본 유형이기 때문에 어떻게 모듈별로 인스턴스화를 시도할 수 있는지 명확하지 않습니다.

유형 가져오기를 추가할 때 유형 가져오기가 없는 모듈을 처리할 수 있지만 externref 가 있는 모듈은 맨 위에 import type externref 가 있는 것으로 간주됩니다. 다른 기본 유형과 달리 externref 에는 연관된 기본 작업이 없기 때문에 모든 것이 동일하게 유형 검사됩니다(기본값을 갖는 것 외에). 그러나 암시적 가져오기를 통해 이제 가상화, 샌드박싱 및 런타임 모니터링과 같은 작업을 수행할 수 있습니다.

그러나 그것에 대해 앞뒤로 돌아가기 전에, 우리 모두가 무언가에 대해 같은 페이지에 있는지 판단하는 것이 도움이 될 것이라고 생각합니다. 다음 진술에 동의하거나 동의하지 않는지 알려주십시오. "일단 형식 가져오기를 사용할 수 있으면 모듈에서 externref 를 사용할 이유가 없으며 대신 형식 가져오기를 사용하면 용도 변경/구성이 더 쉬워집니다."

다음 진술에 동의하거나 동의하지 않는지 알려주십시오. "일단 유형 가져오기를 사용할 수 있게 되면 모듈은 externref 를 사용할 이유가 없으며 대신 유형 가져오기를 사용하는 경우 더 많은 용도/구성이 가능합니다."

나는 초록에서 이 말에 동의합니다. 실제로 externref는 인스턴스화 시 추가 구성이 필요하지 않기 때문에 외부 JS 객체를 참조하기 위해 웹 컨텍스트에서 일반적으로 유지될 것이라고 생각합니다. 그러나 그것은 단지 예측일 뿐이며 내가 잘못된 것으로 판명되어 모든 사람들이 결국 유형 가져오기를 사용하는 것으로 전환하더라도 상관하지 않을 것입니다. externref의 가치는 유형 가져오기와 같은 더 풍부한 메커니즘을 가질 수 있는 것보다 더 빨리 가질 수 있다는 것입니다. 나는 externref를 단순하게 유지하고 나중에 더 우아한 대안이있을 때 어색하게 더 강력한 것으로 구부리기보다 사용하지 않는 것을보고 싶습니다.

@tlively ,

FWIW, 나는 WebAssembly 모듈 내부에서 externref를 인스턴스화할 수 있다는 것을 이해한 적이 없습니다.

맞습니다. 아이디어는 externref가 외부 포인터의 "원시" 유형이라는 것입니다. 참조 유형의 구현 세부 사항을 추상화하려면 anyref 또는 유형 가져오기와 같은 다른 것이 필요합니다.

@lukewagner , 나는 그것이 바람직하다면 유형 가져오기 제안의 범위를 넓히는 데

@RossTate :

내가 상담한 이 전문가들은 일부 논문의 저자를 포함합니다.

훌륭한. 그런 다음 더 많은 권위를 찾고 있는 경우를 대비하여 귀하가 이 두 논문의 저자라는 사실을 알게 되었다고 가정합니다. :)

제가 질문한 내용은 다음과 같습니다.

다형성 함수 f(...)가 있다고 가정합니다. 내 입력 언어에는 (가정) 하위 유형 지정 및 명시적 캐스팅이 있습니다. 그러나 t1에서 t2로의 캐스트는 t2가 t1의 하위 유형인지 여부만 확인합니다. 기본적으로 X와 같은 유형 변수에 하위 유형이나 상위 유형이 없다고 가정합니다(물론 자체 제외). f가 X에 대해 관계적으로 모수적이라고 예상하시겠습니까?

한숨을 쉬다. 나는 그 특정한 질문에 같은 대답을 할 것이다. 그러나 이 질문은 예를 들어 캐스트의 특성, 그리고 어떤 프로그래밍 언어에도 거의 존재하지 않는 제한된 수량화와 무제한 수량화 간의 다소 특이한 구별에 대한 몇 가지 특정 가정을 구현합니다. 그리고 나는 그것이 이유가 있다고 생각합니다.

내가 "정적 유형 추상화가 불충분하다"고 말했을 때 나는 그것이 _기술적으로_ 가능하지 않다는 것을 의미하지 않았습니다(물론 가능합니다). 그러나 그것이 _실제적으로_ 적절하지 않다는 것을 의미합니다. 실제로는 유형 추상화와 하위 유형화/캐스팅 가능성(또는 매개변수 유형과 비 매개변수 유형 사이)의 분기를 원하지 않습니다. 이는 캐스트를 기반으로 하는 구성을 인위적으로 깨뜨릴 수 있기 때문입니다.

나는 당신이 주장하는 것을 이해하지 못합니다.

추상 유형의 값을 받은 경우에도 정확한 유형을 잊어버리고 싶을 수 있습니다. 예를 들어, 이를 일종의 합집합에 넣고 나중에 다운캐스트를 통해 복구하기를 원할 수 있습니다. 다른 참조 유형에 대해 원하는 것과 같은 이유로 그렇게 할 수 있습니다. 유형 추상화는 동일한 종류의 일반 유형에 유효한 특정 사용 패턴을 방해해서는 안 됩니다.

귀하의 대답은 다음과 같습니다. 그래서 각 사용 사이트의 보조 유형, 예를 들어 변형으로 모든 것을 래핑하십시오. 그러나 이는 상당한 래핑/언래핑 오버헤드를 의미할 수 있으며 더 복잡한 유형 시스템 기능이 필요하며 사용하기가 더 복잡합니다.

MVP가 참조 유형의 합집합을 지원해야 하는지, 또는 명시적 변형 유형을 도입하고 인코딩해야 하는지 여부에 대해 의견이 분분합니다. 좋든 나쁘든, 공용체는 일반적인 엔진의 힙 인터페이스와 자연스럽게 일치하며 오늘날 지원하기 쉽고 저렴합니다. 변형이 많지는 않지만 최소한 기존 엔진에서 추가 오버헤드와 예측 불가능한 성능을 유발할 가능성이 있는 훨씬 더 연구적인 접근 방식입니다. 그리고 나는 유형 시스템 사람으로서 사용자 대면 언어와 같은 다른 상황에서 공용체보다 변형을 훨씬 선호한다고 말하고 있습니다. ;)

메타 의견으로서 권위자나 CG에 호소하여 내 제안을 들어줄 필요가 없다는 점에 정말 감사드립니다.

다양한 제안에 대한 대화가 _가정_하기 전에 특정 근거나 미래 계획(항상 명확하지 않거나 아직 작성되지 않은 경우)과 같이 명확하지 않은 것에 대해 각 챔피언에게 _묻는_ 시작하면 더 효과적일 수 있다고 친절하게 제안합니다. 이러한 가정에 기초하여 대답하고 광범위한 주장과 제안을 합니까?

훌륭한. 그런 다음 더 많은 권위를 찾고 있는 경우를 대비하여 귀하가 이 두 논문의 저자라는 사실을 알게 되었다고 가정합니다. :)

예, 내 제안이 그러한 주장이 이루어진 조건을 구체적으로 다루고 있음을 알고 있음에도 불구하고 내 제안이 효과가 없다고 주장하는 문서가 있다고 제안하면 매우 문제가 됩니다.

실제로는 유형 추상화와 하위 유형화/캐스팅 가능성(또는 매개변수 유형과 비 매개변수 유형 사이)의 분기를 원하지 않습니다. 이는 캐스트를 기반으로 하는 구성을 인위적으로 깨뜨릴 수 있기 때문입니다.

이것은 사실이 아니라 의견입니다. 다국어 시스템을 위한 언어에 구애받지 않는 산업 유형 어셈블리 언어는 없으며 따라서 실행에 대해 주장하는 것은 불가능합니다. 이것은 철저한(별도의) 논의가 필요한 것입니다. 그 논의를 위해 먼저 CG가 장단점을 비교할 수 있도록 몇 가지 자세한 사례 연구를 제공하는 것이 도움이 될 것입니다.

다양한 제안에 대한 대화가 특정 근거나 미래 계획(항상 명확하지 않거나 아직 작성되지 않은 경우)과 같이 명확하지 않은 사항에 대해 각 챔피언에게 물어보는 것부터 시작하면 다양한 제안에 대한 대화가 더 효과적일 수 있다는 점을 제안하고 싶습니다. 이러한 가정에 기초하여 대답하고 광범위한 주장과 제안을 합니까?

WebAssembly/proposal-type-imports#4, WebAssembly/proposal-type-imports#6 및 WebAssembly/proposal-type-imports#7은 각각 본질적으로 이 계획에 대한 더 자세한 내용을 요청했습니다. 이 중 마지막은 GC에 문제를 제기하지만 WebAssembly/gc#86은 현재 GC 제안이 실제로 동적 추상화 메커니즘을 지원하지 않는다고 지적합니다.

메타 수준에서 우리는 이 토론을 제쳐두고 당면한 주제에 집중하라는 요청을 받았습니다. 내 질문에 대한 @tlively 의 답변이 매우 유용하다는 것을

@RossTate :

내 질문에 대한 @tlively 의 답변이 매우 유용하다는 것을

흠, 위에서 이미 댓글을 달았던 것 같아요. 아니면 다른 뜻인가요?

아니요. 그 댓글이 그의 대답에 동의한다는 뜻일 수도 있다고 생각했지만 먼저 확인하고 싶었다. 감사 해요!

@lukewagner , 어떻게 생각하세요?

나는 externref 가 영원히 기본 유형이 될 것이며 소급해서 유형 매개변수로 재해석되지 않을 것이라는 점에 동의합니다. 그런 점을 감안할 때 참조 유형은 그대로 사용할 수 있다고 생각합니다.

나는 그것이 추상적 인 형태를 구현하는 wasm 수있는 기능을 포함하도록 유형 수입 제안의 범위를 확장하기 위해 제안에 @rossberg을 차지 싶습니다. 일단 우리가 그것을 정리할 수 있다면, 함수 참조 및 하위 유형 지정에 대한 추가 논의를 차단 해제할 것이라고 생각합니다.

엄청난. 그런 다음 우리는 모두 같은 페이지에 있습니다(저도 @tlively가 관련된 절충안 과 결정에 대한 근거에 대한 훌륭한 요약을 제공한다고 생각합니다).

따라서 externref 는 인스턴스화할 수 없으며 유형 가져오기의 추가 유연성을 찾는 모듈은 기능이 릴리스될 때 유형 가져오기로 변환될 것으로 예상됩니다. 그 전환을 원활하게 하려면 인스턴스화가 제공되지 않은 경우 기본적으로 (일부?) 유형 가져오기가 externref 로 인스턴스화되도록 만들어야 할 것 같습니다.

그리고 Type Imports의 범위를 확장하자는 제안도 받아들이고 싶습니다. 형식 가져오기의 주요 응용 프로그램 중 많은 부분이 추상화를 필요로 하므로 추상화가 해당 제안의 일부인 것이 당연해 보입니다.

한편, externref 에 대한 긴급한 질문을 해결했지만 call_indirect 에 대해 보다 일반적으로 무엇을 해야 하는지는 여전히 해결되지 않고 있습니다. 여전히 문제를 열어둘 것입니다.

감사 해요!