Design: call_indirect बनाम अमूर्त

इस विस्तृत लेखन के लिए धन्यवाद, रॉस! मेरा एक छोटा सा सवाल है: " call_indirect और टाइप इम्पोर्ट्स" सेक्शन में आप लिखते हैं,

यदि आप तकनीक 1 को पसंद करते हैं, तो महसूस करें कि जब हम टाइप किए गए फ़ंक्शन संदर्भ जोड़ते हैं तो यह एक बार फिर काम नहीं करेगा।

क्या यह भी पिछले खंड से चेतावनी के अधीन है कि समस्या केवल तभी मौजूद है जब हम टाइप किए गए फ़ंक्शन संदर्भों में भिन्न उपप्रकार जोड़ते हैं?

यह नहीं। सबटाइपिंग सेक्शन में सभी मुद्दे प्रकार के आयात से स्वतंत्र होते हैं, और प्रकार के आयात अनुभाग में सभी मुद्दे सबटाइपिंग से स्वतंत्र होते हैं। जिस विशेष मुद्दे के बारे में आप पूछ रहे हैं, उस पर विचार करें कि 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] -> []) को "विफल" होना चाहिए क्योंकि फ़ंक्शन तर्क में विरोधाभासी हैं।

निर्यात प्रकार के साथ, एक मॉड्यूल एक हस्ताक्षर निर्दिष्ट करता है, जैसे 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] -> [] , ऊपर बिल्कुल के साथ उसके हस्ताक्षर लाइनों $do_stuff_export instantiating के बाद $handle के साथ capability , इसलिए जाँच सफल होती है। (यहां कोई सबटाइपिंग शामिल नहीं है, केवल परिवर्तनीय प्रतिस्थापन है।)

ध्यान दें, हालांकि, हस्ताक्षर स्वयं $handle बारे में कुछ नहीं कहता है। इसका मतलब है कि बाकी सभी को $handle को एक अमूर्त प्रकार के रूप में मानना ​​​​चाहिए। यही है, हस्ताक्षर जानबूझकर मॉड्यूल के कार्यान्वयन के विवरण को सार करते हैं, और बाकी सभी को उस अमूर्तता का सम्मान करना चाहिए। इस अंक का उद्देश्य यह स्पष्ट करना है कि call_indirect का उपयोग उस अमूर्तता को रोकने के लिए किया जा सकता है।

उम्मीद है कि यह इस मुद्दे को थोड़ा सा स्पष्ट करता है!

धन्यवाद, यह चीजों को स्पष्ट करता है। मेरे पास सबटाइपिंग सेक्शन के बारे में एक प्रश्न होगा (खेद है कि चारों ओर कूदने के लिए):

मैं उस परिदृश्य का अनुसरण कर रहा हूं जहां हम चाहते हैं कि आईबी सफल होने के लिए call_indirect[ -> tsuper](ref.func($fsuper)) निष्पादित करे, call_indirect "परिभाषा हस्ताक्षर के बजाय आयात हस्ताक्षर के साथ तुलना करें।"

और आपने जोड़ा कि (टाइप किए गए फ़ंक्शन संदर्भों के कारण) हमें भी चाहिए

1. अपेक्षित हस्ताक्षर और परिभाषा हस्ताक्षर की उप-प्रकार-संगतता के लिए कम से कम-रैखिक-समय रन-टाइम जांच करें।

क्या यह "अपेक्षित हस्ताक्षर और आयात हस्ताक्षर " के बीच संगतता होनी चाहिए? चूंकि हम मान रहे हैं कि हमने अपेक्षित हस्ताक्षर के साथ आयात हस्ताक्षर की तुलना call_indirect की है।

यदि अपेक्षित और आयात के बीच संगतता की जाँच की जाती है, तो बाद में, call_indirect[ -> tsub]($fsuper) विफल हो जाना चाहिए।

उस अप्रत्यक्ष कॉल को काम करने के लिए तकनीक 1 और 2 को दो ऑर्थोगोनल तरीकों के रूप में दिया गया है। दुर्भाग्य से, तकनीक 1 टाइप किए गए फ़ंक्शन संदर्भों के साथ असंगत है, और तकनीक 2 संभवतः बहुत महंगी है। इसलिए इनमें से कोई भी काम करने की संभावना नहीं है। इस प्रकार शेष खंड इस बात पर विचार करता है कि क्या होता है यदि हम इनमें से किसी का भी उपयोग नहीं करते हैं और केवल साधारण समानता के साथ चिपके रहते हैं-अपेक्षित और परिभाषित हस्ताक्षर के बीच तुलना। गलतफहमी के लिए खेद है; नियोजित शब्दार्थ नहीं होने का मतलब है कि मुझे तीन संभावित शब्दार्थों पर चर्चा करनी है।

सावधान रहें कि बहुत अधिक निष्कर्ष पर न जाएं। ;)

मेरी धारणा यह है कि call_indirect को आज की तरह ही तेज रहना चाहिए और इसलिए केवल एक प्रकार के तुल्यता परीक्षण की आवश्यकता होती है, चाहे हम भाषा में कितना भी उपप्रकार जोड़ दें। साथ ही, रनटाइम चेक को स्थिर प्रकार प्रणाली के साथ सुसंगत होना चाहिए, यानी, इसे सबटाइपिंग संबंध का सम्मान करना होगा।

अब, इन प्रतीत होने वाली विरोधाभासी आवश्यकताओं को वास्तव में काफी आसानी से सुलझाया जा सकता है, जब तक हम यह सुनिश्चित करते हैं कि call_indirect साथ प्रयोग करने योग्य प्रकार हमेशा उपप्रकार पदानुक्रम के पत्तों पर होते हैं।

लागू करने का एक स्थापित तरीका यह है कि _exact_ प्रकार की धारणा को टाइप सिस्टम में पेश किया जाए। एक सटीक प्रकार में कोई उपप्रकार नहीं होता है, केवल सुपरटाइप होता है, और हमारे पास (exact T) <: T ।

इसके साथ, हमें सटीक प्रकार होने के लिए call_indirect पर लक्ष्य प्रकार की आवश्यकता हो सकती है। इसके अलावा, फ़ंक्शन का प्रकार स्वाभाविक रूप से उस फ़ंक्शन का सटीक प्रकार पहले से ही है।

एक मॉड्यूल को फ़ंक्शन आयात पर सटीक प्रकारों की भी आवश्यकता हो सकती है, अगर यह सुनिश्चित करना चाहता है कि इसे केवल उन कार्यों के साथ तत्काल किया जा सकता है जो एक इच्छित रनटाइम जांच में सफल होते हैं।

यह सुनिश्चित करने के लिए बस इतना ही आवश्यक है कि कैनोनिकलाइज़्ड फ़ंक्शन प्रकारों पर एक साधारण पॉइंटर तुलना की वर्तमान कार्यान्वयन तकनीक मान्य बनी रहे। यह इस बात से स्वतंत्र है कि वहां अन्य सबटाइपिंग क्या है, या हम फंक्शन सबटाइपिंग को कितना फैंसी बनाते हैं। (एफडब्ल्यूआईडब्ल्यू, मैंने कुछ समय पहले ल्यूक के साथ इस पर चर्चा की थी, और एक पीआर बनाने की योजना बनाई थी, लेकिन इसे सबटाइपिंग कहानी में लंबित परिवर्तनों पर रोक दिया गया था, और अब कौन सा प्रस्ताव आगे बढ़ता है।)

(एक नकारात्मक पहलू यह है कि एक उपप्रकार के लिए एक फ़ंक्शन परिभाषा को परिष्कृत करना अब सामान्य रूप से एक पश्च-संगत परिवर्तन नहीं है, कम से कम यदि इसका सटीक प्रकार कहीं भी उपयोग नहीं किया गया है। लेकिन यह कमी हमारी बाधाओं के तहत अपरिहार्य है, भले ही हम वास्तव में कैसे लागू करते हैं उन्हें।)

एक दो पहलू:

विकल्प call_indirect और func.ref को वैसे ही छोड़ना है।

AFAICS, संदर्भ प्रकारों को शामिल करने वाले कार्यों पर ref.func को अस्वीकार करना संभव नहीं है। यह कई उपयोग के मामलों को गंभीर रूप से अपंग कर देगा, यानी, externref (कॉलबैक, हुक, आदि) पर चलने वाले प्रथम श्रेणी के कार्यों से जुड़ी हर चीज।

यह संभव है कि इसका मतलब यह है कि, जिस समाधान पर हम पहुंचते हैं, उसके आधार पर, externref तत्काल नहीं हो सकता है जैसे कि एक वास्तविक प्रकार का आयात होगा, और/या वह externref (विडंबना यह है कि) कोई सुपरटेप नहीं हो सकता है (उदाहरण के लिए नहीं हो सकता है अगर हम किसी भी रेफरी को जोड़ने का फैसला करते हैं तो किसी भी रेफरी का उप-प्रकार बनने में सक्षम हो)।

क्या आप विस्तार कर सकते हैं? मुझे कनेक्शन नहीं दिख रहा है।

सावधान रहें कि बहुत अधिक निष्कर्ष पर न जाएं। ;)

मुझे यकीन नहीं है कि आप किस निष्कर्ष का जिक्र कर रहे हैं। मेरा निष्कर्ष यह है कि call_indirect साथ कई मुद्दे हैं जिनके बारे में हमें जागरूक होने की आवश्यकता है और इसके लिए योजना बनाना शुरू कर देना चाहिए। ऐसा लगता है कि आप सुझाव दे रहे हैं कि ये मुद्दे अप्रासंगिक हैं क्योंकि आपके पास समाधान है। लेकिन उस समाधान की सीजी द्वारा समीक्षा नहीं की गई है या स्वीकार नहीं किया गया है, और हमें इसके लिए तब तक योजना नहीं बनानी चाहिए जब तक कि यह न हो जाए। मैंने विशेष रूप से समाधानों पर चर्चा न करने का अनुरोध किया क्योंकि उनका मूल्यांकन और तुलना करने में कुछ समय लगेगा और उन मूल्यांकनों और तुलनाओं को ठीक से करने के लिए हमारे पास समय होने से पहले हमें कुछ निर्णय लेने होंगे। लेकिन, लोगों को यह धारणा बनाने से रोकने के लिए कि यह समस्या हल हो गई है और परिणामस्वरूप दबावपूर्ण निर्णय से बचने के लिए, मैं आपके समाधान पर शीघ्रता से चर्चा करने के लिए एक सेकंड का समय लूंगा।

लागू करने का एक स्थापित तरीका यह है कि सटीक प्रकार की धारणा को टाइप सिस्टम में पेश किया जाए।

सटीक प्रकार शायद ही एक स्थापित समाधान हैं। यदि कुछ भी, सटीक प्रकारों ने समस्याओं को स्थापित किया है तो इसके प्रस्तावक अभी भी संबोधित करने के लिए काम कर रहे हैं। दिलचस्प बात यह है कि सटीक ऑब्जेक्ट प्रकारों द्वारा प्रेरित किया गया था, जो वास्तव में सटीक प्रकार का एक रूप नहीं है (सैद्धांतिक अर्थ में) बल्कि इसके बजाय उपसर्ग उप-प्रकार के ऑब्जेक्ट-एनालॉग को अस्वीकार कर देता है।) मैं कल्पना कर सकता हूं कि हम उस धागे को फिर से चला रहे हैं। यहां।

WebAssembly के लिए इस तरह की समस्याएं कैसे हो सकती हैं, इसके एक उदाहरण के रूप में, मान लीजिए कि हमने सबटाइपिंग को स्थगित नहीं किया था। के प्रकार ref.null होगा exact nullref सटीक प्रकार का उपयोग कर। लेकिन exact nullref exact anyref का उपप्रकार नहीं होगा। वास्तव में, सटीक प्रकार के सामान्य शब्दार्थ के अनुसार, संभवतः कोई भी मान exact anyref से संबंधित नहीं होगा क्योंकि संभवत: किसी भी मूल्य का रन-टाइम प्रकार बिल्कुल anyref । यह call_indirect को anyref s के लिए पूरी तरह से अनुपयोगी बना देगा।

अब हो सकता है कि आपके मन में सटीक प्रकार के कुछ अलग संस्करण हों, लेकिन यह जांचने में थोड़ा समय लगेगा कि यह भिन्न संस्करण किसी तरह सटीक प्रकारों के साथ कई खुली समस्याओं को संबोधित करता है। तो मेरी बात यहाँ इस समाधान बाहर निकालने के लिए है, लेकिन पहचान करने के लिए है कि यह स्पष्ट नहीं है कि इस समाधान है और वह उम्मीद के साथ निर्णय नहीं करने के लिए नहीं है।

क्या आप विस्तार कर सकते हैं? मुझे कनेक्शन नहीं दिख रहा है।

आप एक लंबे वाक्य का जिक्र कर रहे हैं। इसके किस भाग के बारे में आप मुझे विस्तार से बताना चाहेंगे? एक अनुमान यह है कि आप call_indirect और प्रकार के आयात के साथ समग्र समस्या को याद कर रहे हैं। आपका सटीक-प्रकार का सुझाव केवल सबटाइपिंग की समस्याओं का समाधान करता है, लेकिन हमने ऊपर स्थापित किया है कि call_indirect में बिना किसी सबटाइपिंग के भी समस्याएं हैं।

यह कई उपयोग के मामलों को गंभीर रूप से अपंग कर देगा, यानी, externref (कॉलबैक, हुक, आदि) पर चलने वाले प्रथम श्रेणी के कार्यों से जुड़ी हर चीज।

हाँ, तो यह कुछ ऐसा है जिसके बारे में मैं अधिक जानकारी प्राप्त करने की उम्मीद कर रहा था। मेरी समझ यह है कि call_indirect का प्राथमिक उपयोग केस सी/सी ++ फ़ंक्शन पॉइंटर्स और सी ++ वर्चुअल विधियों का समर्थन करना है। मेरी समझ यह भी है कि यह उपयोग मामला वर्तमान में संख्यात्मक हस्ताक्षरों तक ही सीमित है। मुझे call_indirect के अधिक संभावित उपयोगों के बारे में पता है, लेकिन जैसा कि मैंने उल्लेख किया है कि मैं एक अस्थायी प्रतिबंध का सुझाव दे रहा था, इसलिए जो मायने रखता है वह यह है कि call_indirect के वर्तमान उपयोग क्या हैं। यह देखते हुए कि call_indirect अभी भी केवल funcref बजाय एक तालिका और अनुक्रमणिका की आवश्यकता है, यह कॉलबैक का समर्थन करने के लिए विशेष रूप से अच्छी तरह से डिज़ाइन नहीं किया गया है। मुझे नहीं पता था कि ऐसा इसलिए है क्योंकि वर्तमान में इसका उपयोग इस उद्देश्य के लिए नहीं किया जा रहा है।

आप सभी इस सुविधा को लक्षित करने वाले कोड आधारों को मुझसे कहीं बेहतर जानते हैं, इसलिए यदि आप कुछ वास्तविक कार्यक्रमों के बारे में जानते हैं जिन्हें अभी इस कार्यक्षमता की आवश्यकता है, तो यहां उपयोग पैटर्न के कुछ उदाहरण प्रदान करना बहुत उपयोगी होगा। यह पता लगाने के लिए उपयोगी होने के अलावा कि क्या हमें अभी इस कार्यक्षमता का समर्थन करने की आवश्यकता है, यदि कार्यक्षमता की अभी आवश्यकता है तो ये उदाहरण यह सूचित करने में सहायक होंगे कि उपरोक्त मुद्दों को संबोधित करते हुए इसे जल्दी से कैसे प्रदान किया जाए।

@RossTate :

यदि कुछ भी, सटीक प्रकारों ने समस्याओं को स्थापित किया है तो इसके प्रस्तावक अभी भी संबोधित करने के लिए काम कर रहे हैं। दिलचस्प बात यह है कि यहां एक थ्रेड है जहां टाइपस्क्रिप्ट टीम ने मूल रूप से देखा कि आपके द्वारा प्रस्तावित फ़ॉर्म के सटीक प्रकार कुछ समस्याओं को कैसे हल कर सकते हैं, लेकिन फिर उन्हें अंततः एहसास हुआ कि सटीक प्रकारों ने हल की तुलना में अधिक समस्याएं पेश कीं। (संदर्भ के लिए नोट: उस चर्चा को फ्लो के सटीक ऑब्जेक्ट प्रकारों द्वारा प्रेरित किया गया था, जो वास्तव में सटीक प्रकार का एक रूप नहीं है (सैद्धांतिक अर्थ में) बल्कि इसके बजाय केवल उपसर्ग उप-प्रकार के ऑब्जेक्ट-एनालॉग को अस्वीकार करते हैं।) मैं कल्पना कर सकता हूं कि हम उस धागे को फिर से चला रहे हैं। यहां।

कोष्ठक यहाँ महत्वपूर्ण हैं। मुझे यकीन नहीं है कि उस धागे में उनके मन में क्या है, लेकिन ऐसा लगता है कि यह वही बात नहीं है। अन्यथा, "यह माना जाता है कि एक प्रकार T & U हमेशा T को असाइन करने योग्य होता है, लेकिन यह विफल हो जाता है यदि T एक सटीक प्रकार है" का कोई मतलब नहीं होगा (यह नहीं है' t विफल, क्योंकि T & U अमान्य या नीचे होगा)। अन्य प्रश्न मुख्य रूप से व्यावहारिकता के बारे में हैं, यानी, एक प्रोग्रामर उन्हें (वस्तुओं के लिए) कहां उपयोग करना चाहता है, जो हमारे मामले में लागू नहीं होता है।

निम्न-स्तरीय प्रकार की प्रणालियों के लिए, आपके अपने कुछ पत्रों में भी सटीक प्रकार एक महत्वपूर्ण घटक नहीं थे?

WebAssembly के लिए इस तरह की समस्याएं कैसे हो सकती हैं, इसके एक उदाहरण के रूप में, मान लीजिए कि हमने सबटाइपिंग को स्थगित नहीं किया था। सटीक प्रकारों का उपयोग करके ref.null का प्रकार सटीक nullref होगा। लेकिन सटीक नलरेफ सटीक किसी भी प्रकार का उपप्रकार नहीं होगा।

यहां कोई असहमति नहीं है। उपप्रकार नहीं होना सटीक प्रकारों का उद्देश्य है।

वास्तव में, सटीक प्रकार के सामान्य शब्दार्थ के अनुसार, संभवत: कोई भी मान सटीक किसी भी प्रकार से संबंधित नहीं होगा क्योंकि संभवत: किसी भी मूल्य का रन-टाइम प्रकार बिल्कुल भी नहीं है।

ठीक है, संयोजन (exact anyref) एक उपयोगी प्रकार नहीं है, यह देखते हुए कि anyref का एकमात्र उद्देश्य एक सुपरटाइप होना है। लेकिन यह समस्या क्यों है?

यह call_indirect को किसी भी रेफरी के लिए पूरी तरह से अनुपयोगी बना देगा।

क्या आप सुनिश्चित हैं कि अब आप स्तरों को भ्रमित नहीं कर रहे हैं? एक फ़ंक्शन प्रकार (exact (func ... -> anyref)) पूरी तरह से उपयोगी है। यह सिर्फ एक प्रकार के साथ संगत नहीं है, कहते हैं, (func ... -> (ref $T)) । अर्थात्, exact फ़ंक्शन प्रकारों पर गैर-तुच्छ उपप्रकार को रोकता है। लेकिन वह पूरी बात है!

हो सकता है कि आप (exact (func ... -> anyref)) को (func ... -> exact anyref) ? ये असंबंधित प्रकार हैं।

आपका सटीक-प्रकार का सुझाव केवल सबटाइपिंग की समस्याओं का समाधान करता है, लेकिन हमने ऊपर स्थापित किया है कि call_indirect में बिना किसी सबटाइपिंग के भी समस्याएं हैं।

आप किसी तरह यह मान रहे हैं कि आप एक अमूर्त डेटा प्रकार को परिभाषित करने के साधन के रूप में इसकी परिभाषा के बिना एक प्रकार का निर्यात करने में सक्षम होंगे। स्पष्ट रूप से, वह दृष्टिकोण गतिशील प्रकार की कास्ट (call_indirect या अन्यथा) की उपस्थिति में काम नहीं करता है। इसलिए मैं कहता रहता हूं कि हमें न्यूटाइप-स्टाइल टाइप एब्स्ट्रैक्शन की जरूरत होगी, न कि एमएल-स्टाइल टाइप एब्स्ट्रैक्शन की।

मेरी समझ यह है कि call_indirect का प्राथमिक उपयोग केस सी/सी ++ फ़ंक्शन पॉइंटर्स का समर्थन करना है

हां, लेकिन यह ref.func का एकमात्र उपयोग मामला नहीं है, जिसका मैं जिक्र कर रहा था, क्योंकि आपने इसे अपने सुझाए गए प्रतिबंध में शामिल किया था (शायद अनावश्यक रूप से ऐसा?) विशेष रूप से, call_ref , जिसमें टाइप चेक शामिल नहीं है।

आप किसी तरह यह मान रहे हैं कि आप एक अमूर्त डेटा प्रकार को परिभाषित करने के साधन के रूप में इसकी परिभाषा के बिना एक प्रकार का निर्यात करने में सक्षम होंगे। स्पष्ट रूप से, वह दृष्टिकोण गतिशील प्रकार की कास्ट (call_indirect या अन्यथा) की उपस्थिति में काम नहीं करता है। इसलिए मैं कहता रहता हूं कि हमें न्यूटाइप-स्टाइल टाइप एब्स्ट्रैक्शन की जरूरत होगी, न कि एमएल-स्टाइल टाइप एब्स्ट्रैक्शन की।

ठीक है, तो आप इस बात से सहमत हैं कि सटीक प्रकार call_indirect साथ समस्या को हल करने के लिए कुछ भी नहीं करते हैं और आयात टाइप करते हैं। लेकिन आप यह भी कह रहे हैं कि उस समस्या को हल करने का कोई मतलब नहीं है क्योंकि रन-टाइम कास्ट के कारण वैसे भी यह एक समस्या होगी। उस समस्या को रोकने का एक आसान तरीका है: लोगों को अमूर्त प्रकारों पर रन-टाइम कास्ट करने की अनुमति न दें (जब तक कि सार प्रकार स्पष्ट रूप से यह कहने योग्य न हो)। आखिरकार, यह एक अपारदर्शी प्रकार है, इसलिए हमें यह मानने में सक्षम नहीं होना चाहिए कि यह किसी कलाकार को करने के लिए आवश्यक संरचना को प्रदर्शित करता है। इसलिए भले ही इस बात की संभावना हो कि सटीक प्रकार सबटाइपिंग समस्या को संबोधित करते हैं, समस्या के दूसरे आधे हिस्से की अवहेलना करना जल्दबाजी होगी।

जैसा कि मैंने कहा, हर समाधान में ट्रेडऑफ़ होते हैं। आप यह मान रहे हैं कि आपके समाधान में केवल वही ट्रेडऑफ़ हैं जिन्हें आपने स्वयं पहचाना है, और आप यह मान रहे हैं कि सीजी आपके समाधान को दूसरों पर पसंद करेगा। मेरे पास भी इस समस्या का एक संभावित समाधान है। यह निरंतर-समय की जांच की गारंटी देता है, वर्चुअल मशीनों में पहले से उपयोग की जाने वाली तकनीक पर आधारित है, यहां सभी समस्याओं का समाधान करता है (मेरा मानना ​​​​है), किसी भी नए प्रकार को जोड़ने की आवश्यकता नहीं है, और वास्तव में ज्ञात अनुप्रयोगों के साथ WebAssembly में अतिरिक्त कार्यक्षमता जोड़ता है। हालांकि, मैं यह नहीं मान रहा हूं कि यह मेरी अपेक्षा के अनुरूप काम करता है और मैंने कुछ कमियों को नजरअंदाज नहीं किया है क्योंकि आपको और दूसरों को इसे देखने का मौका नहीं मिला है। मैं यह भी नहीं मान रहा हूं कि सीजी वैकल्पिक विकल्पों की तुलना में अपने ट्रेडऑफ़ को प्राथमिकता देगा। इसके बजाय, मैं यह पता लगाने की कोशिश कर रहा हूं कि विकल्पों का विश्लेषण करने के लिए हमें समय देने के लिए हम क्या कर सकते हैं ताकि सीजी, केवल मेरे बजाय, इस क्रॉस-कटिंग विषय पर एक सूचित निर्णय लेने वाला हो।

विशेष रूप से, call_ref , जिसमें टाइप चेक शामिल नहीं है।

आपके वाक्य में मुख्य शब्द इच्छा है । मैं पूरी तरह से पता के आवेदनों देखते हैं कि कर रहा हूँ call_indirect गैर-संख्यात्मक प्रकार के साथ यह है कि लोगों का समर्थन किया है रखना चाहते हैं। और मैं उम्मीद करते हैं कि हम एक डिजाइन कि समर्थन करता है कि कार्यक्षमता और पतों उपरोक्त मुद्दों के साथ आ जाएगा। लेकिन, जैसा कि मैंने कहा, आदर्श रूप से हमारे पास उस डिज़ाइन को विकसित करने के लिए कुछ समय हो सकता है ताकि हम उन प्रभावों की जांच करने का मौका मिलने से पहले क्रॉस-कटिंग प्रभाव वाली सुविधा को जल्दी से शिपिंग न करें। तो मेरा सवाल यह है कि क्या ऐसे प्रमुख कार्यक्रम हैं जिन्हें अब उस कार्यक्षमता की आवश्यकता है। यदि वहाँ है, तो परिकल्पना करने की कोई आवश्यकता नहीं है; बस कुछ को इंगित करें और स्पष्ट करें कि वे वर्तमान में इस कार्यक्षमता पर कैसे भरोसा करते हैं।

आप किसी तरह यह मान रहे हैं कि आप एक अमूर्त डेटा प्रकार को परिभाषित करने के साधन के रूप में इसकी परिभाषा के बिना एक प्रकार का निर्यात करने में सक्षम होंगे। स्पष्ट रूप से, वह दृष्टिकोण गतिशील प्रकार की कास्ट (call_indirect या अन्यथा) की उपस्थिति में काम नहीं करता है। इसलिए मैं कहता रहता हूं कि हमें न्यूटाइप-स्टाइल टाइप एब्स्ट्रैक्शन की जरूरत होगी, न कि एमएल-स्टाइल टाइप एब्स्ट्रैक्शन की।

यह मेरे लिए एक मौलिक मुद्दे की तरह लगता है। क्या निर्यात किए गए प्रकारों की परिभाषाओं की गोपनीयता को सक्षम करना आयात प्रकार के प्रस्ताव का लक्ष्य है? मैं इस सूत्र से इकट्ठा होता हूं कि @RossTate को लगता है कि यह एक लक्ष्य होना चाहिए और @rossberg को लगता है कि यह वर्तमान में एक लक्ष्य नहीं है। आइए समाधानों पर चर्चा करने से पहले इस प्रश्न पर चर्चा करें और सहमत हों ताकि हम सभी मान्यताओं के एक ही सेट से काम कर सकें।

@RossTate :

ठीक है, तो आप इस बात से सहमत हैं कि कॉल_इनडायरेक्ट और टाइप इंपोर्ट के साथ समस्या का समाधान करने के लिए सटीक प्रकार कुछ भी नहीं करते हैं।

हां, अगर इससे आपका मतलब अमूर्त डेटा प्रकारों को परिभाषित करने के लिए एक सुविधा को जोड़ने के सवाल से है। ऐसे कई तरीके हैं जिनसे टाइप एब्स्ट्रैक्शन लगातार काम कर सकता है, लेकिन ऐसी सुविधा सड़क से और नीचे है।

आपके वाक्य में मुख्य शब्द वसीयत है। मुझे पूरी तरह से पता है कि गैर-संख्यात्मक प्रकारों के साथ call_indirect के अनुप्रयोग हैं जिनका लोग समर्थन करना चाहेंगे।

call_ref निर्देश फ़ंक्शन रेफरी प्रस्ताव में है, किसी भी संभावित सार डेटा प्रकार तंत्र से पहले किसी भी मामले में काफी करीब है। क्या आप सुझाव दे रहे हैं कि हम इसे तब तक के लिए होल्ड पर रखें?

@tlively :

क्या निर्यात किए गए प्रकारों की परिभाषाओं की गोपनीयता को सक्षम करना आयात प्रकार के प्रस्ताव का लक्ष्य है? मैं इस सूत्र से इकट्ठा होता हूं कि @RossTate को लगता है कि यह एक लक्ष्य होना चाहिए और @rossberg को लगता है कि यह वर्तमान में एक लक्ष्य नहीं है।

यह एक लक्ष्य है, लेकिन एक सार डेटा प्रकार तंत्र एक अलग विशेषता है। और इस तरह के तंत्र को इस तरह से डिजाइन किया जाना चाहिए कि यह आयात के डिजाइन को प्रभावित न करे। अगर ऐसा होता है, तो हम इसे बहुत गलत कर रहे होंगे - परिभाषा स्थल पर अमूर्तता सुनिश्चित की जानी चाहिए, न कि उपयोग स्थल पर। सौभाग्य से, हालांकि, यह रॉकेट विज्ञान नहीं है, और डिजाइन स्थान काफी अच्छी तरह से निर्यात किया गया है।

धन्यवाद, @rossberg , यह समझ में आता है। टाइप इंपोर्ट और एक्सपोर्ट के बाद फॉलो-अप प्रस्ताव में एब्स्ट्रैक्शन प्रिमिटिव जोड़ना मेरे लिए ठीक लगता है, लेकिन यह बहुत अच्छा होगा अगर हम इस बारे में विवरण लिख सकें कि हम इसे जल्द ही कहीं कैसे करने की योजना बना रहे हैं। प्रकार के आयात और निर्यात का डिज़ाइन बाधा डालता है और अमूर्त प्रकार के आयात और निर्यात के डिज़ाइन को सूचित करता है, इसलिए यह महत्वपूर्ण है कि प्रारंभिक डिज़ाइन को अंतिम रूप देने से पहले हमें इस बात का एक अच्छा विचार है कि अमूर्त सड़क पर कैसे काम करेगा।

उस योजना का विवरण देने के अलावा, चूंकि call_indirect साथ यह मुद्दा यह प्रदर्शित कर रहा है कि यह दबाव के निर्णयों को प्रभावित करता है, क्या आप समझा सकते हैं कि आप मेरे सुझाव को अस्वीकार क्यों कर रहे हैं कि अमूर्त प्रकारों को कास्टेबल नहीं किया जाना चाहिए (जब तक कि स्पष्ट रूप से कास्टेबल होने के लिए विवश नहीं किया जाता है) )? वे अपारदर्शी हैं, इसलिए सुझाव अमूर्त प्रकार की सामान्य प्रथाओं के अनुरूप प्रतीत होता है।

@tlively , हाँ, सहमत हुए। इसके अलावा कई अन्य चीजें जो मैं कुछ समय के लिए लिखना चाहता था। एक बार जब मैं #69 से सभी नतीजों पर काम कर चुका हूं, तब करूंगा। ;)

@RossTate , क्योंकि यह अमूर्त डेटा प्रकारों को कास्ट के साथ असंगत बना देगा। सिर्फ इसलिए कि मैं दूसरों को _थ्रू_ एक अमूर्त प्रकार देखने से रोकना चाहता हूं, मैं जरूरी नहीं कि उन्हें (या खुद को) _to_ एक अमूर्त प्रकार कास्टिंग करने से रोकना चाहता हूं। इस तरह के झूठे द्वंद्व को बनाने से कास्ट के केंद्रीय उपयोग के मामले टूट जाएंगे। उदाहरण के लिए, निश्चित रूप से मैं एक पॉलिमॉर्फिक फ़ंक्शन में अमूर्त प्रकार का मान पास करने में सक्षम होना चाहता हूं।

@rossberg क्या आप स्पष्ट कर सकते हैं कि आपके मन में यह केंद्रीय उपयोग मामला क्या है? आपके उदाहरण की व्याख्या करने में मेरा सबसे अच्छा अनुमान तुच्छ रूप से हल करने योग्य है, लेकिन हो सकता है कि आपका मतलब कुछ और हो।

@RossTate , बहुरूपी कार्यों पर विचार करें। वासम-जेनेरिक की कमी, किसी भी रेफरी से अप/डाउन कास्ट का उपयोग करके उन्हें संकलित करते समय, किसी अन्य ऑब्जेक्ट में अतिरिक्त लपेटने के बिना, किसी अन्य की तरह अमूर्त प्रकार के मूल्यों के साथ उनका उपयोग करना संभव होना चाहिए। आप आम तौर पर किसी अन्य की तरह अमूर्त प्रकार के मूल्यों का इलाज करने में सक्षम होना चाहते हैं।

ठीक है, आइए बहुरूपी कार्यों पर विचार करें, और मान लें कि आयातित प्रकार है Handle :

1. जावा में बहुरूपी कार्य हैं। इसके बहुरूपी कार्य सभी (जावा संदर्भ) मानों के ऑब्जेक्ट होने की अपेक्षा करते हैं। विशेष रूप से, उनके पास एक वी-टेबल होना चाहिए। हैंडल का उपयोग करने वाला एक जावा मॉड्यूल संभवतः एक जावा वर्ग CHandle निर्दिष्ट करेगा जो संभवतः इंटरफेस को लागू कर रहा है। इस वर्ग के उदाहरणों में Handle प्रकार का एक (wasm-स्तर) सदस्य होगा और एक v-तालिका होगी जो विभिन्न वर्ग और इंटरफ़ेस विधियों के कार्यान्वयन के लिए फ़ंक्शन पॉइंटर्स प्रदान करती है। जब सतह-स्तर के पॉलीमॉर्फिक फ़ंक्शन को दिया जाता है, जो कि wasm स्तर पर ऑब्जेक्ट पर केवल एक फ़ंक्शन होता है, तो मॉड्यूल उसी तंत्र का उपयोग कर सकता है जिसका उपयोग वह अन्य वर्गों को कास्ट करने के लिए करता है CHandle ।
2. OCaml में बहुरूपी कार्य हैं। इसके बहुरूपी कार्य सभी OCaml मूल्यों से भौतिक समानता का समर्थन करने की अपेक्षा करते हैं। क्योंकि wasm OCaml की प्रकार की सुरक्षा के बारे में तर्क नहीं कर सकता, इसके बहुरूपी कार्यों के लिए भी कास्ट का भारी उपयोग करने की आवश्यकता होगी। एक विशेष कास्टिंग संरचना संभवतः इसे और अधिक कुशल बना देगी। इनमें से किसी भी कारण से, एक OCaml मॉड्यूल एक बीजीय डेटा प्रकार या रिकॉर्ड प्रकार THandle निर्दिष्ट करेगा जो इन मानदंडों के साथ फिट बैठता है और इसमें Handle प्रकार का एक (wasm-स्तर) सदस्य होता है। इसके बहुरूपी कार्य तब OCaml मानों को THandle वैसे ही डाल देंगे जैसे वे किसी अन्य बीजीय डेटा प्रकार या रिकॉर्ड प्रकार के लिए करते हैं।

दूसरे शब्दों में, क्योंकि मॉड्यूल इस बात पर निर्भर करते हैं कि पॉलिमॉर्फिक फ़ंक्शंस जैसी चीज़ों को लागू करने के लिए सतह-स्तर के मूल्यों का प्रतिनिधित्व कैसे किया जाता है, और अमूर्त आयातित प्रकार जैसे हैंडल इन मानदंडों को पूरा नहीं करते हैं, मूल्यों का लपेटना अनिवार्य है। यही कारण है कि anyref के मूल अनुप्रयोगों में से एक को इंटरफ़ेस प्रकारों से बदल दिया गया था। और हमने यह प्रदर्शित करते हुए केस स्टडीज विकसित कीं कि anyref पॉलीमॉर्फिक कार्यों का समर्थन करने के लिए आवश्यक नहीं है, न ही अच्छी तरह से अनुकूल है।

दूसरी ओर, आपने दिखाया है कि स्थिर अमूर्त तंत्र को रोकने के लिए कास्टेबल anyref का उपयोग किया जा सकता है। आपने जिस अमूर्त-तंत्र योजना का उल्लेख किया है, वह गतिशील अमूर्त तंत्र के माध्यम से इस समस्या को हल करने का एक प्रयास है। लेकिन गतिशील अमूर्त तंत्र के साथ कई समस्याएं हैं। उदाहरण के लिए, कोई आपके i31ref प्रकार को किसी के सार Handle i31ref प्रकार के रूप में निर्यात नहीं कर सकता है, बिना anyref का उपयोग करके और फोर्ज हैंडल (जैसे क्षमताओं के लिए) का उपयोग करके अन्य मॉड्यूल के जोखिम के बिना। इसके बजाय किसी को अतिरिक्त हुप्स और ओवरहेड्स के माध्यम से कूदना पड़ता है जो अनावश्यक होगा यदि हम इसके बजाय केवल मानक स्थिर अमूर्तता सुनिश्चित करते हैं।

साथ ही, अब (मुझे लगता है) मैं बेहतर ढंग से समझता हूं कि आप सटीक प्रकारों का उपयोग कैसे करना चाहते हैं, मुझे एहसास हुआ कि आपका इरादा call_indirect और सबटाइपिंग के साथ ध्यान देने वाली दो प्रमुख समस्याओं में से कोई भी संबोधित नहीं करता है:

1. यह call_indirect सम्मान सबटाइपिंग बनाने में मदद नहीं करता है (जो मुझे लगता है कि आपने पहले ही स्पष्ट रूप से कहा है)
2. यह call_indirect को अपने निर्यात किए गए हस्ताक्षर के बजाय अपने परिभाषित हस्ताक्षर के साथ निर्यात किए गए फ़ंक्शन का उपयोग करने से नहीं रोकता है।

तो यह हल करने के लिए एक छोटी सी समस्या नहीं है। इसलिए, समय की कमी को देखते हुए, मैं इस बात का मूल्यांकन करने पर ध्यान देना पसंद करूंगा कि हमें इसे कैसे ठीक से हल करने के लिए समय दिया जाए। मुझे नहीं लगता कि पहले इस बारे में चर्चा करना आवश्यक होना चाहिए कि क्या anyref लिए स्थिर अमूर्तता को फेंकने लायक है। चीजों में और देरी न करने के लिए मैं इस तरह की बड़ी चर्चा से बचने की उम्मीद कर रहा था।

दूसरी तरफ, आपने दिखाया है कि स्थिर अमूर्त तंत्र को रोकने के लिए कास्टेबल Anyref का उपयोग किया जा सकता है।

डायनामिक टाइप कास्ट वाली भाषा में स्टेटिक टाइप एब्स्ट्रैक्शन अपर्याप्त है। क्योंकि स्टैटिक एब्स्ट्रैक्शन पैरामीट्रिकिटी पर निर्भर करता है, और कास्ट इसे तोड़ देता है। इसमें कोई नई बात नहीं है, इसके बारे में पेपर लिखे जा चुके हैं। ऐसे संदर्भ में अन्य अमूर्त तंत्र की आवश्यकता है।

अमूर्त प्रकारों के उपयोग को प्रतिबंधित करके उसके आसपास काम करने की कोशिश करना उनके उद्देश्य को हरा देता है। WASI उपयोग के मामले पर विचार करें। इससे कोई फर्क नहीं पड़ना चाहिए कि क्या WASI मॉड्यूल और इसके द्वारा निर्यात किए जाने वाले किसी भी प्रकार को होस्ट द्वारा कार्यान्वित किया जाता है या Wasm में। यदि आप उपयोगकर्ता द्वारा परिभाषित अमूर्त प्रकारों को मनमाने ढंग से प्रतिबंधित करते हैं, तो एक Wasm कार्यान्वयन अब सामान्य रूप से एक मेजबान कार्यान्वयन के साथ विनिमेय नहीं होगा।

1. यह call_indirect सम्मान उप-प्रकार बनाने में मदद नहीं करता है (जो मुझे लगता है कि आपने पहले ही स्पष्ट रूप से कहा है)

हुह? यह सबटाइपिंग नियमों का हिस्सा है, इसलिए परिभाषा के अनुसार करता है।

1. यह call_indirect को अपने निर्यात किए गए हस्ताक्षर के बजाय अपने परिभाषित हस्ताक्षर के साथ निर्यात किए गए फ़ंक्शन का उपयोग करने से नहीं रोकता है।

मैंने यह नहीं कहा कि किया। मैंने कहा कि यह स्वयं call_indirect के साथ कोई समस्या नहीं है, बल्कि कास्ट वाली भाषा के लिए उपयुक्त प्रकार के अमूर्त तंत्र को चुनने का प्रश्न है।

एक तरफ के रूप में, OCaml (या किसी भी समान भाषा) को संकलित करने के लिए भिन्न प्रकारों की शुरूआत की आवश्यकता होने का कोई अनिवार्य कारण नहीं है। यहां तक ​​​​कि अगर यह सिद्धांत में थोड़ा तेज हो सकता है (जो मुझे संदेह है कि वर्तमान-जीन इंजनों में मामला होगा, इसके विपरीत अधिक संभावना है), भिन्न प्रकार एक महत्वपूर्ण जटिलता है जो एमवीपी के लिए आवश्यक नहीं होना चाहिए। मैं समय से पहले जटिलता के लिए आपकी भूख को साझा नहीं करता। ;)

कार्यों पर समानता: हास्केल या एसएमएल जैसी भाषाएं हैं, जो इसका समर्थन नहीं करती हैं, इसलिए सीधे func refs से लाभ हो सकता है। OCaml संरचनात्मक समानता के लिए फेंकता है और स्पष्ट रूप से भौतिक के लिए कार्यान्वयन-परिभाषित व्यवहार है। यह खुला छोड़ दिया जाता है कि क्या यह हमेशा झूठे लौटने या कार्यों के लिए फेंकने की अनुमति देता है, लेकिन या तो अभ्यास में पर्याप्त हो सकता है, और महंगा अतिरिक्त रैपिंग करने से पहले खोज करने लायक हो सकता है।

[एक मेटा टिप्पणी के रूप में, मैं वास्तव में सराहना करता हूं यदि आपने अपने व्याख्यान को कम कर दिया है और शायद इस विचार पर विचार किया है कि यह एक ऐसी दुनिया है जहां, शायद, सक्षम लोगों का सेट सिंगलटन नहीं है और दिमाग के निशान कभी-कभी पहले भी लागू होते हैं।]

एक मेटा टिप्पणी के रूप में, यदि आप अपने व्याख्यान को कम करते हैं तो मैं वास्तव में सराहना करूंगा

सुना।

और शायद इस विचार पर विचार किया कि यह एक ऐसी दुनिया है जहां, शायद, सक्षम लोगों का समूह सिंगलटन नहीं है और दिमाग के निशान कभी-कभी पहले भी लागू होते हैं।

यहां मेरी सलाह कई विशेषज्ञों के परामर्श पर आधारित है।

डायनामिक टाइप कास्ट वाली भाषा में स्टेटिक टाइप एब्स्ट्रैक्शन अपर्याप्त है। क्योंकि स्टैटिक एब्स्ट्रैक्शन पैरामीट्रिकिटी पर निर्भर करता है, और कास्ट इसे तोड़ देता है। इसमें कोई नई बात नहीं है, इसके बारे में पेपर लिखे जा चुके हैं। ऐसे संदर्भ में अन्य अमूर्त तंत्र की आवश्यकता है।

जिन विशेषज्ञों से मैंने परामर्श किया है उनमें कुछ उक्त पत्रों के लेखक शामिल हैं।

अब, यह जांचने के प्रयास के रूप में कि मैंने उनकी सलाह को सही ढंग से संश्लेषित किया है, मैंने अभी कुछ उक्त पत्रों के एक अन्य लेखक को ई-मेल किया है, जिनके बारे में मैंने पहले इस विषय पर चर्चा नहीं की है। मैंने जो पूछा वह यहां है:

मान लीजिए मेरे पास एक बहुरूपी कार्य है f(...) मेरी टाइप की गई भाषा में (सब्जेक्टिव) सबटाइपिंग और स्पष्ट कास्टिंग है। हालाँकि, t1 से t2 तक का कास्ट केवल यह जाँचता है कि t2 t1 का उपप्रकार है या नहीं। मान लीजिए कि डिफ़ॉल्ट रूप से एक्स जैसे प्रकार के चर में कोई उपप्रकार या सुपरटेप नहीं है (बेशक खुद के अलावा)। क्या आप अपेक्षा करते हैं कि f, X के संबंध में सापेक्षिक रूप से पैरामीट्रिक है?

ये रही उनकी प्रतिक्रिया:

हां, मुझे लगता है कि यह पैरामीट्रिक होगा क्योंकि यह आपको केवल एक्स पर कास्ट लिखने की क्षमता देता है जो एक पहचान समारोह के बराबर है, जो पहले से ही पैरामीट्रिक है।

यह मेरी सलाह के अनुरूप है। अब, निश्चित रूप से, यह हाथ में समस्या का सरलीकरण है, लेकिन हमने विशेष रूप से WebAssembly के लिए समस्या की जांच करने का प्रयास किया है, और अब तक हमारे अन्वेषण ने सुझाव दिया है कि यह अपेक्षा WebAssembly के पैमाने पर भी जारी है call_indirect को छोड़कर , इसलिए यह मुद्दा।

ध्यान दें कि जिन प्रमेयों का आप उल्लेख कर रहे हैं, वे उन भाषाओं पर लागू होते हैं जिनमें सभी मान कास्ट करने योग्य होते हैं। यह अवलोकन वह जगह है जहाँ हमें जातिवाद को प्रतिबंधित करने का विचार आया।

WASI उपयोग के मामले पर विचार करें।

मैं आपके द्वारा किए जा रहे दावों को नहीं समझता। हमने WASI उपयोग के मामले पर विचार किया है। हमारे द्वारा, मैं सुरक्षा और यहां तक ​​कि विशेष रूप से क्षमता-आधारित सुरक्षा में कई विशेषज्ञों को शामिल कर रहा हूं।

एक मेटा टिप्पणी के रूप में, मैं वास्तव में सराहना करूंगा कि मेरे सुझावों को सुनने के लिए प्राधिकरण या सीजी से अपील करने की आवश्यकता नहीं है। मैंने सुझाव दिया कि कास्ट को प्रतिबंधित करने से कास्ट की उपस्थिति में भी स्थिर पैरामीट्रिकिटी सुनिश्चित हो सकेगी। आपने तुरंत उस सुझाव की अवहेलना की, उस बर्खास्तगी को उचित ठहराने के लिए पूर्व के कागजात की अपील की। फिर भी जब मैंने उन पत्रों के लेखक को यही सुझाव दिया, तो वे तुरंत उसी निष्कर्ष पर पहुंचे जैसे मैंने किया था और जैसा आप कर सकते थे। इससे पहले, मैंने सुझाव दिया था कि संभावित समाधानों का मूल्यांकन करना एक लंबी प्रक्रिया होगी। आपने उस सुझाव की अवहेलना की, यह कहते हुए कि आपने (अपने दम पर) समस्या का समाधान किया था, हम दोनों को इस लंबी बातचीत में खींच लिया। जब किसी के सुझावों को इतनी लापरवाही से बार-बार खारिज कर दिया जाता है, तो प्रगति करना और निराश होने से बचना बेहद मुश्किल है। (मुझे स्पष्ट करना चाहिए कि मैं यहां आपके सुझाव को एक संभावित समाधान के रूप में खारिज करने की कोशिश नहीं कर रहा हूं; मैं यह प्रदर्शित करने की कोशिश कर रहा हूं कि यह एकमात्र समाधान नहीं है और इसलिए इसका मूल्यांकन कई अन्य लोगों के साथ किया जाना चाहिए।)

मुझे लगता है कि इस मुद्दे में उठाई गई चिंताओं को दूर करने के लिए विस्तृत डिजाइन तैयार किया गया है और इसकी जांच की गई है, यह महत्वपूर्ण और सामयिक है: मुझे वास्तव में नहीं लगता कि अमूर्त प्रकारों को एक दूर की विशेषता माना जाना चाहिए; WASI को अब उनकी जरूरत है-ईश।

मुझे यह भी उम्मीद है कि exact + newtype चिंताओं को दूर कर सकता है, लेकिन मैं मानता हूं कि हम समय से पहले एक डिजाइन के लिए समय से पहले इस समय इस कूबड़ पर खेत को दांव पर नहीं लगा सकते हैं हम (शीघ्र ही) संदर्भ प्रकार जहाज करते हैं। हमें इसके बारे में उचित चर्चा करने के लिए समय चाहिए।

कहा जा रहा है, मुझे संदर्भ-प्रकार के प्रस्ताव में externref में call_indirect हस्ताक्षरों की अनुमति देने में कोई खतरा नहीं दिखता है। हां, यदि कोई मॉड्यूल externref मान निर्यात करता है (एक कॉन्स ग्लोबल के रूप में या इसे किसी फ़ंक्शन से वापस कर रहा है ...), तो हमने यह नहीं बताया है कि हम उस externref को डाउनकास्ट कर सकते हैं या नहीं। लेकिन call_indirect एक externref ; यह funcref , और externref funcref-type-equality check wrt i32 से अलग भूमिका में नहीं है। इस प्रकार, call_indirect में टाइप इंपोर्ट, टाइप एक्सपोर्ट और प्ले पर सबटाइपिंग के अभाव में, मुझे नहीं लगता कि हम एक नए डिज़ाइन विकल्प के लिए कैसे प्रतिबद्ध हैं जिसे हमने पहले से ही एमवीपी में प्रतिबद्ध नहीं किया है। .

यदि कोई खतरा नहीं है, तो शायद हम इस गहन चर्चा को टाइप आयात प्रस्ताव में कम गहन चर्चा के लिए डायल कर सकते हैं (जहां मुझे अभी भी लगता है कि हमें उचित सार प्रकार का समर्थन शामिल करना चाहिए)?

ज़रूर। मुझे लगता है कि यह जांचना एक अच्छा विचार है कि कोई खतरा है या नहीं।

WASI के संबंध में, डिज़ाइन अभी भी बहुत अधिक प्रवाह में है, लेकिन एक विकल्प जो अभी भी व्यवहार्य लगता है, वह है अपने "हैंडल्स" के लिए i31ref जैसे कुछ का उपयोग करना, क्योंकि इसे गतिशील मेमोरी आवंटन की आवश्यकता नहीं है। WASI अन्य विकल्पों पर निर्णय ले सकता है, लेकिन बात यह है कि वर्तमान में कोई नहीं जानता है, और यह अच्छा होगा कि अब किए गए निर्णय ऐसे निर्णयों को प्रभावित न करें।

वर्तमान में, externref एकमात्र सार प्रकार उपलब्ध है, और इसलिए एक WASI-आधारित होस्ट externref को i31ref (या जो भी WASI "हैंडल" हैं) के साथ तुरंत चालू करेगा। लेकिन मेरी समझ यह है कि WASI होस्ट-निर्भर कोड को कम करने के लिए जितना संभव हो सके WebAssembly में इसके कार्यान्वयन को स्थानांतरित करना चाहता है। इसे सुविधाजनक बनाने के लिए, कुछ बिंदु पर WASI सिस्टम किसी अन्य प्रकार के आयात की तरह ही externref का इलाज करना चाहते हैं और इसे WASI के अमूर्त निर्यात Handle प्रकार के साथ तत्काल करना चाहते हैं। लेकिन अगर Handle है i31ref , तो call_indirect के उपरोक्त कार्यान्वयन को मॉड्यूल सीमाओं के पार काम करने में सक्षम बनाने के लिए इसका उपयोग लोगों को externref माध्यम से हैंडल बनाने के लिए भी किया जा सकता है।

तो मेरे प्रश्नों में से एक, जो अब मैं देख रहा हूं, मेरी मूल पोस्ट में स्पष्ट रूप से नहीं बताया गया था, क्या लोग चाहते हैं कि externref अन्य अमूर्त प्रकार के आयात की तरह तत्काल हो?

तो मेरे प्रश्नों में से एक, जो अब मैं देख रहा हूं, मेरी मूल पोस्ट में स्पष्ट रूप से नहीं बताया गया था, क्या लोग चाहते हैं कि externref अन्य अमूर्त प्रकार के आयात की तरह तत्काल हो?

इस प्रश्न को स्पष्ट रूप से उठाने के लिए धन्यवाद। एफडब्ल्यूआईडब्ल्यू, मैंने कभी भी externref को WebAssembly मॉड्यूल के अंदर से तत्काल करने योग्य नहीं समझा है। इसका मतलब है कि वर्चुअलाइजेशन में मेजबान भागीदारी अगर WASI हैंडल के रूप में externref का उपयोग करना चाहता है, लेकिन यह मेरे लिए ठीक लगता है, या कम से कम एक अलग चर्चा लगता है।

हम्म, मुझे देखने दो कि क्या मैं स्पष्ट कर सकता हूं। मुझे संदेह है कि आप पहले से ही बोर्ड पर हैं जो निम्नानुसार है, लेकिन मेरे लिए बस खरोंच से शुरू करना आसान है।

एक wasm मॉड्यूल के दृष्टिकोण से, externref अर्थ होस्ट संदर्भ नहीं है। यह सिर्फ एक अपारदर्शी प्रकार है जिसके बारे में मॉड्यूल कुछ भी नहीं जानता है। इसके बजाय, यह externref आसपास के सम्मेलन हैं जो इसे एक मेजबान संदर्भ के रूप में व्याख्या करते हैं। उदाहरण के लिए, एक मॉड्यूल की परंपराओं का उपयोग कर externref डोम के साथ बातचीत करने से जुड़े कार्यों में स्पष्ट हो जाएगा externref कि मॉड्यूल आयात, जैसे parentNode : [externref] -> [externref] और childNode : [externref, i32] -> [externref] । मॉड्यूल का वातावरण, जैसे कि स्वयं होस्ट, वही है जो वास्तव में होस्ट संदर्भ के रूप में externref की व्याख्या देता है, और यह उस व्याख्या की पुष्टि करने वाले आयातित तरीकों के कार्यान्वयन प्रदान करता है।

हालांकि, मॉड्यूल के वातावरण मेजबान होने के लिए नहीं है और externref मेजबान संदर्भ होने की जरूरत नहीं है। पर्यावरण एक और मॉड्यूल हो सकता है जो कुछ प्रकार के लिए कार्यक्षमता प्रदान करता है जो अपेक्षित सम्मेलनों को प्रदर्शित करने वाले मेजबान संदर्भों की तरह दिखता है। मान लें कि मॉड्यूल ई मॉड्यूल एम का वातावरण है, और वह मॉड्यूल एम ऊपर के रूप में parentNode और childNode आयात करता है। मान लें कि ई मॉड्यूल एम का उपयोग करना चाहता है लेकिन एम की पहुंच को डीओएम तक सीमित करना चाहता है, क्योंकि ई को एम पर सीमित भरोसा है या क्योंकि ई किसी भी बग को बाध्य करना चाहता है और जानता है कि एम की ज़रूरतें इन प्रतिबंधों से अधिक नहीं होनी चाहिए। E क्या कर सकता है M को "MonitoredRef" के साथ M के externref रूप में तुरंत चालू करें। मान लें कि, विशेष रूप से, E, M DOM नोड देना चाहता है, लेकिन सुनिश्चित करें कि M, DOM ट्री से ऊपर नहीं जाता है। तब E का MonitoredRef विशेष रूप से ref (struct externref externref) , जहां दूसरा externref (E के दृष्टिकोण से) DOM नोड है जिस पर M काम कर रहा है, लेकिन पहला externref का पूर्वज है वह नोड कि एम को अतीत में चलने की अनुमति नहीं है। ई तब एम के parentNode तुरंत चालू कर सकता है जैसे कि यह गलती करता है यदि ये दो संदर्भ समान हैं। E स्वयं अपने स्वयं के parentNode और childNode फ़ंक्शन आयात करेगा, जिससे E प्रभावी रूप से DOM इंटरैक्शन का रन-टाइम मॉनिटर बन जाएगा।

उम्मीद है कि यह सही तस्वीर को चित्रित करने के लिए पर्याप्त ठोस था, जबकि विवरण में खो जाने के लिए इतना ठोस नहीं था। जाहिर है इस तरह के कई पैटर्न हैं। तो मुझे लगता है कि प्रश्न को वाक्यांश देने का एक और तरीका है, क्या हम चाहते हैं कि externref केवल वास्तव में मेजबान संदर्भों का प्रतिनिधित्व करें?

एकमात्र हिस्सा जो मुझे संदेहास्पद लगता है वह है "ई क्या कर सकता है एम को "मॉनिटरेडरेफ" के साथ एम के externref रूप में तत्काल एम कर सकता है।" मैं इस धारणा के तहत नहीं हूं कि अन्य मॉड्यूल में अमूर्त चीजों को externref रूप में प्रदर्शित करने की अनुमति देने की योजना है। मेरी समझ यह है कि externref एक अमूर्त उपकरण नहीं है।

मुझे ऐसी किसी योजना की जानकारी भी नहीं है; मैं यह भी नहीं जानता कि क्या किसी ने विकल्प पर विचार किया था। यानी, क्या externref एक "आदिम" प्रकार होना चाहिए, उदाहरण के लिए i32 , या एक "तत्काल" प्रकार, जैसे आयातित प्रकार?

मेरी मूल पोस्ट में, मैंने संकेत दिया था कि कोई भी तरीका प्रबंधनीय है। "आदिम" व्याख्या के लिए जाने का ट्रेडऑफ यह है कि externref आयातित प्रकारों की तुलना में काफी कम उपयोगी/रचना योग्य है, क्योंकि बाद वाला externref के उपयोग के मामलों के साथ-साथ उपरोक्त पैटर्न का समर्थन करेगा। जैसे, "आदिम" externref अवशेषी बनने की संभावना प्रतीत होती है—केवल पश्चगामी संगतता के लिए विद्यमान है। लेकिन ऐसा लगता है कि विशेष रूप से समस्याग्रस्त होने की संभावना नहीं है, केवल एक उपद्रव। सबसे बड़ी समस्या मैं देख सकता हूँ कि है, बस की अच्छी तरह से behavedness तरह call_indirect सांख्यिक प्रकार पर बाहर काम करता है क्योंकि उन पर कोई supertypes, की अच्छी तरह से behavedness है call_indirect के आधार पर खत्म हो सकता है externref में कोई सुपरटाइप भी नहीं है।

आह, हाँ, यह समझने में अंतर बताता है: मैं @tlively से सहमत externref बिल्कुल भी सार नहीं है और "एक प्रकार के साथ externref को तुरंत चालू करने" की कोई धारणा नहीं है, और मैं लगता है कि हम इसे आगे बढ़ने के बारे में बहुत आश्वस्त महसूस कर सकते हैं। (चूंकि externref एक आदिम प्रकार है, जैसा कि स्पष्ट रूप से घोषित प्रकार पैरामीटर के विपरीत है, यह स्पष्ट नहीं है कि कोई इसे प्रति-मॉड्यूल आधार पर तत्काल करने का प्रयास कैसे कर सकता है।)

डाउनकास्ट की अनुपस्थिति में, यह तथ्य WASI API को लागू करने/वर्चुअलाइज़ करने के लिए लगभग बेकार बना देता है, यही कारण है कि WASI की योजना i32 हैंडल से सीधे टाइप इंपोर्ट में संक्रमण करने की रही है (और मैंने /#6 , b/c हमें थोड़ा और चाहिए)।

चूंकि externref एक आदिम प्रकार है, जैसा कि स्पष्ट रूप से घोषित प्रकार पैरामीटर के विपरीत है, यह स्पष्ट नहीं है कि कोई इसे प्रति-मॉड्यूल आधार पर तत्काल करने का प्रयास कैसे कर सकता है।

जब हम प्रकार के आयात जोड़ते हैं, तो हम बिना प्रकार के आयात के मॉड्यूल का इलाज कर सकते हैं लेकिन externref साथ शीर्ष पर import type externref होने के साथ। सब कुछ उसी तरह टाइप-चेक करेगा क्योंकि, अन्य आदिम प्रकारों के विपरीत, externref में कोई संबद्ध आदिम संचालन नहीं है (डिफ़ॉल्ट मान से परे)। लेकिन उस निहित आयात के साथ, अब हम वर्चुअलाइजेशन, सैंडबॉक्सिंग और रन-टाइम मॉनिटरिंग जैसी चीजें कर सकते हैं।

लेकिन उस पर आगे और पीछे जाने से पहले, मुझे लगता है कि यह पता लगाने में मदद करेगा कि क्या हम सभी एक ही पृष्ठ पर किसी चीज़ के बारे में हैं। मुझे बताएं कि क्या आप निम्नलिखित कथन से सहमत या असहमत हैं और क्यों: "एक बार प्रकार के आयात उपलब्ध होने के बाद, मॉड्यूल के पास externref का उपयोग करने का कोई कारण नहीं होता है और यदि वे इसके बजाय एक प्रकार के आयात का उपयोग करते हैं तो वे अधिक पुन: प्रयोज्य/संगत हैं।"

मुझे बताएं कि क्या आप निम्नलिखित कथन से सहमत हैं या असहमत हैं और क्यों: "एक बार प्रकार के आयात उपलब्ध होने के बाद, मॉड्यूल के पास externref का उपयोग करने का कोई कारण नहीं है और यदि वे इसके बजाय एक प्रकार के आयात का उपयोग करते हैं तो वे अधिक पुन: प्रयोज्य/संगत हैं।"

मैं सार में इस कथन से सहमत हूं। व्यावहारिक रूप से मुझे लगता है कि बाहरी जेएस ऑब्जेक्ट्स को संदर्भित करने के लिए वेब संदर्भों में बाहरी संदर्भ सामान्य रहेगा क्योंकि इसे तत्काल समय पर अतिरिक्त कॉन्फ़िगरेशन की आवश्यकता नहीं होती है। लेकिन यह सिर्फ एक भविष्यवाणी है और मुझे कोई आपत्ति नहीं होगी अगर मैं गलत निकला और हर कोई टाइप आयात का उपयोग करने के लिए स्विच करता है। एक्सटर्नरेफ का मूल्य यह है कि हमारे पास इसे जल्द से जल्द प्राप्त कर सकते हैं जैसे कि हमारे पास प्रकार के आयात जैसे समृद्ध तंत्र हो सकते हैं। मैं इसके बजाय externref को सरल रखूंगा और इसे अजीब तरह से शूहॉर्न की तुलना में उपयोग से बाहर कर दूंगा, जब बाद में और अधिक सुरुचिपूर्ण विकल्प होंगे।

@tlively ,

FWIW, मैंने कभी भी WebAssembly मॉड्यूल के अंदर से externref को तत्काल करने योग्य नहीं समझा है।

ठीक है, विचार यह है कि externref विदेशी पॉइंटर्स का "आदिम" प्रकार है। किसी संदर्भ प्रकार के कार्यान्वयन विवरण को संक्षेप में बताने के लिए, आपको कुछ और चाहिए: कुछ जैसे anyref या एक प्रकार का आयात।

@lukewagner , यदि यह बेहतर है, तो मैं प्रकार के आयात प्रस्ताव के दायरे को चौड़ा करने के साथ बोर्ड पर

@RossTate :

जिन विशेषज्ञों से मैंने परामर्श किया है उनमें कुछ उक्त पत्रों के लेखक शामिल हैं।

उत्कृष्ट। तब मुझे लगता है कि आपने देखा है कि आप वास्तव में इन दो पत्रों के लेखक हैं, यदि आप अधिक अधिकार की तलाश में हैं। :)

मैंने जो पूछा वह यहां है:

मान लीजिए मेरे पास एक बहुरूपी कार्य f(...) है। मेरी टाइप की गई भाषा में (सब्जेक्टिव) सबटाइपिंग और स्पष्ट कास्टिंग है। हालाँकि, t1 से t2 तक का कास्ट केवल यह जाँचता है कि t2 t1 का उपप्रकार है या नहीं। मान लीजिए कि डिफ़ॉल्ट रूप से एक्स जैसे प्रकार के चर में कोई उपप्रकार या सुपरटेप नहीं है (बेशक खुद के अलावा)। क्या आप अपेक्षा करते हैं कि f, X के संबंध में सापेक्षिक रूप से पैरामीट्रिक है?

आहें। मैं उस विशिष्ट प्रश्न का वही उत्तर दूंगा। लेकिन यह प्रश्न कई विशिष्ट धारणाओं का प्रतीक है, उदाहरण के लिए कास्ट की प्रकृति के बारे में, और बाध्य और असीमित मात्रा के बीच एक असामान्य भेद के बारे में जो शायद ही कभी किसी प्रोग्रामिंग भाषा में मौजूद होता है। और मुझे लगता है कि यह एक कारण के लिए है।

जब मैंने कहा "स्थिर प्रकार का अमूर्तन अपर्याप्त है" तो मेरा मतलब यह नहीं था कि यह _तकनीकी रूप से संभव नहीं है (बेशक यह है), लेकिन यह _व्यावहारिक रूप से पर्याप्त नहीं है। व्यवहार में, आप टाइप एब्स्ट्रैक्शन और सबटाइपिंग/कास्टेबिलिटी (या पैरामीट्रिक और गैर-पैरामीट्रिक प्रकारों के बीच) के बीच एक द्विभाजन नहीं चाहते हैं, क्योंकि यह कृत्रिम रूप से कास्ट के आधार पर संरचना को तोड़ देगा।

मैं आपके द्वारा किए जा रहे दावों को नहीं समझता।

यदि आपको अमूर्त प्रकार का मान प्राप्त होता है तो आप अभी भी इसके सटीक प्रकार को भूलना चाहेंगे, उदाहरण के लिए इसे किसी प्रकार के संघ में रखना, और बाद में इसे डाउनकास्ट के माध्यम से पुनर्प्राप्त करना। हो सकता है कि आप ऐसा किसी अन्य संदर्भ प्रकार के लिए उसी कारण से करना चाहें। टाइप एब्स्ट्रैक्शन कुछ निश्चित उपयोग पैटर्न के रास्ते में नहीं आना चाहिए जो समान प्रकार के नियमित प्रकारों के साथ मान्य हैं।

आपका उत्तर ऐसा प्रतीत होता है: तो क्या, संबंधित उपयोग साइटों पर सहायक प्रकारों में सब कुछ लपेटें, उदाहरण के लिए वेरिएंट में। लेकिन इसका मतलब पर्याप्त रैपिंग/अनरैपिंग ओवरहेड हो सकता है, इसके लिए अधिक जटिल प्रकार की सिस्टम सुविधाओं की आवश्यकता होती है, और इसका उपयोग करना अधिक जटिल होता है।

मुझे लगता है कि हमारी कई असहमति इसी पर आती है: क्या एमवीपी को संदर्भ प्रकारों के संघों का समर्थन करना चाहिए, या क्या इसे स्पष्ट प्रकार के साथ परिचय और एन्कोडिंग की आवश्यकता होनी चाहिए। बेहतर या बदतर के लिए, यूनियन विशिष्ट इंजनों के ढेर इंटरफेस के लिए एक प्राकृतिक मेल हैं, और वे आज समर्थन के लिए आसान और सस्ते हैं। वेरिएंट इतने अधिक नहीं हैं, वे बहुत अधिक शोधपूर्ण दृष्टिकोण हैं जो संभावित रूप से अतिरिक्त ओवरहेड और कम अनुमानित प्रदर्शन को प्रेरित करेंगे, कम से कम मौजूदा इंजनों में। और मैं कह रहा हूं कि एक प्रकार के सिस्टम व्यक्ति के रूप में जो अन्य परिस्थितियों में यूनियनों पर भिन्नता पसंद करता है, जैसे उपयोगकर्ता-सामना करने वाली भाषाएं। ;)

एक मेटा टिप्पणी के रूप में, मैं वास्तव में सराहना करूंगा कि मेरे सुझावों को सुनने के लिए प्राधिकरण या सीजी से अपील करने की आवश्यकता नहीं है।

क्या मैं कृपया सुझाव दे सकता हूं कि विभिन्न प्रस्तावों के बारे में बातचीत बेहतर काम कर सकती है यदि _asking_ संबंधित चैंपियन द्वारा उन चीजों के बारे में शुरू किया जाए जो स्पष्ट नहीं हैं, उदाहरण के लिए विशिष्ट तर्क या भविष्य की योजनाएं (जो हमेशा स्पष्ट या लिखित नहीं होती हैं), _मान लेने से पहले। एक उत्तर और इन मान्यताओं के आधार पर व्यापक दावे और सुझाव देना?

उत्कृष्ट। तब मुझे लगता है कि आपने देखा है कि आप वास्तव में इन दो पत्रों के लेखक हैं, यदि आप अधिक अधिकार की तलाश में हैं। :)

हां, जो इसे बेहद समस्याग्रस्त बनाता है जब आप सुझाव देते हैं कि मेरे सुझाव का दावा करने वाले कागजात काम नहीं करते हैं, भले ही आप जानते हैं कि मेरा सुझाव विशेष रूप से उन शर्तों को संबोधित करता है जिनके तहत दावा किया गया था।

व्यवहार में, आप टाइप एब्स्ट्रैक्शन और सबटाइपिंग/कास्टेबिलिटी (या पैरामीट्रिक और गैर-पैरामीट्रिक प्रकारों के बीच) के बीच एक द्विभाजन नहीं चाहते हैं, क्योंकि यह कृत्रिम रूप से कास्ट के आधार पर संरचना को तोड़ देगा।

यह एक राय है, तथ्य नहीं (इसे हमारे लिए असहमत होने के लिए पूरी तरह से उचित बनाना)। मैं कहूंगा कि बहु-भाषा प्रणालियों के लिए कोई भाषा-अज्ञेय उद्योग-टाइप असेंबली भाषा नहीं है, और इसलिए अभ्यास के बारे में दावा करना असंभव है। यह एक ऐसी चीज है जिस पर गहन (अलग) चर्चा की जानी चाहिए। उस चर्चा के लिए, आपको पहले कुछ विस्तृत केस स्टडी प्रदान करने में मदद मिलेगी ताकि सीजी ट्रेडऑफ़ की तुलना कर सके।

क्या मैं कृपया सुझाव दे सकता हूं कि विभिन्न प्रस्तावों के बारे में बातचीत बेहतर काम कर सकती है यदि संबंधित चैंपियन से उन चीजों के बारे में पूछकर शुरू किया जाए जो स्पष्ट नहीं हैं, उदाहरण के लिए विशिष्ट तर्क या भविष्य की योजनाएं (जो हमेशा स्पष्ट या लिखित नहीं होती हैं), की अनुपस्थिति को मानने से पहले एक उत्तर और इन मान्यताओं के आधार पर व्यापक दावे और सुझाव देना?

WebAssembly/प्रस्ताव-प्रकार-आयात#4, WebAssembly/प्रस्ताव-प्रकार-आयात#6, और WebAssembly/प्रस्ताव-प्रकार-आयात#7 प्रत्येक ने अनिवार्य रूप से इस योजना पर अधिक विशिष्टताओं के लिए कहा। इनमें से अंतिम ने इस मुद्दे को जीसी के पास रखा, लेकिन WebAssembly/gc#86 बताता है कि वर्तमान GC प्रस्ताव वास्तव में गतिशील अमूर्त तंत्र का समर्थन नहीं करता है।

मेटा स्तर पर, हमें इस चर्चा को अलग रखने और विषय पर ध्यान केंद्रित करने के लिए कहा गया था। मैंने अपने प्रश्न के लिए @tlively की प्रतिक्रिया को बहुत उपयोगी पाया। मुझे वास्तव में उस प्रश्न पर विशेष रूप से आपके विचार प्राप्त करने में काफी दिलचस्पी है।

@RossTate :

मैंने अपने प्रश्न के लिए @tlively की प्रतिक्रिया को बहुत उपयोगी पाया। मुझे वास्तव में उस प्रश्न पर विशेष रूप से आपके विचार प्राप्त करने में काफी दिलचस्पी है।

हम्म, मुझे लगा कि मैंने पहले ही इस पर ऊपर टिप्पणी कर दी

नहीं। मैंने सोचा था कि टिप्पणी में उनकी प्रतिक्रिया के साथ सहमति हो सकती है, लेकिन मैं पहले पुष्टि करना चाहता था। धन्यवाद!

@lukewagner , आपके क्या विचार हैं?

मैं ऊपर से सहमत हूं कि externref हमेशा के लिए एक आदिम प्रकार होगा और एक प्रकार पैरामीटर के रूप में पूर्वव्यापी रूप से पुनर्व्याख्या नहीं किया जाएगा। मुझे लगता है, यह देखते हुए, संदर्भ-प्रकार जैसा है वैसा ही अच्छा है।

मैं प्रकार आयात प्रस्ताव के दायरे का विस्तार करने के प्रस्ताव पर @rossberg को लेना चाहता हूं ताकि इसमें अमूर्त प्रकारों को लागू करने के लिए wasm की क्षमता शामिल हो। एक बार जब हम इसे कम कर सकते हैं, तो मुझे लगता है कि यह फ़ंक्शन संदर्भों और सबटाइपिंग के बारे में और चर्चा को अनब्लॉक कर देगा।

बहुत बढ़िया। फिर हम सभी एक ही पृष्ठ पर हैं (और मुझे भी लगता है कि @tlively शामिल ट्रेडऑफ़ का एक अच्छा सारांश और निर्णय के लिए तर्क प्रदान करता है)।

तो externref तत्काल नहीं होगा, और उस प्रकार के आयात के अतिरिक्त लचीलेपन की तलाश करने वाले मॉड्यूल से फीचर जारी होने पर टाइप आयात में परिवर्तित होने की उम्मीद की जाएगी। यह मेरे लिए होता है कि, उस संक्रमण को सुचारू बनाने के लिए, हमें इसे बनाने की आवश्यकता होगी ताकि (कुछ?) प्रकार का आयात डिफ़ॉल्ट रूप से externref द्वारा तत्काल किया जा सके यदि कोई तात्कालिकता प्रदान नहीं की जाती है।

और मैं टाइप इंपोर्ट के दायरे का विस्तार करने का प्रस्ताव भी लेना चाहता हूं। प्रकार के आयात के कई प्रमुख अनुप्रयोगों में अमूर्तता की आवश्यकता होती है, इसलिए अमूर्तता के लिए उस प्रस्ताव का हिस्सा बनना मेरे लिए स्वाभाविक लगता है।

इस बीच, हालांकि हमने externref के बारे में दबाव वाले प्रश्न को संबोधित किया है, आम तौर पर call_indirect बारे में अधिक क्या करना है, यह अभी भी अनसुलझा है, हालांकि इसे कैसे हल किया जा सकता है, इस पर कुछ उपयोगी चर्चा के साथ, मैं 'अभी भी इस मुद्दे को खुला छोड़ देंगे।

धन्यवाद!