Design: प्रस्ताव: अंतर-भाषा प्रकार बाइंडिंग जोड़ें

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

5 - मेमोरी लेआउट के बीच पुल

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

दो मॉड्यूल के बीच डेटा पास करते समय रूपांतरण कार्य डेवलपर के लिए पारदर्शी होना चाहिए, जब तक कि सिमेंटिक प्रकार संगत हों।

एफएफआई बाधा में डेटा पास करते समय एक लेआउट का दूसरे में पारदर्शी अनुवाद वास्तव में मेरे लिए कंपाइलर बैकएंड या भाषा रनटाइम के लिए नौकरी की तरह लगता है, और संभवतः सी/सी ++/रस्ट/आदि जैसी प्रदर्शन-संवेदनशील भाषाओं में वांछनीय नहीं है। विशेष रूप से, उन चीज़ों के लिए जिन्हें आप FFI में आगे-पीछे करने की योजना बनाते हैं, मुझे लगता है कि किसी भी प्रकार का अनुवाद करने के बजाय, एक सामान्य ABI का उपयोग करना हमेशा बेहतर होगा, क्योंकि अनुवाद की लागत बहुत अधिक होने की संभावना है। मंच के सामान्य एबीआई के अलावा किसी अन्य लेआउट को चुनने का लाभ इसके लायक होने की संभावना नहीं है, लेकिन मैं आसानी से स्वीकार करूंगा कि वैकल्पिक लेआउट से आपका क्या मतलब है, मैं गलत समझ सकता हूं।

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

क्षमा करें यदि मैंने प्रस्ताव के उद्देश्य को गलत समझा है, या कुछ महत्वपूर्ण याद किया है, जैसा कि मैंने ऊपर उल्लेख किया है, मुझे फिर से और अधिक ध्यान से पढ़ने की आवश्यकता है, लेकिन मुझे लगा कि मेरे पास कुछ समय होने पर मुझे अपने प्रारंभिक प्रश्न उठाने की आवश्यकता है।

इसके लिए भी

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

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

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

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

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

दूसरी ओर एक निर्यात/आयातित प्रकार के दो भाव होने से अपने स्वयं के मुद्दे सामने आते हैं: क्या भाषा प्रणाली को यह सत्यापित करना चाहिए कि दो अभिव्यक्ति कुछ अर्थों में सुसंगत हैं? यह काम करने की जिम्मेदारी किसकी है?

@lukewagner लिंक के लिए धन्यवाद! निश्चित रूप से खुशी है कि मुझे उस दस्तावेज़ को पढ़ने का मौका मिला!

मुझे ऐसा लगता है कि इस विशेष चर्चा में दो चीजें एक साथ मिश्रित हैं - नीचे जो कुछ लिखा गया है, उसमें से कुछ को मेरी समझ को दोबारा जांचा जा सकता है, इसलिए किसी भी चीज को इंगित करने के लिए स्वतंत्र महसूस करें जिसे मैंने गलत समझा या याद किया हो:

1. कुशल मेजबान बाइंडिंग
   
   
   
   • मूल रूप से समस्या WebIDL को हल करने का इरादा है, कम से कम ब्राउज़र वातावरण के लिए - एक इंटरफ़ेस विवरण जो मॉड्यूल-> होस्ट और होस्ट-> मॉड्यूल से मैप करता है, अनिवार्य रूप से एक से दूसरे में होस्ट इंजन में अनुवाद का काम सौंपता है। यह अनुवाद आवश्यक रूप से आदर्श होने की गारंटी नहीं है, या बिल्कुल भी अनुकूलित नहीं है, लेकिन अनुकूलन इंजन ऐसा करने के लिए इसका उपयोग कर सकते हैं। हालाँकि, अनुकूलित भी, अनुवाद अभी भी कुछ हद तक किया जाता है, लेकिन यह स्वीकार्य है क्योंकि विकल्प अभी भी अनुवाद है, बस धीमा है।
   
   
2. कुशल हेटेरोजेनस मॉड्यूल-टू-मॉड्यूल बाइंडिंग।
   
   
   
   • दूसरे शब्दों में, दो मॉड्यूल दिए गए हैं, एक source में लिखा गया है और दूसरा dest में लिखा गया है, उनके बीच प्रकार साझा करना, स्रोत से कॉल करना-> गंतव्य और/या गंतव्य-> स्रोत
   
   
   • यदि कोई सामान्य FFI उपलब्ध नहीं है, और WebIDL जैसा कुछ दिया गया है, अर्थात 1 पर पिग्गी-बैकिंग, तो भाषा अवरोधों को पार करते समय होस्ट वातावरण द्वारा प्रदान किए गए कुछ सामान्य भाजक प्रकार के माध्यम से अनुवाद करने के लिए गैर-अनुकूलित पथ होगा, उदाहरण के लिए source type -> common type -> dest type .
     
     
     
     
     
     • एक अनुकूलन इंजन सैद्धांतिक रूप से इस अनुवाद को source से dest बिना किसी बीच जाने के प्रत्यक्ष बना सकता है, लेकिन फिर भी अनुवाद ओवरहेड लगाता है।
     
     
     
   
   
   • यदि एक सामान्य FFI उपलब्ध है, अर्थात source और dest एक ABI (जैसे C ABI) साझा करते हैं, तो source और dest एक दूसरे को सीधे कॉल कर सकते हैं एफएफआई के माध्यम से कोई ओवरहेड नहीं। यह शायद व्यवहार में सबसे अधिक संभावना वाला परिदृश्य है।
   
   

तो मेरा विचार यह है कि निश्चित रूप से WebIDL, या इसके जैसा कुछ (यानी एक सुपरसेट जो होस्ट एपीआई/वातावरण के व्यापक सेट का समर्थन करता है) का लाभ उठाने के लिए निश्चित रूप से लाभ है, लेकिन यह वास्तव में केवल 1 में उल्लिखित समस्या का समाधान है, और सबसेट 2 का जो अंतर-भाषा बंधनों से संबंधित है जहां कोई एफएफआई उपलब्ध नहीं है। 2 का उपसमुच्चय जहां FFI _is_ उपलब्ध है, विकल्पों के लिए स्पष्ट रूप से बेहतर है, क्योंकि इसमें कोई ओवरहेड नहीं है।

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

मेरे पास कुछ अतिरिक्त प्रश्न हैं, यदि C FFI (उदाहरण के लिए, क्योंकि यह सबसे आम है) और IDL दोनों एक ही समय में उपयोग/उपस्थित हैं:

• यदि दोनों source और dest भाषाएं साझा प्रकार के लिए अलग-अलग प्रकार की परिभाषाएं प्रदान करती हैं, तो उनके सामान्य एबीआई के अनुसार समान अंतर्निहित इन-मेमोरी प्रतिनिधित्व (उदाहरण के लिए, एक चर-लंबाई सरणी के लिए एक सामान्य प्रतिनिधित्व) ) - क्या होस्ट इंजन उन प्रकारों के बीच केवल इसलिए अनुवाद करने का प्रयास करेगा क्योंकि IDL निर्देश मौजूद हैं, भले ही वे अपने मानक FFI का उपयोग करके एक दूसरे को सुरक्षित रूप से कॉल कर सकें?
  
  
  
  • यदि नहीं, और यह ऑप्ट-इन है, तो यह आदर्श परिदृश्य की तरह लगता है, क्योंकि आप एक ही समय में एफएफआई के साथ भाषाओं का समर्थन करते हुए, एफएफआई के बिना भाषाओं के साथ इंटरऑप का समर्थन करने के लिए आईडीएल जोड़ सकते हैं। मुझे यकीन नहीं है कि एक मेजबान इंजन कैसे काम करेगा। मैंने इसे पूरी तरह से नहीं सोचा है, इसलिए शायद मुझे कुछ याद आ रहा है
  
  
  • यदि हां, तो होस्ट इंजन प्रकार को कैसे एकीकृत करता है ?:
    
    
    
    
    
    • यदि इंजन केवल लेआउट की परवाह करता है, तो स्थिर विश्लेषण कैसे पता लगा सकता है जब कोई कॉलर कैली को गलत तर्क प्रकार प्रदान करता है? यदि उस तरह का विश्लेषण एक लक्ष्य नहीं है, तो ऐसा प्रतीत होता है कि आईडीएल वास्तव में केवल आदर्श रूप से मेजबान बाइंडिंग के लिए उपयुक्त है, और कम क्रॉस-लैंग्वेज।
    
    
    
    • यदि इंजन लेआउट से अधिक परवाह करता है, तो दूसरे शब्दों में टाइप सिस्टम को नाममात्र और संरचनात्मक संगतता दोनों की आवश्यकता होती है:
      
      
      
      
      
      
      
      • किसी फ़ंक्शन के लिए आधिकारिक प्रकार को कौन परिभाषित करता है? मैं किसी भाषा के आधिकारिक प्रकार का संदर्भ भी कैसे दूं? उदाहरण के लिए, मान लें कि मैं किसी अन्य भाषा में लिखी गई साझा लाइब्रेरी को कॉल कर रहा हूं जो add/2 फ़ंक्शन को परिभाषित करती है, और add/2 किसी प्रकार के दो तर्कों की अपेक्षा करता है size_t । मेरी भाषा आवश्यक रूप से size_t नाममात्र के बारे में नहीं जानती है, इसका मशीन-चौड़ाई वाले अहस्ताक्षरित पूर्णांकों का अपना ABI-संगत प्रतिनिधित्व है, usize , इसलिए मेरी भाषा में उस फ़ंक्शन के लिए FFI बाइंडिंग मेरा उपयोग करती है भाषाओं के प्रकार। यह देखते हुए, मेरा कंपाइलर आईडीएल उत्पन्न करने के बारे में कैसे जान सकता है जो usize से size_t मैप करता है।
      
      
      
      
    
    
    
  
  
• क्या किसी प्रोग्राम में मॉड्यूल के बीच कॉल करने के लिए उपयोग किए जाने वाले आईडीएल इंटरफेस के उदाहरण हैं, जहां एफएफआई उपलब्ध है लेकिन आईडीएल-वर्णित इंटरफेस के पक्ष में स्पष्ट रूप से अप्रयुक्त छोड़ दिया गया है? विशेष रूप से कुछ WebAssembly नहीं, ज्यादातर उन मामलों में लाभों का अध्ययन करने में रुचि रखते हैं।

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

@bitwalker

यह वाकई दिलचस्प है!

खुशी है तुझे यह पसंद है!

लेकिन मेरा पहला और सबसे महत्वपूर्ण सवाल यह पूछना होगा कि मौजूदा एफएफआई तंत्र जो कि ज्यादातर भाषाएं पहले से ही प्रदान/उपयोग करती हैं, WebAssembly के लिए पर्याप्त नहीं हैं।

C टाइप सिस्टम में अंतर-भाषा IDL के रूप में कुछ समस्याएं हैं:

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

• इसमें गतिशील लंबाई सरणियों, टैग की गई यूनियनों, डिफ़ॉल्ट मानों, जेनरिक आदि के लिए मूल समर्थन नहीं है।

• संदर्भ प्रकारों के बराबर प्रत्यक्ष नहीं है।

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

विशेष रूप से, उन चीज़ों के लिए जिन्हें आप FFI में आगे-पीछे करने की योजना बना रहे हैं

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

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

बात यह है कि अभी, आम एबीआई रैखिक स्मृति में संग्रहीत बाइट्स का एक टुकड़ा है। लेकिन भविष्य में, जब जीसी प्रस्ताव लागू किया जाता है, तो कुछ भाषाएं (जावा, सी #, पायथन) रैखिक मेमोरी में बहुत कम या कुछ भी नहीं स्टोर करती हैं। इसके बजाय, वे अपना सारा डेटा GC स्ट्रक्चर में स्टोर करेंगे। यदि इनमें से दो भाषाएं संवाद करने का प्रयास करती हैं, तो इन संरचनाओं को केवल बाइट्स की धारा में क्रमबद्ध करने के लिए उन्हें तुरंत deserialize करने के लिए अनावश्यक ओवरहेड होगा।

@KronicDeth धन्यवाद, मैं इसे देख लूंगा।

हालांकि, दस्तावेज़ को स्किम करने से, यह फ़्लैटबफ़र्स का सुपरसेट लगता है, विशेष रूप से प्रदर्शन में सुधार करने के लिए? किसी भी तरह से, इसके गुण क्या हैं जो Flatbuffers या Capnproto की तुलना में WebAssembly मॉड्यूल इंटरऑपरेबिलिटी में विशिष्ट रूप से मदद कर सकते हैं?

@lukewagner

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

माना। इस प्रस्ताव को लिखते समय मेरी धारणा यह थी कि कोई भी कैपनप्रोटो बाइंडिंग कार्यान्वयन वेबआईडीएल प्रस्ताव को लागू करने के फीडबैक पर आधारित होगा।

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

मुझे लगता है कि कैपनप्रोटो कार्यान्वयन पर चर्चा करने का मूल्य है, हालांकि, यह जल्दी भी है।

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

एन-टू-एन समस्या के संबंध में, मैं इन समाधानों पर ध्यान केंद्रित कर रहा हूं:

• केवल RPC- शैली डेटा स्थानांतरण के बारे में चिंता करें। साझा परिवर्तनशील डेटा, कक्षाएं, सूचक जीवनकाल, या किसी अन्य प्रकार की जानकारी को "एक वेक्टर में तीन फ़ील्ड: 'x', 'y', और 'z', जो सभी फ़्लोट हैं" से अधिक जटिल जानकारी को पारित करने का प्रयास न करें।

• भाषाओं को समूहबद्ध करने और मामलों को डेटा-हैंडलिंग रणनीतियों के "क्लस्टर" में उपयोग करने का प्रयास करें। इन समूहों के केंद्र में रणनीतियां स्थापित करें; भाषा संकलक किसी दी गई रणनीति से जुड़ते हैं, और दुभाषिया बाकी NxN कार्य करता है।

@fgmccabe

इसका कारण यह है कि मैं कार्य को असंभव मानता हूं। इसके दो मूलभूत कारण हैं:
ए। अलग-अलग भाषाओं में अलग-अलग शब्दार्थ होते हैं जो आवश्यक रूप से एक प्रकार के एनोटेशन में कैद नहीं होते हैं। मामले में, प्रोलॉग का मूल्यांकन सी ++ के मूल्यांकन के लिए मौलिक रूप से अलग है: उस बिंदु पर जहां भाषाएं अनिवार्य रूप से अंतःक्रियाशील नहीं हैं। (प्रोलॉग के लिए आप कई अन्य भाषाओं को स्थानापन्न कर सकते हैं)

हास्केल का कोई भी कार्यान्वयन जिसमें समर्थन प्रकार की कक्षाएं शामिल नहीं हैं, इसे प्रभावी ढंग से प्रभावित करेगा और इसे अनुपयोगी बना देगा।

हाँ, विचार एक आदर्श "सभी भाषाओं के साथ आसानी से संगत" अमूर्तता को परिभाषित नहीं करना है।

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

मुझे लगता है कि मॉड्यूल के बीच घर्षण को कम करने के लिए इन समानताओं में टैप करना संभव है। (लुकवैगनर को मेरा जवाब भी देखें)

बी। परिभाषा के अनुसार, किसी भी प्रकार की प्रणाली के किसी भी एलसीडी को किसी दी गई भाषा की सभी प्रकार की भाषा को पकड़ने की गारंटी नहीं है। यह भाषा कार्यान्वयनकर्ता को एक गहरी असहज पसंद के साथ छोड़ देता है: अपनी भाषा का समर्थन करें या अपनी भाषा की प्रकार प्रणाली के लाभों को त्याग दें।

हां। मुझे लगता है कि यहाँ अंगूठे का नियम है "यदि यह एक साझा पुस्तकालय सीमा है, तो इसे एक कैपनप्रोटो प्रकार बनाएं, अन्यथा, अपने मूल प्रकारों का उपयोग करें"।

दूसरी ओर एक निर्यात/आयातित प्रकार के दो भाव होने से अपने स्वयं के मुद्दे सामने आते हैं: क्या भाषा प्रणाली को यह सत्यापित करना चाहिए कि दो अभिव्यक्ति कुछ अर्थों में सुसंगत हैं? यह काम करने की जिम्मेदारी किसकी है?

हाँ, मैं शुरू में अपरिवर्तनीय-जांच के बारे में एक खंड और टाइप संगतता के बारे में एक और खंड शामिल करना चाहता था, लेकिन मैंने हिम्मत खो दी।

"किसकी जिम्मेदारी है" का उत्तर आमतौर पर "कैली" होता है (क्योंकि उन्हें यह मानना ​​​​चाहिए कि उन्हें प्राप्त होने वाला कोई भी डेटा संदिग्ध है), लेकिन यदि दुभाषिया यह साबित कर सकता है कि कॉलर प्रकार के इनवेरिएंट का सम्मान करता है, तो चेक को हटा दिया जा सकता है।

C प्रकार प्रणाली में अंतर-भाषा IDL के रूप में कुछ समस्याएं हैं

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

यह एक साझा पता स्थान की धारणा के तहत संचालित होता है, जो असुरक्षित और जानबूझकर WebAssembly में नहीं होता है।

इसलिए मुझे लगता है कि मैं यहां गलतफहमी का हिस्सा देखता हूं। एफएफआई के दो वर्ग हैं जिनके बारे में हम यहां बात कर रहे हैं, एक जिसमें रैखिक मेमोरी (अधिक पारंपरिक साझा मेमोरी एफएफआई) साझा करना शामिल है, और एक जो नहीं है (अधिक पारंपरिक आईपीसी/आरपीसी)। मैं पहले वाले के बारे में बात कर रहा हूं, और मुझे लगता है कि आप बाद वाले पर अधिक ध्यान केंद्रित कर रहे हैं।

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

क्रॉस-मॉड्यूल इंटरऑप जो साझा मेमोरी एफएफआई, यानी आईपीसी/आरपीसी का उपयोग नहीं करता है, निश्चित रूप से वेबआईडीएल, कैपनप्रोटो या उस नस में अन्य सुझावों में से एक के लिए एक अच्छा मैच की तरह लगता है, क्योंकि यह उनकी रोटी और मक्खन है।

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

इसमें गतिशील लंबाई सरणियों, टैग की गई यूनियनों, डिफ़ॉल्ट मानों, जेनरिक आदि के लिए मूल समर्थन नहीं है।

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

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

सहमत, आईपीसी/आरपीसी के लिए, सी इंटरफेस को परिभाषित करने के लिए एक भयानक भाषा है।

बात यह है कि अभी, आम एबीआई रैखिक स्मृति में संग्रहीत बाइट्स का एक टुकड़ा है।

यह निश्चित रूप से वह आदिम है जिसके साथ हम काम कर रहे हैं, लेकिन C ABI उसके ऊपर बहुत कुछ परिभाषित करता है।

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

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

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

हमें केवल बाइट्स के बफ़र्स का आदान-प्रदान करने का एक अधिकतम कुशल तरीका चाहिए, और भाषाओं के प्रारूप पर सहमत होने का एक तरीका है। इसे एक विशेष क्रमांकन प्रणाली में ठीक करने की आवश्यकता नहीं है। यदि Cap'n प्रोटो इस उद्देश्य के लिए सबसे उपयुक्त है, तो यह wasm द्वारा अनिवार्य होने के बजाय व्यवस्थित रूप से एक सामान्य डिफ़ॉल्ट के रूप में उत्पन्न हो सकता है।

मैं निश्चित रूप से पक्षपाती हूं, जैसा कि मैंने FlatBuffers बनाया, जो दक्षता में Cap'n Proto के समान है, लेकिन अधिक लचीला और अधिक व्यापक रूप से समर्थित है। हालाँकि मैं इस प्रारूप को wasm द्वारा अनिवार्य करने की अनुशंसा नहीं करता।

ऐसे कई अन्य प्रारूप हैं जो कुछ निश्चित उपयोग के मामलों में इन दोनों के लिए बेहतर हो सकते हैं।

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

जबकि मैं सूक्ष्म रूप से आत्म-प्रचार कर रहा हूं, मैं लोगों को फ्लेक्सबफर पर इंगित कर सकता

@aardappel

हमें केवल बाइट्स के बफ़र्स का आदान-प्रदान करने का एक अधिकतम कुशल तरीका चाहिए, और भाषाओं के प्रारूप पर सहमत होने का एक तरीका है। इसे एक विशेष क्रमांकन प्रणाली में ठीक करने की आवश्यकता नहीं है। यदि Cap'n प्रोटो इस उद्देश्य के लिए सबसे उपयुक्त है, तो यह wasm द्वारा अनिवार्य होने के बजाय व्यवस्थित रूप से एक सामान्य डिफ़ॉल्ट के रूप में उत्पन्न हो सकता है।

मैं निहित बिंदु को समझता हूं, कि wasm का उपयोग एक मानक दूसरे को अपने प्रतिस्पर्धियों को थोपने के तरीके के रूप में नहीं किया जाना चाहिए, और मैं व्यक्तिगत रूप से उदासीन हूं जिसके लिए IDL चुना जाता है।

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

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

मुझे अपील दिखाई दे रही है, मुझे नहीं लगता कि पुस्तकालय लिखते समय आप ज्यादातर यही चाहते हैं। JSON (भयानक पार्स समय से अलग) के साथ समस्या यह है कि जब आप अपने कोड में कहीं JSON ऑब्जेक्ट आयात करते हैं, तो आप अपने डेटा का उपयोग करने से पहले बहुत सारे सैनिटाइज़िंग कोड लिखना समाप्त कर देते हैं, जैसे:

assert(myObj.foo);
assert(isJsonObject(myObj.foo));
assert(myObj.foo.bar);
assert(isString(myObj.foo.bar));
loadUrl(myObj.foo.bar);

संभावित सुरक्षा कमजोरियों के साथ यदि आप नहीं करते हैं।

यह भी देखें 6 - ऊपर

@bitwalker

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

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

मुझे लगता है कि मुझे इस सूत्र पर Cap'n Proto के निर्माता के रूप में कुछ कहना चाहिए, लेकिन अजीब तरह से, मैंने यह नहीं पाया कि मेरी कोई राय है। मैं कुछ आसन्न विचार व्यक्त करता हूं जो दिलचस्प हो सकते हैं या नहीं भी हो सकते हैं।

मैं क्लाउडफ्लेयर वर्कर्स का तकनीकी नेतृत्व भी हूं, जो एक "सर्वर रहित" वातावरण है जो जावास्क्रिप्ट और डब्ल्यूएएसएम चलाता है।

हम श्रमिकों के एक दूसरे से बात करने के लिए एक प्रोटोकॉल के रूप में Cap'n Proto RPC का समर्थन करने पर विचार कर रहे हैं। वर्तमान में, वे HTTP तक सीमित हैं, इसलिए बार काफी कम सेट है। :)

वर्कर्स में, जब एक वर्कर दूसरे को कॉल करता है, तो आमतौर पर ऐसा होता है कि दोनों एक ही मशीन पर चलते हैं, यहां तक ​​कि एक ही प्रक्रिया में भी। इस कारण से, Cap'n Proto जैसा शून्य-प्रतिलिपि क्रमांकन स्पष्ट रूप से बहुत मायने रखता है, विशेष रूप से WASM वर्कर्स के लिए क्योंकि वे रैखिक मेमोरी पर काम करते हैं, जो सिद्धांत रूप में, उनके बीच शारीरिक रूप से साझा किया जा सकता है।

दूसरा, कम-ज्ञात कारण जो हमें लगता है कि यह एक अच्छा फिट है, वह है आरपीसी सिस्टम। Cap'n Proto में वादा पाइपलाइनिंग के साथ एक पूर्ण वस्तु क्षमता RPC प्रोटोकॉल है, जिसे CapTP के बाद तैयार किया गया है। इससे समृद्ध, वस्तु-उन्मुख इंटरैक्शन को सुरक्षित और प्रदर्शनकारी तरीके से व्यक्त करना आसान हो जाता है। Cap'n Proto RPC केवल एक बिंदु-से-बिंदु प्रोटोकॉल नहीं है, बल्कि किसी भी नेटवर्क वाली पार्टियों के बीच बातचीत का मॉडल है, जो हमें लगता है कि एक बहुत बड़ी बात होगी।

इस बीच WASM भूमि में, WASI एक क्षमता-आधारित API पेश कर रहा है। ऐसा लगता है कि यहाँ कुछ दिलचस्प "तालमेल" हो सकता है।

उन सभी के साथ, Cap'n प्रोटो के कई डिज़ाइन लक्ष्य FFI के विशिष्ट उपयोग के मामले में समझ में नहीं आ सकते हैं:

• Cap'n प्रोटो संदेशों को स्थिति-स्वतंत्र और सन्निहित होने के लिए डिज़ाइन किया गया है ताकि उन्हें पता स्थान के बीच प्रेषित और साझा किया जा सके। पॉइंटर्स सापेक्ष होते हैं, और संदेश में सभी ऑब्जेक्ट्स को सन्निहित मेमोरी, या कम से कम सेगमेंट में आवंटित करने की आवश्यकता होती है। यह देशी वस्तुओं की तुलना में उपयोग मॉडल को काफी जटिल बनाता है। एक ही रैखिक मेमोरी स्पेस के भीतर एफएफआई का उपयोग करते समय, यह ओवरहेड बर्बाद हो जाता है, क्योंकि आप मूल पॉइंटर्स को ढेर ऑब्जेक्ट्स को ठीक करने के लिए पास कर सकते हैं।
• Cap'n प्रोटो संदेशों को स्कीमा संस्करणों के बीच आगे और पीछे-संगत होने के लिए डिज़ाइन किया गया है, जिसमें स्कीमा को जाने बिना वस्तुओं और उप-पेड़ों को दोषरहित रूप से कॉपी करने की क्षमता शामिल है। इसके लिए कुछ प्रकाश प्रकार की जानकारी को सीधे सामग्री में संग्रहीत करने की आवश्यकता होती है, जिसे Cap'n Proto प्रत्येक सूचक पर मेटाडेटा के रूप में एन्कोड करता है। यदि FFI पर संचार करने वाले दो मॉड्यूल एक ही समय में संकलित किए जाते हैं, तो इस मेटाडेटा की कोई आवश्यकता नहीं है।
• Cap'n Proto RPC का वादा पाइपलाइनिंग, पथ-छोटा, और ऑर्डर देने की गारंटी तब समझ में आती है जब कॉलर और कैली के बीच गैर-नगण्य विलंबता होती है। एकल सीपीयू पर एफएफआई में ऐसी कोई विलंबता नहीं होती है, जिस स्थिति में वादा पाइपलाइनिंग मशीनरी शायद सिर्फ साइकिल बर्बाद करती है।

संक्षेप में, मुझे लगता है कि जब आपके पास अलग-अलग सैंडबॉक्स में स्वतंत्र रूप से तैनात मॉड्यूल एक दूसरे से बात कर रहे हैं, तो Cap'n Proto बहुत मायने रखता है। लेकिन एक ही सैंडबॉक्स में एक साथ तैनात मॉड्यूल के लिए, यह शायद अधिक है।

प्रतिपुष्टि के लिए धन्यवाद!

पॉइंटर्स सापेक्ष होते हैं, और संदेश में सभी ऑब्जेक्ट्स को सन्निहित मेमोरी, या कम से कम सेगमेंट में आवंटित करने की आवश्यकता होती है। यह देशी वस्तुओं की तुलना में उपयोग मॉडल को काफी जटिल बनाता है। एक ही रैखिक मेमोरी स्पेस के भीतर एफएफआई का उपयोग करते समय, यह ओवरहेड बर्बाद हो जाता है, क्योंकि आप मूल पॉइंटर्स को ढेर ऑब्जेक्ट्स को ठीक करने के लिए पास कर सकते हैं।

मैं नहीं जानता कि wasm (ऊपर देखें) के लिए साझा रैखिक स्मृति दृष्टिकोण कितना व्यवहार्य है।

उस ने कहा, किसी भी तरह से, मुझे नहीं लगता कि रिश्तेदार पॉइंटर्स से ओवरहेड इतना बुरा होगा। WebAssembly पहले से ही रैखिक मेमोरी की शुरुआत के सापेक्ष ऑफसेट का उपयोग करता है, और कार्यान्वयन में ज्यादातर मामलों (मुझे लगता है) में ADD निर्देशों को दूर करने के लिए तरकीबें हैं, इसलिए सापेक्ष पॉइंटर्स का उपयोग करने के ऊपरी हिस्से को शायद दूर भी अनुकूलित किया जा सकता है।

Cap'n प्रोटो संदेशों को स्कीमा संस्करणों के बीच आगे और पीछे-संगत होने के लिए डिज़ाइन किया गया है, जिसमें स्कीमा को जाने बिना वस्तुओं और उप-पेड़ों को दोषरहित रूप से कॉपी करने की क्षमता शामिल है। [...] अगर एक एफएफआई पर संचार करने वाले दो मॉड्यूल एक ही समय में संकलित किए जाते हैं, तो इस मेटाडेटा की कोई आवश्यकता नहीं है।

मुझे नहीं लगता कि यह सच है। मॉड्यूल के लिए अपनी सीमाओं पर पश्च-संगत प्रकारों को परिभाषित करने का एक तरीका होने से wasm को एक निर्भरता ट्री मॉडल का उपयोग करने की अनुमति मिलती है, जबकि ज्यादातर हास्केल की निर्भरता हीरे की समस्या से बचते हैं।

व्यर्थ ओवरहेड का एक बड़ा स्रोत यह होगा कि कैपनप्रोटो xor s उनके डिफ़ॉल्ट मानों के विरुद्ध इसके चर हैं, जो तब उपयोगी होता है जब शून्य-बाइट्स संकुचित हो जाते हैं, लेकिन शून्य-प्रतिलिपि वर्कफ़्लो में प्रति-उत्पादक होते हैं।

मैं नहीं जानता कि wasm (ऊपर देखें) के लिए साझा रैखिक स्मृति दृष्टिकोण कितना व्यवहार्य है।

आह, टीबीएच मुझे नहीं लगता कि चर्चा के उस हिस्से का अनुसरण करने के लिए मेरे पास पर्याप्त संदर्भ है। यदि आपके पास साझा पता स्थान नहीं है, तो हाँ, Cap'n Proto बहुत मायने रखता है।

मुझे इस तरह के प्रारूपों को डिजाइन करने के बारे में सलाह देने में खुशी हो रही है। एफडब्ल्यूआईडब्ल्यू कैप'एन प्रोटो में कुछ छोटी चीजें हैं जिन्हें मैं बदल दूंगा अगर मुझे उन ऐप्स के साथ संगतता की परवाह नहीं है जो आज पहले से मौजूद हैं ... यह ज्यादातर, निम्न-स्तरीय पॉइंटर एन्कोडिंग विवरण है, हालांकि।

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

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

@lukewagner "रैखिक स्मृति साझा करना" भाग पर कोई विचार?

मुझे लगता है कि रैखिक स्मृति साझा करने और साझा नहीं करने दोनों के लिए उपयोग के मामले हैं और आखिरकार टूल को दोनों का समर्थन करने की आवश्यकता है:

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

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

अंत में इसे पूरा पढ़ने के बाद, यह इस क्षेत्र में मेरी सोच की तरह लगता है (जिसमें यह टिप्पणी बॉक्स बहुत छोटा है?)

विशेष रूप से मैं अंतर-मॉड्यूल संचार समस्या के बारे में सोच रहा हूं क्योंकि स्कीमा के साथ सबसे अच्छा वर्णन किया जा रहा है। दूसरे शब्दों में, हमें Cap'nProto क्रमांकन प्रारूप की आवश्यकता नहीं है, हम केवल स्कीमा का उपयोग कर सकते हैं। इस समय विशेष रूप से Cap'nProto की स्कीमा भाषा के बारे में मेरी कोई राय नहीं है।

WASI/ESM+npm परिप्रेक्ष्य से, इस फॉर्म का समाधान मेरे लिए सबसे ज्यादा मायने रखता है। यह साझा एबीआई पर निर्भर किए बिना, एबीआई पर एक अमूर्तता है। यह अनिवार्य रूप से एक स्कीमा-लैंग एपीआई के साथ एक इंटरफ़ेस का वर्णन करने की अनुमति देता है, और इन भाषा सीमाओं को दोनों सिरों पर देशी-प्रतीत होने वाले एबीआई के साथ कॉल करता है, जिससे मेजबान को अनुवाद को संभालने की सुविधा मिलती है।

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

विशेष रूप से मैं अंतर-मॉड्यूल संचार समस्या के बारे में सोच रहा हूं क्योंकि स्कीमा के साथ सबसे अच्छा वर्णन किया जा रहा है। दूसरे शब्दों में, हमें [ए] क्रमांकन प्रारूप की आवश्यकता नहीं है, हम केवल स्कीमा का उपयोग कर सकते हैं।

मैं पूर्व से सहमत हूं, लेकिन मुझे यकीन नहीं है कि बाद वाला अनुसरण करता है। स्कीमा कौन लागू करता है? यहां तक ​​​​कि अगर मेजबान परिवहन करता है, तो किसी बिंदु पर आपको परिभाषित करना होगा कि वास्तव में दोनों सिरों पर वासम मूल्य/बाइट्स का उपभोग/उत्पादन किया जाता है, और प्रत्येक मॉड्यूल को अपना डेटा उस रूप में लाना होता है जिसे मेजबान समझता है। यहां तक ​​कि कई रूप उपलब्ध भी हो सकते हैं, लेकिन फिर भी यह क्रमांकन प्रारूप से भिन्न नहीं है, बस थोड़ा अधिक उच्च-स्तरीय है।

सी से जंग को निम में कुशलतापूर्वक परिवर्तित करना संभव होना चाहिए, सी से हास्केल में अधिक ओवरहेड होना डीलब्रेकर नहीं है।

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

और यहां "हास्केल" हर उच्च-स्तरीय भाषा के लिए बस एक स्टैंड-इन है। अधिकांश भाषाएं सी-जैसी नहीं हैं।

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

सी-जैसी भाषाओं को विशेषाधिकार देने का मतलब है कि हास्केल इस अमूर्तता का उपयोग हास्केल मॉड्यूल के लिए नहीं करेगा, क्योंकि ओवरहेड प्रेरित है। बदले में इसका मतलब है कि यह अपने स्वयं के पुस्तकालयों के लिए समान "एनपीएम" पारिस्थितिकी तंत्र में भाग नहीं लेगा।

और यहां "हास्केल" हर उच्च-स्तरीय भाषा के लिए बस एक स्टैंड-इन है। अधिकांश भाषाएं सी-जैसी नहीं हैं।

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

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

@PoignardAzur , उनका अनुवाद करना मुश्किल नहीं है, लेकिन उन्हें प्रत्येक क्रॉस-मॉड्यूल कॉल के दोनों सिरों पर सभी तर्कों/परिणामों को कॉपी (क्रमबद्ध/deserialise) करने की आवश्यकता है। स्पष्ट रूप से, आप प्रत्येक भाषा-आंतरिक पुस्तकालय कॉल के लिए उस लागत का भुगतान नहीं करना चाहते हैं।

हास्केल में विशेष रूप से आपके पास अतिरिक्त समस्या है कि नकल करना आलस्य के शब्दार्थ के साथ असंगत है। अन्य भाषाओं में यह स्टेटफुल डेटा के साथ असंगत हो सकता है।

स्कीमा कौन लागू करता है? यहां तक ​​​​कि अगर मेजबान परिवहन करता है, तो किसी बिंदु पर आपको परिभाषित करना होगा कि वास्तव में दोनों सिरों पर वासम मूल्य/बाइट्स का उपभोग/उत्पादन किया जाता है, और प्रत्येक मॉड्यूल को अपना डेटा उस रूप में लाना होता है जिसे मेजबान समझता है। यहां तक ​​कि कई रूप उपलब्ध भी हो सकते हैं, लेकिन फिर भी यह क्रमांकन प्रारूप से भिन्न नहीं है, बस थोड़ा अधिक उच्च-स्तरीय है।

होस्ट स्कीमा को लागू करता है। स्कीमा बाइट्स का बिल्कुल भी वर्णन नहीं करता है, और इसे एक कार्यान्वयन विवरण देता है। यह वेबआईडीएल बाइंडिंग प्रस्ताव के डिजाइन से उधार ले रहा है, जिसमें दिलचस्प बिट सी स्ट्रक्चर से वेबआईडीएल प्रकारों में रूपांतरण में है। इस प्रकार का डिज़ाइन WebIDL प्रकारों के बजाय Wasm Abstract Interface Types (मैं संक्षिप्त नाम: WAIT का सुझाव देता हूं) का उपयोग करता है। वेबआईडीएल प्रस्ताव में हमें "वेबआईडीएल में अनुवादित" होने पर डेटा के बाइनरी प्रतिनिधित्व की आवश्यकता नहीं है या अनिवार्य नहीं है, क्योंकि हम बीच में बिना रुके सीधे वासम से ब्राउज़र एपीआई तक जाने में सक्षम होना चाहते हैं।

सी-जैसी भाषाओं को विशेषाधिकार देने का मतलब है कि हास्केल इस अमूर्तता का उपयोग हास्केल मॉड्यूल के लिए नहीं करेगा, क्योंकि ओवरहेड प्रेरित है।

ओह, 100% सहमत हूँ। मुझे इसे और अधिक स्पष्ट करने के लिए उदाहरण समाप्त करना चाहिए था: इस बीच, हास्केल से एल्म से सी # समान रूप से कुशल हो सकता है (मान लीजिए कि वे वासम जीसी प्रकारों का उपयोग करते हैं), लेकिन सी # से जंग में ओवरहेड हो सकता है। मुझे नहीं लगता कि भाषा प्रतिमानों में कूदते समय ओवरहेड से बचने का कोई तरीका है।

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

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

कॉल चेन से मेरा मतलब है:

1. सी -> जंग -> ज़िग -> फोरट्रान, कुशल
2. हास्केल -> सी # -> हास्केल, कुशल
3. सी -> हास्केल -> जंग -> योजना, अक्षम
4. जावा -> जंग, अक्षम

और यहां "हास्केल" हर उच्च-स्तरीय भाषा के लिए बस एक स्टैंड-इन है। अधिकांश भाषाएं सी-जैसी नहीं हैं।

हां, हास्केल को एक ठोस भाषा के रूप में उपयोग करने के पीछे मेरा इरादा था। (हालांकि निम शायद सी-जैसी भाषा का एक बुरा उदाहरण था क्योंकि यह जीसी का भी भारी उपयोग करता है)

--

अमूर्त प्रकारों के बारे में सोचने का एक और तरीका आईआर के रूप में है। जिस तरह एलएलवीएम कई-से-एक-से-अनेक संबंध (कई भाषाएं -> एक आईआर -> कई लक्ष्य) का वर्णन करता है, उसी तरह अमूर्त प्रकार भाषाओं के कई-से-कई मैपिंग में मध्यस्थता कर सकते हैं + मेजबान -> भाषा + मेजबान। इस डिज़ाइन स्पेस में कुछ N^2 मैपिंग समस्या लेता है और इसे N+N में बदल देता है।

होस्ट स्कीमा को लागू करता है।

खैर, यह पर्याप्त नहीं हो सकता है, प्रत्येक मॉड्यूल को कुछ लागू

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

खैर, यह पर्याप्त नहीं हो सकता है, प्रत्येक मॉड्यूल को कुछ लागू करना होगा ताकि होस्ट डेटा ढूंढ सके। यदि होस्ट सी लेआउट की अपेक्षा करता है तो आपको इस सी लेआउट को परिभाषित करना होगा

मेजबान को कुछ भी उम्मीद नहीं समर्थन करने की जरूरत है। अधिक संक्षेप में, एक उदाहरण उदाहरण के रूप में वेबिडल-बाइंडिंग प्रस्ताव का उपयोग करते हुए , हमारे पास utf8-cstr और utf8-str , जो क्रमशः i32 (ptr) और i32 (ptr), i32 (len) लेते हैं। उनके बीच ठोस रूप से मानचित्र बनाने में सक्षम होने के लिए "मेजबान आंतरिक रूप से इसे सी-स्ट्रिंग्स के रूप में दर्शाता है" में अनिवार्य करने की कोई आवश्यकता नहीं है।
तो, प्रत्येक मॉड्यूल कुछ लागू करता है, हां, लेकिन डेटा के प्रतिनिधित्व को सार डेटा/स्कीमा परत में व्यक्त करने की आवश्यकता नहीं है, इस प्रकार यह हमें उस डेटा लेआउट पर अमूर्त करने की संपत्ति देता है।
इसके अतिरिक्त, यह बाइंडिंग लेयर पर एक्स्टेंसिबल है जो कंक्रीट वासम प्रकार और अमूर्त मध्यवर्ती प्रकारों के बीच मैप करता है। हास्केल समर्थन जोड़ने के लिए (जो मॉडल वर्णों और वर्णों के सरणी दोनों की विपक्ष सूची के रूप में तार करते हैं), हम utf8-cons-str और utf8-array-str बाइंडिंग जोड़ सकते हैं, जो उम्मीद करते हैं (और मान्य) wasm प्रकार (वर्तमान का उपयोग करके) gc प्रस्ताव सिंटैक्स) (type $haskellString (struct (field i8) (field (ref $haskellString)))) और (type $haskellText (array i8)) ।

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

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

आप जो वर्णन कर रहे हैं वह मेरे मन में एक बड़ी चेतावनी के साथ काफी करीब है: स्कीमा में संभावित अभ्यावेदन की एक छोटी, निश्चित संख्या होनी चाहिए। विभिन्न अभ्यावेदन के बीच ब्रिजिंग एक एन * एन समस्या है, जिसका अर्थ है कि वीएम लेखकों पर अधिक बोझ से बचने के लिए अभ्यावेदन की संख्या को छोटा रखा जाना चाहिए।

इसलिए हास्केल समर्थन जोड़ने के लिए मौजूदा बाइंडिंग का उपयोग करने की आवश्यकता होगी, कस्टम बाइंडिंग जोड़ने की नहीं।

कुछ संभावित प्रतिनिधित्व:

• सी-स्टाइल स्ट्रक्चर और पॉइंटर्स।
• वास्तविक कैपनप्रोटो बाइट्स।
• जीसी कक्षाएं।
• गेटर्स और सेटर्स के रूप में काम करने वाले क्लोजर।
• पायथन-शैली के शब्दकोश।

विचार यह है कि जबकि प्रत्येक भाषा अलग है, और कुछ चरम बाहरी हैं, आप काफी कम संख्या में श्रेणियों में काफी बड़ी संख्या में भाषाओं को फिट कर सकते हैं।

इसलिए हास्केल समर्थन जोड़ने के लिए मौजूदा बाइंडिंग का उपयोग करने की आवश्यकता होगी, कस्टम बाइंडिंग जोड़ने की नहीं।

आप जिस मौजूदा बाइंडिंग के बारे में सोच रहे हैं, उसकी ग्रैन्युलैरिटी के स्तर पर निर्भर करता है। N<->N भाषाएं प्रत्येक संभावित बाइंडिंग को 2*N*N एन्कोडिंग करती हैं, लेकिन N<->IR 2*N है, और आगे यदि आप N<->[common बाइंडिंग स्टाइल]<->IR कहते हैं, जहां संख्या सामान्य स्वरूपों में k है, आप 2*k बात कर रहे हैं, जहाँ k < N.

विशेष रूप से, मेरे द्वारा वर्णित योजना के साथ, आपको योजना मुफ्त में मिलती है (यह utf8-cons-str पुन: उपयोग करेगी)। यदि जावा मॉडल चार सरणियों के रूप में भी तार करता है, तो यह utf8-array-str बाध्यकारी है। यदि निम हुड के नीचे string_views का उपयोग करता है, तो utf8-str । यदि Zig C ABI के अनुरूप है, तो utf8-cstr . (मैं जावा/निम/ज़िग के एबीआई नहीं जानता, इसलिए मैंने उन्हें पहले ठोस उदाहरण के रूप में उल्लेख नहीं किया था)

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

इसके अलावा, मैं यह भी कहूंगा कि हम डेटा की किसी एक शैली को विशेषाधिकार देने से बचने के लिए, प्रति सार प्रकार के लिए कई बाइंडिंग निर्दिष्ट करना चाहते हैं। यदि हम स्ट्रिंग्स के लिए एकमात्र बाध्यकारी utf8-cstr , तो सभी गैर-सी-एबीआई- वाली भाषाओं को उस बेमेल से निपटना होगा। मैं वीएम लेखन जटिलता को बढ़ाने के साथ ठीक हूं, कुछ छोटे कारक नहीं हैं।
पारिस्थितिकी तंत्र में कुल कार्य ओ (वीएम प्रयास + भाषा कार्यान्वयन प्रयास) है, और ये दोनों शब्द किसी तरह से एन = भाषाओं की संख्या के साथ स्केल करते हैं। एम = एम्बेडर्स की संख्या, के = बाइंडिंग की संख्या, और ए = बाइंडिंग की औसत संख्या को किसी दिए गए भाषा को लागू करने की आवश्यकता होती है, एक <= के साथ। कम से कम हमारे पास M+N अलग wasm कार्यान्वयन हैं।
निष्पक्ष दृष्टिकोण, प्रत्येक एन भाषा के साथ स्वतंत्र रूप से एबीआई एफएफआई को हर दूसरी एन भाषा के साथ लागू करने के साथ, ओ (एम + एन * एन) है। यह वही है जो हमारे पास देशी प्रणालियों पर है, जो एक मजबूत संकेत है कि कोई भी ओ (एन * एन) परिणाम मूल प्रणालियों से अलग नहीं होगा।
दूसरा भोला दृष्टिकोण, जहां प्रत्येक वीएम को सभी एन * एन बाइंडिंग लागू करने की आवश्यकता होती है: ओ (एम * एन * एन + एन), जो स्पष्ट रूप से और भी बदतर है।
हम जो प्रस्ताव देने की कोशिश कर रहे हैं, वह यह है कि हमारे पास k बाइंडिंग है जो एक अमूर्त भाषा के बीच का नक्शा है, जो सभी भाषाओं में वापस मैप करता है। इसका तात्पर्य प्रत्येक VM के लिए k कार्य है। प्रत्येक भाषा के लिए, हमें केवल बाइंडिंग के सबसेट को लागू करने की आवश्यकता होती है। कुल कार्य M*k + N*a है, जो O(M*k + N*k) है। ध्यान दें कि इस घटना में कि के = एन कि वीएम पक्ष "केवल" एम * एन है, इसलिए किसी दिए गए वीएम के लिए यह भाषाओं की संख्या में "केवल" रैखिक है। स्पष्ट रूप से हालांकि हम k << N चाहते हैं, क्योंकि अन्यथा यह अभी भी O(N*N) है, पहले समाधान से बेहतर नहीं है।
फिर भी, ओ (एम * के + एन * के) अधिक स्वादिष्ट है। यदि k, O(1) है, तो यह पूरे पारिस्थितिकी तंत्र को कार्यान्वयन की संख्या में रैखिक बनाता है, जो कि शामिल प्रयासों की मात्रा पर हमारी निचली सीमा है। एक अधिक संभावना बाध्य है के ओ (लॉग (एन)) है, जिसे मैं अभी भी बहुत संतुष्ट हूं।

जो कहने का एक लंबा रास्ता है, मैं इस सुविधा के लिए वीएम जटिलता को कुछ स्थिर कारक से बढ़ाने के साथ पूरी तरह से ठीक हूं।

हम अधिकांश भाषाओं को कवर करने के लिए प्रति IR प्रकार में कुछ बाइंडिंग जोड़ सकते हैं।

यह महत्वपूर्ण अंतर्निहित धारणा है जो मुझे विश्वास है कि यह सच नहीं है। मेरा अनुभव यह है कि भाषा कार्यान्वयन के रूप में कई प्रतिनिधित्व विकल्प हैं (कम से कम!)। और वे मनमाने ढंग से जटिल हो सकते हैं।

V8 लें, जिसमें अकेले स्ट्रिंग के लिए कुछ दर्जन (!) प्रतिनिधित्व हैं, जिसमें विभिन्न एन्कोडिंग, विषम रस्सियां ​​​​आदि शामिल हैं।

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

अन्य भाषाएं एक स्ट्रिंग की लंबाई के लिए अजीब प्रतिनिधित्व का उपयोग करती हैं, या इसे स्पष्ट रूप से संग्रहीत नहीं करती हैं, लेकिन इसकी गणना करने की आवश्यकता होती है।

ये दो उदाहरण पहले से ही दिखाते हैं कि एक घोषणात्मक डेटा लेआउट इसे काटता नहीं है, आपको अक्सर रनटाइम कोड का आह्वान करने में सक्षम होना चाहिए, जिसके बदले में अपने स्वयं के कॉलिंग सम्मेलन हो सकते हैं।

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

और फिर प्राप्त करने वाला पक्ष है, जहां आपको इन सभी डेटा संरचनाओं को बनाने में सक्षम होना होगा!

इसलिए मुझे लगता है कि यह पूरी तरह से अवास्तविक है कि हम कभी भी "विशाल बहुसंख्यक भाषाओं" का समर्थन करने के करीब भी पहुंच जाएंगे। इसके बजाय, हम कुछ को विशेषाधिकार देना शुरू कर देंगे, जबकि पहले से ही मनमाने सामान का एक बड़ा चिड़ियाघर विकसित कर रहे हैं। यह कई स्तरों पर घातक लगता है।

मेरा अनुभव यह है कि भाषा कार्यान्वयन के रूप में कई प्रतिनिधित्व विकल्प हैं (कम से कम!)। और वे मनमाने ढंग से जटिल हो सकते हैं।

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

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

वास्तव में, आप केवल एक डेटा प्रकार के साथ बहुत दूर जा सकते हैं: सूचक + लेन जोड़ी। फिर आपको बस एक "स्कीमा" चाहिए जो कहती है कि उन बाइट्स में क्या है। क्या यह UTF-8 के अनुरूप होने का वादा करता है? क्या अंतिम बाइट की गारंटी हमेशा 0 होती है? क्या पहले 4/8 बाइट लंबाई/क्षमता फ़ील्ड हैं? क्या ये सभी बाइट्स लिटिल एंडियन फ्लोट्स हैं जिन्हें सीधे वेबजीएल पर भेजा जा सकता है? क्या ये बाइट शायद मौजूदा क्रमांकन प्रारूप की स्कीमा एक्स हैं? आदि?

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

यह महत्वपूर्ण अंतर्निहित धारणा है जो मुझे विश्वास है कि यह सच नहीं है। मेरा अनुभव यह है कि भाषा कार्यान्वयन के रूप में कई प्रतिनिधित्व विकल्प हैं (कम से कम!)। और वे मनमाने ढंग से जटिल हो सकते हैं।

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

बाइंडिंग सभी भाषा अभ्यावेदन को पूरी तरह से मैप करने के लिए नहीं हैं, उन्हें केवल सभी भाषाओं में पर्याप्त रूप से मैप करने की आवश्यकता

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

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

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

ये दो उदाहरण पहले से ही दिखाते हैं कि एक घोषणात्मक डेटा लेआउट इसे काटता नहीं है, आपको अक्सर रनटाइम कोड का आह्वान करने में सक्षम होना चाहिए, जिसके बदले में अपने स्वयं के कॉलिंग सम्मेलन हो सकते हैं।

मॉडल करने का तरीका, भले ही हम बाइंडिंग कैसे निर्दिष्ट करते हैं (या यहां तक ​​​​कि अगर हम बाइंडिंग के लिए कुछ भी निर्दिष्ट करते हैं), उपयोगकर्तालैंड में इसे संभालना है। यदि किसी भाषा का किसी प्रकार का प्रतिनिधित्व सीधे बाध्यकारी के लिए मैप नहीं करता है, तो उसे उस प्रतिनिधित्व में कनवर्ट करने की आवश्यकता होगी जो करता है। उदाहरण के लिए यदि हास्केल के स्ट्रिंग्स को वास्तव में (type $haskellString (struct (field i8) (field (func (result (ref $haskellString)))))) रूप में दर्शाया गया है, तो इसे या तो एक सख्त स्ट्रिंग में कनवर्ट करने और स्कीम-जैसी बाइंडिंग का उपयोग करने की आवश्यकता होगी, या टेक्स्ट ऐरे में और जावा-जैसी बाइंडिंग का उपयोग करना होगा, या ए CFFIString और C- जैसे बाइंडिंग का उपयोग करें। कई अपूर्ण बाध्यकारी प्रकार होने का मूल्य प्रस्ताव यह है कि उनमें से कुछ दूसरों की तुलना में हास्केल के लिए कम अजीब हैं, और संकलक को संशोधित करने की आवश्यकता के बिना Wasm-FFI प्रकारों का निर्माण करना संभव है।

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

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

इसके बजाय, हम कुछ को विशेषाधिकार देना शुरू कर देंगे

लगभग-निश्चित रूप से। सवाल यह है कि कुछ बेहतर समर्थित भाषाओं को किस हद तक विशेषाधिकार प्राप्त हैं? एक एर्गोनोमिक समाधान खोजने में वंचित भाषाओं के पास कितनी छूट है?

जबकि पहले से ही मनमाना सामान का एक बड़ा चिड़ियाघर बढ़ रहा है।

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

@aardappel लघु संस्करण यह है कि यह मेरी बैकअप योजना है यदि घोषणात्मक सार दृष्टिकोण विफल हो जाता है: पूरी तरह से विपरीत दिशा में जाएं और एक क्रमबद्ध प्रारूप का वर्णन करें। अवलोकन किया जाता है कि वेब स्वयं लगभग पूरी तरह से टेक्स्ट पर बनाया गया है, क्योंकि यह एक अत्यंत निम्न सामान्य भाजक है। टेक्स्ट सभी टूल्स द्वारा तुच्छ रूप से समझ में आता है, और इसलिए इसके ऊपर वेब जैसा कुछ संभव है।

डेटा-इन-बफ़र्स के साथ मेरी सबसे बड़ी चिंता है जो उस दृष्टिकोण को अट्रैक्टिव बना सकती है, हम संदर्भ प्रकारों को कैसे संभाल सकते हैं? मेरे पास सबसे अच्छा विचार है कि तालिकाओं को साझा करना और उनमें सूचकांकों को क्रमबद्ध करना, लेकिन मेरे पास पूरी तस्वीर नहीं है कि यह वास्तव में कितनी अच्छी तरह काम करेगा।

@ jgravelle-google शायद संदर्भ प्रकारों को अलग रखा जाना चाहिए? तो एक दिया गया कार्य कच्चे हस्ताक्षर ref ref i32 i32 i32 i32 हो सकता है जो वास्तव में 2 किसी भी प्रकार के 2 बफर के बाद एक विशेष प्रकार के 2 बफर (उपरोक्त काल्पनिक स्कीमा में निर्दिष्ट) है।

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

डेटा-इन-बफ़र्स के साथ मेरी सबसे बड़ी चिंता है जो उस दृष्टिकोण को अट्रैक्टिव बना सकती है, हम संदर्भ प्रकारों को कैसे संभाल सकते हैं? मेरे पास सबसे अच्छा विचार है कि तालिकाओं को साझा करना और उनमें सूचकांकों को क्रमबद्ध करना, लेकिन मेरे पास पूरी तस्वीर नहीं है कि यह वास्तव में कितनी अच्छी तरह काम करेगा।

यही एक कारण है कि मैंने कैपनप्रोटो को एन्कोडिंग के रूप में प्रस्तावित किया। संदर्भ तालिकाएँ कमोबेश अंतर्निहित हैं।

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

आपकी प्रतिक्रिया के लिए सभी को धन्यवाद।

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

अब तक की प्रतिक्रिया को संक्षेप में प्रस्तुत करने के लिए:

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

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

• @lukewagner ने ईएसएम एकीकरण के साथ संयुक्त रूप से परस्पर अविश्वास मॉड्यूल को जोड़ने वाले मॉड्यूल सिस्टम की क्षमता के लिए कुछ उत्साह व्यक्त किया है। प्रस्ताव का अगला पुनरावृत्ति उस क्षमता पर विस्तारित होना चाहिए; विशेष रूप से, मेरा मानना ​​​​है कि एक पश्च-संगत प्रकार की प्रणाली होने से wasm को npm जैसी निर्भरता ट्री मॉडल का उपयोग करने की अनुमति मिलती है, जबकि निर्भरता हीरे की समस्या का खामियाजा भुगतना पड़ता है।

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

• कई पाठकों ने अंतर-भाषा प्रकार की प्रणाली की व्यवहार्यता के बारे में चिंता व्यक्त की। इन चिंताओं को कुछ हद तक अस्पष्ट और परिभाषित करना कठिन है, आंशिक रूप से क्योंकि विषय वस्तु बहुत सारगर्भित है, आंशिक रूप से क्योंकि प्रस्ताव अब तक बहुत अस्पष्ट है, जो करता है। विशिष्ट विफलता राज्यों में शामिल हैं:

  • अत्यधिक दृश्यमान भाषाओं पर बहुत अधिक ध्यान केंद्रित करना, अधिक विशिष्ट भाषाओं को पीछे छोड़ना।
  • एक टपका हुआ अमूर्त होना जो बहुत सामान्य होने की कोशिश करता है, लेकिन किसी के उपयोग के मामले को आसानी से या कुशलता से कवर नहीं करता है।
  • बहुत सारे मामलों को कवर करना, एक फूला हुआ N*N कार्यान्वयन बनाना जो अभी भी उपरोक्त समस्याओं से ग्रस्त है।

अगले प्रस्ताव पुनरावृत्ति को इन चिंताओं को एक या दूसरे तरीके से संबोधित करने की आवश्यकता है।

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

साथ ही, जैसा कि पाठकों ने बताया है, प्रस्ताव वर्तमान में एक प्रकार के स्कीमा के विचार को इसके प्रतिनिधित्व के विचार के साथ उलझाता है। जबकि प्रस्ताव एक प्रतिनिधित्व प्रारूप की आवश्यकताओं को निर्धारित करने का एक उचित काम करता है, इसे पहले एक सार प्रकार की स्कीमा की आवश्यकताओं को पूरा करने की आवश्यकता होती है।

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

@ jgravelle-गूगल:

मॉडल करने का तरीका, भले ही हम बाइंडिंग कैसे निर्दिष्ट करते हैं (या यहां तक ​​​​कि अगर हम बाइंडिंग के लिए कुछ भी निर्दिष्ट करते हैं), उपयोगकर्तालैंड में इसे संभालना है।

हां, मैं सहमत हूं, और मेरा तर्क @aardappel के समान है: यदि वैसे भी हमें आम तौर पर ऐसा ही करना है तो हमें बस इसे स्वीकार करना चाहिए और कुछ विषम मामलों को सुधारने के लिए तदर्थ चीजों की कोशिश नहीं करनी चाहिए। Userland वह जगह है जहां रूपांतरण संबंधित है, Wasm में बाकी सब चीजों की भावना में।

मैं उलझन में हूं, मैं देख रहा हूं कि "भाषाओं के बीच बंधन पूरी तरह से असंभव है इसलिए हमें बिल्कुल भी कोशिश नहीं करनी चाहिए,"

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

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

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

हम संदर्भ प्रकारों को कैसे संभाल सकते हैं?

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

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

@PoignardAzur :

एक तरफ के रूप में, मैं हास्केल से अपरिचित हूं, लेकिन स्ट्रिंग की आलसी सूचियों के रूप में स्ट्रिंग का विचार मेरे दिमाग को उड़ा देता है।

हाँ, मेरा मानना ​​है कि आजकल इसे व्यापक रूप से एक गलती माना जाता है। लेकिन यह दर्शाता है कि "सरल" डेटा प्रकारों के लिए भी कितनी विविधता है।

@ रोसबर्ग

मुझे लगता है कि भाषाओं के बीच डेटा इंटरऑप के लिए डीडीएल (टाइप स्कीम) को परिभाषित करना पूरी तरह से वांछनीय है। मुझे नहीं लगता कि वासम में रूपांतरण बनाना संभव है। रूपांतरणों को यूजरलैंड में लागू करने की आवश्यकता है।

मैं सहमत हूं, और उसमें जोड़ने के लिए: मैं इसके लिए wasm कल्पना में कुछ जोड़ने के बारे में संदेह कर रहा हूं क्योंकि मुझे नहीं लगता कि wasm को अन्य प्लेटफार्मों की तुलना में एक अंतर-भाषा समाधान की अधिक करने की अधिक @aardappel के रूप में बफ़र्स का उल्लेख किया गया है। (लेकिन मुझे लगता है कि यूजरस्पेस में प्रयोग बहुत दिलचस्प है, क्योंकि यह सभी प्लेटफॉर्म पर है!)

कम से कम वेब पर एक विशेष चीज है, स्ट्रिंग्स और एरेज़ के लिए जावास्क्रिप्ट/वेब एपीआई प्रकार और आगे। उनके साथ बातचीत करने में सक्षम होना स्पष्ट रूप से महत्वपूर्ण है।

मुझे नहीं लगता कि अन्य प्लेटफार्मों की तुलना में वासम को एक अंतर-भाषा समाधान की अधिक आवश्यकता है

मुझे लगता है कि यह करता है। डिफ़ॉल्ट रूप से वेब पर उपयोग किए जाने का अर्थ है कि कोड को विभिन्न संदर्भों में चलाया जा सकता है और चलाया जाएगा। उसी तरह जैसे कोई <script src="http://some.other.site/jquery.js"> हो सकता है, मुझे लोगों को एक क्रॉस-ऑरिजिनल तरीके से वासम लाइब्रेरी को मिलाते हुए देखना अच्छा लगेगा। वेब द्वारा प्रदान की जाने वाली क्षणिकता और कंपोज़ेबिलिटी गुणों के कारण, विदेशी मॉड्यूल के साथ इंटरफेस करने में सक्षम होने का मूल्य-जोड़ देशी सिस्टम पर पहले की तुलना में अधिक है।

और मुझे नहीं लगता कि अन्य प्लेटफार्मों की तुलना में इस तरह के समाधान को लागू करने के लिए wasm की अधिक क्षमता है।

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

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

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

(और क्या वह एनपीएम या डब्ल्यूएपीएम या कुछ अभी तक बनाए गए पैकेज मैनेजर हैं?)

मुझे लगता है कि डब्ल्यूएपीएम के लिए एक व्यवहार्य पैकेज मैनेजर बनना बहुत जल्द है। हमें ईएसएम एकीकरण, WASI और कुछ प्रकार की अंतर-भाषा बाइंडिंग जैसी सुविधाओं की आवश्यकता होती है, इससे पहले कि एक wasm पैकेज मैनेजर संभव हो जाए।

वैसे भी, मुझे नहीं लगता कि डब्ल्यूएपीएम में निर्भरता प्रबंधन भी है।

मुझे नहीं लगता कि अन्य प्लेटफार्मों की तुलना में वासम को एक अंतर-भाषा समाधान की अधिक आवश्यकता है

मुझे लगता है कि यह करता है। डिफ़ॉल्ट रूप से वेब पर उपयोग किए जाने का अर्थ है कि कोड को विभिन्न संदर्भों में चलाया जा सकता है और चलाया जाएगा। उसी तरह जिससे कोई हो सकता है

रूपांतरणों को यूजरलैंड में लागू करने की आवश्यकता है। बाध्यकारी परत केवल एक प्रारूप निर्धारित करती है जिसे उपयोगकर्ता कोड को उत्पादन/उपभोग करना होता है।

यह मेरे लिए एक अच्छा सारांश है।

जब मैं एक नया मसौदा लिख ​​रहा हूं, तो इस धागे पर मेरे पास सभी के लिए एक खुला प्रश्न है:

क्या कोई मौजूदा पुस्तकालय है, अगर इसे WebAssembly में संकलित किया गया था, तो आप किसी भी भाषा से उपयोग करने में सक्षम होना चाहेंगे?

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

@PoignardAzur सी में बहुत सी भाषाएं समान पर्ल-संगत नियमित अभिव्यक्ति (पीसीआरई) पुस्तकालयों का उपयोग करती हैं, लेकिन ब्राउज़र एम्बेडिंग में उन्हें शायद जेएस के रेगेक्स एपीआई का उपयोग करना चाहिए।

@PoignardAzur BoringSSL और libsodium दिमाग में आते हैं।

इसके अलावा Cap'n प्रोटो आरपीसी कार्यान्वयन, लेकिन यह एक अजीब है: Cap'n प्रोटो की _serialization_ परत वास्तविक रूप से प्रत्येक भाषा में स्वतंत्र रूप से लागू की जानी चाहिए क्योंकि इसमें से अधिकांश एक विस्तृत-लेकिन-उथली एपीआई परत है जिसे मुहावरेदार और इनलाइन होने की आवश्यकता है - मैत्रीपूर्ण। RPC परत, OTOH, संकीर्ण लेकिन गहरी है। सिद्धांत रूप में एफएफआई सीमा पर कैपन-एन्कोडेड बाइट सरणी संदर्भों को पारित करके किसी भी मनमानी भाषा के क्रमिकरण कार्यान्वयन के पीछे सी ++ आरपीसी कार्यान्वयन का उपयोग करना संभव होना चाहिए ...

मुझे लगता है कि जो प्रस्तावित है उसे करने के लिए अंततः वेब असेंबली में कुछ काफी आक्रामक परिवर्तनों की आवश्यकता होगी क्योंकि यह पहले से मौजूद है - लेकिन तर्कसंगत रूप से इसके लायक हो सकता है।

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

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

मैंने https://github.com/WebAssembly/webidl-bindings/issues/40 खोला है, जिसने मुझे यहां एक प्रश्न पूछने के लिए प्रेरित किया क्योंकि मैंने इसका कोई उल्लेख नहीं देखा है (या मैंने इसे याद किया)।

पूरी बाध्यकारी कहानी में, यह स्पष्ट नहीं है कि "कौन" बाइंडिंग उत्पन्न करने के लिए जिम्मेदार है:

• क्या यह एक कंपाइलर है (जो एक प्रोग्राम को वासम मॉड्यूल में बदल देता है)?
• क्या यह एक प्रोग्राम लेखक है (और इसलिए, क्या बाइंडिंग हाथ से लिखी गई है)?

मुझे लगता है कि दोनों मान्य हैं। और वेब आईडीएल के मामले में, ऐसा लगता है कि यह कुछ सीमाएं दिखाता है (उपरोक्त लिंक देखें)। हो सकता है कि मैं इस प्रक्रिया में एक महत्वपूर्ण कदम से चूक गया, और इसलिए, मेरे संदेश को भूल जाने पर विचार करें।

भले ही वेब आईडीएल को कम वेब-केंद्रित करने के लिए "फिर से फोकस" करने का लक्ष्य है, अभी, यह बहुत वेब-केंद्रित है। और विकल्प प्रस्तावित करने के लिए प्रस्ताव उठते हैं, इसलिए यह धागा। इसलिए, मैं संभावित विखंडन से चिंतित हूं। आदर्श रूप से (और इस तरह वासम को अब तक डिजाइन किया गया था), इसके बाइंडिंग सहित एक वासम मॉड्यूल को देखते हुए, इसे कहीं भी चलाना संभव है। Web IDL, Cap'n' Proto, FlatBuffers, जो भी हो, में लिखे गए बाइंडिंग के साथ, मुझे पूरा यकीन है कि सभी कंपाइलर या प्रोग्राम लेखक अलग-अलग सिंटैक्स में समान बाइंडिंग को सही मायने में क्रॉस-प्लेटफ़ॉर्म नहीं लिखेंगे। मजे की बात यह है कि यह हस्तलिखित बाइंडिंग के पक्ष में एक तर्क है: लोग प्लेटफॉर्म पी के लिए बाइंडिंग लिखकर कार्यक्रम में योगदान कर सकते हैं। लेकिन मान लें कि यह बिल्कुल भी आदर्श नहीं होगा।

तो संक्षेप में: मैं वेब और गैर-वेब बाइंडिंग के बीच संभावित विखंडन से चिंतित हूं। यदि एक गैर-वेब बाध्यकारी भाषा आयोजित की जाती है, तो क्या इसे वेब ब्राउज़र द्वारा वास्तविक रूप से कार्यान्वित किया जाएगा? उन्हें बाइंडिंग “Wasm बाइंडिंग लैंग्वेज B ⟶ Web IDL” लिखनी होगी। ध्यान दें कि यह सभी होस्ट के लिए समान परिदृश्य है: Wasm बाइंडिंग लैंग्वेज B ⟶ होस्ट API।

जो लोग उत्सुक हैं के लिए, मैं WASMER पर काम करते हैं और मैं के लेखक हूँ PHP- , Python- , Ruby- और Go- Wasm एकीकरण। हम बहुत अलग मेजबानों के लिए अलग-अलग बाइंडिंग को हैक करने के लिए एक अच्छा खेल का मैदान बनाना शुरू करते हैं। यदि कोई चाहता है कि मैं विभिन्न समाधानों को एकीकृत करूँ, प्रतिक्रियाएँ एकत्र करूँ, या प्रयोग करने का प्रयास करूँ, तो हम सभी सहयोग करने और उस पर अधिक संसाधन लगाने के लिए तैयार हैं।

'वेबआईडीएल बाइंडिंग' में वर्तमान दिशा शायद वेबआईडीएल से दूर है
अपने आप। हालाँकि, दुविधा यह है:

इंटर-मॉड्यूल और मॉड्यूल-होस्ट को व्यक्त करने के लिए 'प्राकृतिक' भाषा
इंटरऑपरेबिलिटी WASM की प्राकृतिक भाषा की तुलना में काफी समृद्ध है। इस
इसका मतलब है कि कोई भी प्रयोग करने योग्य आईडीएल-समकक्ष काफी मनमाना दिखने वाला है
WASM के पीओवी।

दूसरी ओर, उन लोगों के लिए जो दुनिया को C/C++ . के लेंस से देखते हैं
(और जंग और इसके जैसे) WASM के मॉडल के जोखिम से अधिक समृद्ध कुछ भी हो रहा है
अनुपयोगी हम इसे पहले से ही रेफरी को एकीकृत करने की कठिनाई के साथ देख सकते हैं
उपकरण श्रृंखला में टाइप करें।

इसके अलावा, सामान्य का समर्थन करना WASM का प्रत्यक्ष आदेश नहीं है
अंतर-भाषा अंतरसंचालनीयता। न ही यह आईएमओ होना चाहिए।

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

निचली पंक्ति: आईडीएल-समकक्ष होने का मामला है, और हमें इसकी आवश्यकता है
स्वामित्व सीमाओं के पार अंतर्संचालन का समर्थन करने के लिए। यह क्या समाप्त होता है
होना फिलहाल स्पष्ट नहीं है।

सोम 24 जून 2019 को सुबह 7:02 बजे इवान एंडरलिन नोटिफिकेशन @github.com
लिखा था:

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

मैंने WebAssembly/webidl-bindings#40 . खोली हैं
https://github.com/WebAssembly/webidl-bindings/issues/40 , जिसने मुझे आगे बढ़ाया
यहां एक प्रश्न पूछने के लिए क्योंकि मैंने इसका कोई उल्लेख नहीं देखा है (या मैंने इसे याद किया है)।

पूरी बाध्यकारी कहानी में, यह स्पष्ट नहीं है कि "कौन" जिम्मेदार है
बाइंडिंग उत्पन्न करें:

• क्या यह एक कंपाइलर है (जो एक प्रोग्राम को वासम मॉड्यूल में बदल देता है)?
• क्या यह एक प्रोग्राम लेखक है (और इसलिए, क्या बाइंडिंग हाथ से लिखी गई है)?

मुझे लगता है कि दोनों मान्य हैं। और वेब आईडीएल के मामले में, ऐसा लगता है कि कुछ दिखा रहा है
सीमाएं (उपरोक्त लिंक देखें)। हो सकता है कि मैं अभी-अभी एक महत्वपूर्ण कदम से चूक गया हूँ
प्रक्रिया, और इसलिए, मेरे संदेश को भूल जाने पर विचार करें।

भले ही उद्देश्य वेब आईडीएल को कम वेब-केंद्रित करने के लिए "रीफोकस" करना है, अभी,
यह बहुत वेब केंद्रित है। और विकल्प प्रस्तावित करने के लिए प्रस्ताव उठते हैं,
इसलिए यह धागा। इसलिए, मैं संभावित विखंडन से चिंतित हूं।
आदर्श रूप से (और इस तरह वासम को अब तक डिजाइन किया गया था), एक वासम मॉड्यूल दिया गया
इसकी बाइंडिंग सहित, इसे कहीं भी चलाना संभव है। साथ में
Web IDL, Cap'n' Proto, FlatBuffers, जो भी हो, में लिखे गए बाइंडिंग
निश्चित रूप से सभी कंपाइलर या प्रोग्राम लेखक एक ही नहीं लिखेंगे
वास्तव में क्रॉस-प्लेटफ़ॉर्म होने के लिए विभिन्न सिंटैक्स में बाइंडिंग। मजे की बात यह है
हस्तलिखित बंधनों के पक्ष में एक तर्क: लोग इसमें योगदान कर सकते हैं:
मंच पी के लिए बाइंडिंग लिखकर कार्यक्रम। लेकिन मान लें कि यह नहीं होगा
बिल्कुल आदर्श।

तो संक्षेप में: मैं वेब और के बीच संभावित विखंडन से चिंतित हूं
गैर-वेब बाइंडिंग। यदि एक गैर-वेब बाध्यकारी भाषा आयोजित की जाती है, तो क्या यह होगा?
वेब ब्राउज़र द्वारा वास्तविक रूप से कार्यान्वित किया गया? उन्हें लिखना होगा
बाइंडिंग "वासम बाइंडिंग लैंग्वेज बी वेब आईडीएल"। ध्यान दें कि यह वही है
सभी मेजबानों के लिए परिदृश्य: Wasm बाध्यकारी भाषा B होस्ट API।

उत्सुक लोगों के लिए, मैं वासमर में काम करता हूं और मैं PHP का लेखक हूं-
https://github.com/wasmerio/php-ext-wasm , पायथन-
https://github.com/wasmerio/python-ext-wasm , रूबी-
https://github.com/wasmerio/ruby-ext-wasm और Go-
https://github.com/wasmerio/go-ext-wasm Wasm इंटीग्रेशन। हम शुरू करें
बहुत अलग के लिए अलग-अलग बाइंडिंग को हैक करने के लिए एक अच्छा खेल का मैदान होना
मेजबान। अगर कोई चाहता है कि मैं अलग-अलग समाधानों को एकीकृत करूँ, एकत्र करने के लिए
फीडबैक, या प्रयोग करने का प्रयास करें, हम सभी खुले हैं और सहयोग करने के लिए तैयार हैं
और उस पर अधिक संसाधन लगाएं।

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपका उल्लेख किया गया था।
इस ईमेल का सीधे उत्तर दें, इसे GitHub पर देखें
https://github.com/WebAssembly/design/issues/1274?email_source=notifications&email_token=AAQAXUD6WA22DDUS7PYQ6F3P4DHYRA5CNFSM4HJUHVG2YY3PNVWWK3TUL52HS4DFVREXG43VMVBJ
या थ्रेड को म्यूट करें
https://github.com/notifications/unsubscribe-auth/AAQAXUGM66AWN7ZCIVBTXVTP4DHYRANCNFSM4HJUHVGQ
.

--
फ्रांसिस मैककेबे
दुर्भाग्य

हम इसे पहले से ही टूल श्रृंखला में रेफ प्रकारों को एकीकृत करने की कठिनाई के साथ देख सकते हैं।

मैं अन्य भाषाओं के लिए बात नहीं कर सकता, लेकिन Rust + wasm-bindgen के पास पहले से ही इसके लिए समर्थन है:

• anyref

• बाइंडिंग जो WebIDL से स्वतः उत्पन्न होती हैं , और इसे सावधानीपूर्वक डिज़ाइन किया गया है ताकि बाद में इसे आधिकारिक WebIDL रेफरी प्रकारों में आसानी से अपग्रेड किया जा सके

• आधिकारिक webidl-bindings प्रस्ताव के लिए एक WebIDL पॉलीफ़िल

तो मैं उत्सुक हूं: आप किन कठिनाइयों का जिक्र कर रहे हैं?

कठिनाइयों के बारे में मेरी समझ C++ के अंत में अधिक है। भाषा के अंत में इसे और अधिक उचित बनाने के लिए जंग के पास पर्याप्त शक्तिशाली मेटाप्रोग्रामिंग है, लेकिन उपयोगकर्तालैंड सी ++ में उदाहरण के लिए किसी भी रेफरी के बारे में कठिन समय है।

मैं यहां सी ++ विशिष्ट मुद्दों के बारे में और जानने के लिए उत्सुक हूं। (क्या वे सी ++ विशिष्ट या एलएलवीएम विशिष्ट हैं?)

सी ++ नहीं जानता कि रेफ प्रकार क्या है। तो आप इसे अंदर नहीं रख सकते a
मनमाना वस्तु। वास्तव में भाषा का हिस्सा नहीं है; एक फ़ाइल की तरह अधिक
वर्णनकर्ता एक स्ट्रिंग के लिए मजेदार जगह।

सोम, जून 24, 2019 3:07 PM पर एलन Zakai पर पर [email protected] लिखा है:

मैं यहां सी ++ विशिष्ट मुद्दों के बारे में और जानने के लिए उत्सुक हूं। (क्या वे हैं
सी ++ विशिष्ट या एलएलवीएम विशिष्ट?)

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपका उल्लेख किया गया था।
इस ईमेल का सीधे उत्तर दें, इसे GitHub पर देखें
https://github.com/WebAssembly/design/issues/1274?email_source=notifications&email_token=AAQAXUDW237MUBBUUJLKS6LP4FARJA5CNFSM4HJUHVG2YY3PNVWWK3TUL52HS4DFVREXG43VMVBJKT74P मुद्दा -50HWUL52HS4DFVREXG43VMVBJKT74PN
या थ्रेड को म्यूट करें
https://github.com/notifications/unsubscribe-auth/AAQAXUB4O3ZX4LRQSQRL763P4FARJANCNFSM4HJUHVGQ
.

--
फ्रांसिस मैककेबे
दुर्भाग्य

@fgmccabe ऑफ़लाइन से बात करते

मैं इस बारे में उत्सुक रहता हूं कि यहां सी ++ के लिए कुछ विशिष्ट है या नहीं। मुझे नहीं लगता वहाँ है?

सी ++ को यहां कठिन बनाने के बारे में मेरी समझ यह है कि यदि आपने कहा है:

struct Anyref; // opaque declaration
void console_log(Anyref* item); // declaration of ref-taking external JS API
Anyref* document_getElementById(const char* str);

void wellBehaved() {
  // This should work
  Anyref* elem = document_getElementById("foo");
  console_log(elem);
}

void notSoWellBehaved() {
  // ????
  Anyref* elem = document_getElementById("bar");
  Anyref* what = (Anyref*)((unsigned int)elem + 1);
  console_log(what);
}

अच्छी खबर यह है कि बाद का उदाहरण यूबी मेरा मानना ​​​​है (अमान्य पॉइंटर्स यूबी जैसे ही बनाए जाते हैं), लेकिन हम इसे एलएलवीएम आईआर में मॉडल करने का प्रयास कैसे करते हैं?

@ jgravelle-google मुझे लगता है कि struct Anyref; मानता है कि यह ऐसा कुछ है जो रैखिक स्मृति में समझ में आता है। इसके बजाय, इसे एक पूर्णांक हैंडल के साथ मॉडल क्यों न करें जैसा कि पहले उल्लेख किया गया है, जैसे ओपनजीएल बनावट, फ़ाइल हैंडल, और आगे?

using Anyref = uint32_t; // handle declaration
void console_log(Anyref item); // declaration of ref-taking external JS API
Anyref document_getElementById(const char* str);

void wellBehaved() {
  // This should work
  Anyref elem = document_getElementById("foo");
  console_log(elem);
}

पूर्णांक हैंडल को तालिका में देखा जाना चाहिए जब इसका उपयोग किया जाना है - फिर से, यह केवल उन भाषाओं का नकारात्मक पक्ष है जो सी ++ और जंग जैसी रैखिक स्मृति का उपयोग करते हैं। हालांकि, इसे निश्चित रूप से कम से कम स्थानीय रूप से अनुकूलित किया जा सकता है - यदि एलएलवीएम द्वारा नहीं, तो वासम स्तर पर।

यह काम करेगा, लेकिन फिर आपको table_free(elem) पर कॉल करना सुनिश्चित करना होगा या आप इसका संदर्भ हमेशा के लिए रखेंगे। जो सी ++ के लिए अजीब नहीं है, दी गई है।

यह एक अजीब मैपिंग का कुछ है क्योंकि यह मुझे लगता है कि अच्छी तरह से परत नहीं करता है? जैसे यह एक पुस्तकालय की तरह लगता है एक ला ओपनजीएल, लेकिन यह प्रदान करने के लिए कंपाइलर जादू पर निर्भर करता है - मुझे नहीं लगता कि आप इनलाइन-वास के साथ भी सी ++ में anyref.h बना सकते हैं, यदि आप एक अलग घोषित करने पर निर्भर हैं टेबल।

वैसे भी मुझे लगता है कि यह सब करने योग्य/ट्रैक्टेबल है, लेकिन सीधे-सीधे नहीं है।

@kripken यह सच है कि "उचित" मूल anyref समर्थन के लिए LLVM (और rustc में) में कुछ बदलावों की आवश्यकता होगी, लेकिन यह वास्तव में एक बाधा नहीं है।

wasm-bindgen वास्तविक wasm anyref s को एक wasm तालिका में संग्रहीत करता है, और फिर रैखिक स्मृति में यह तालिका में एक पूर्णांक अनुक्रमणिका संग्रहीत करता है। तो यह wasm table.get निर्देश का उपयोग करके anyref तक पहुंच सकता है।

wasm-gc लागू होने तक, GC भाषाओं को ठीक उसी रणनीति का उपयोग करने की आवश्यकता होगी, इसलिए Rust (et al) गायब नहीं हैं।

तो LLVM में मूल anyref समर्थन से हमें क्या लाभ होगा? खैर, यह एक wasm तालिका के माध्यम से anyref को अप्रत्यक्ष करने की आवश्यकता के बजाय, कार्यों से सीधे anyref पास/वापस करने में सक्षम होगा। यह उपयोगी होगा, हाँ, लेकिन यह सिर्फ एक प्रदर्शन अनुकूलन है, यह वास्तव में anyref का उपयोग करने से नहीं रोकता है।

@पौआन

wasm-bindgen वास्तविक wasm anyrefs को wasm तालिका में संग्रहीत करता है, और फिर रैखिक स्मृति में यह तालिका में एक पूर्णांक अनुक्रमणिका संग्रहीत करता है। तो यह wasm table.get निर्देश का उपयोग करके किसी भी रेफरी तक पहुंच सकता है।

बिल्कुल, हाँ, यही वह मॉडल है जिसका मैं जिक्र कर रहा था।

wasm-gc लागू होने तक, GC भाषाओं को ठीक उसी रणनीति का उपयोग करने की आवश्यकता होगी, इसलिए Rust (et al) गायब नहीं हैं।

हां, अभी GC भाषाओं का कोई फायदा नहीं है क्योंकि हमारे पास कोई देशी wasm GC नहीं है। लेकिन उम्मीद है कि यह बदलेगा! :) आखिरकार मुझे उम्मीद है कि जीसी भाषाओं को यहां स्पष्ट लाभ होगा, कम से कम अगर हम जीसी ठीक से करते हैं।

तो एलएलवीएम में नेटिव एनीरेफ सपोर्ट से हमें क्या फायदा होगा? खैर, यह किसी वॉश टेबल के माध्यम से किसी भी तरह से अप्रत्यक्ष करने की आवश्यकता के बजाय, कार्यों से किसी भी प्रकार को सीधे पास/वापस करने में सक्षम बनाता है। यह उपयोगी होगा, हाँ, लेकिन यह सिर्फ एक प्रदर्शन अनुकूलन है, यह वास्तव में anyref का उपयोग करने से नहीं रोकता है।

सहमत, हाँ, यह केवल सी ++ और जंग आदि पर जीसी भाषाओं (अंततः) का एक पूर्ण लाभ होगा। यह उपयोग को रोकता नहीं है।

सी ++ और जंग के लिए साइकिल एक बड़ी समस्या है, हालांकि, टेबल रूट के बाद से। हो सकता है कि हमारे पास एक ट्रेसिंग एपीआई या "छाया ऑब्जेक्ट्स" हो, मूल रूप से सी ++/रस्ट के अंदर जीसी लिंक की संरचना को मैप करने का कोई तरीका है ताकि बाहरी जीसी उन्हें समझ सके। लेकिन मुझे नहीं लगता कि उनमें से किसी के लिए अभी तक कोई वास्तविक प्रस्ताव है।

आखिरकार मुझे उम्मीद है कि जीसी भाषाओं को यहां स्पष्ट लाभ होगा, कम से कम अगर हम जीसी ठीक से करते हैं।

मैं गलत हो सकता था, लेकिन अगर ऐसा होता तो मुझे आश्चर्य होता: GC भाषाओं को एक wasm GC संरचना आवंटित करनी होगी और फिर wasm इंजन को उस पर नज़र रखनी होगी क्योंकि यह कार्यक्रम के माध्यम से बहता है।

इसकी तुलना में, रस्ट को किसी आवंटन की आवश्यकता नहीं है (बस एक तालिका को असाइन करें), और केवल एक पूर्णांक को संग्रहीत करने की आवश्यकता है, और wasm इंजन को केवल GC उद्देश्यों के लिए 1 स्थिर स्थिर तालिका का ट्रैक रखने की आवश्यकता है।

मुझे लगता है कि यह संभव है कि anyref पहुंच जीसी भाषाओं के लिए अनुकूलन योग्य हो, क्योंकि इसे table.get का उपयोग करने की आवश्यकता नहीं होगी, हालांकि मुझे उम्मीद है कि table.get काफी तेज होगा।

तो क्या आप इस बारे में अधिक बता सकते हैं कि आप एक wasm-gc प्रोग्राम को wasm टेबल का उपयोग करके प्रोग्राम से बेहतर प्रदर्शन करने की उम्मीद कैसे करते हैं?

पीएस यह बहुत दूर विषय प्राप्त करना शुरू कर रहा है, तो शायद हमें इस चर्चा को एक नए सूत्र में ले जाना चाहिए?

वास्तव में बस यही: table.get/table.set से परहेज करना। जीसी के साथ आपके पास कच्चे सूचक होना चाहिए, संकेतों को सहेजना। लेकिन हाँ, आप सही कह रहे हैं कि जंग और सी ++ को केवल एक पूर्णांक स्टोर करने की आवश्यकता है, और वे कुल मिलाकर बहुत तेज़ हैं, इसलिए कोई भी जीसी लाभ मायने नहीं रखता है!

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

@kentonv

Cap'n Proto की क्रमांकन परत वास्तविक रूप से प्रत्येक भाषा में स्वतंत्र रूप से लागू की जानी चाहिए क्योंकि इसमें से अधिकांश एक विस्तृत-लेकिन-उथली API परत है जिसे मुहावरेदार और इनलाइन-अनुकूल होने की आवश्यकता है। RPC परत, OTOH, संकीर्ण लेकिन गहरी है

कौन सा फोल्डर है?

@PoignardAzur क्षमा करें, मुझे आपका प्रश्न समझ में नहीं आया।

@kentonv मैं capnproto Github रिपॉजिटरी के माध्यम से देख रहा हूँ। क्रमांकन परत कहाँ है?

@PoignardAzur तो, यह मेरी बात पर वापस आ जाता है। वास्तव में एक भी जगह नहीं है जिसे आप इंगित कर सकते हैं और कह सकते हैं "वह क्रमांकन परत है"। अधिकतर, Cap'n Proto का "क्रमबद्धता" एक अंतर्निहित बफर में लोड/स्टोर के आसपास केवल सूचक अंकगणित है। एक स्कीमा फ़ाइल को देखते हुए, आप एक हेडर फ़ाइल उत्पन्न करने के लिए कोड जनरेटर का उपयोग करते हैं जो इनलाइन विधियों को परिभाषित करता है जो स्कीमा में परिभाषित विशेष फ़ील्ड के लिए सही पॉइंटर अंकगणित करते हैं। एप्लिकेशन कोड को तब इन जेनरेट किए गए एक्सेसर्स को हर बार किसी भी फ़ील्ड को पढ़ने या लिखने के लिए कॉल करने की आवश्यकता होती है।

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

Cap'n प्रोटो कार्यान्वयन के भीतर शायद कुछ आंतरिक सहायक कार्य हैं जिन्हें साझा किया जा सकता है। विशेष रूप से, layout.c++ / layout.h में वह सभी कोड होते हैं जो कैपनप के पॉइंटर एन्कोडिंग की व्याख्या करते हैं, बाउंड चेकिंग करते हैं, आदि। जेनरेट कोड एक्सेसर्स पॉइंटर फ़ील्ड को पढ़ते/लिखते समय उस कोड में कॉल करते हैं। तो मैं शायद कल्पना कर सकता हूं कि उस हिस्से को एफएफआई में कई भाषाओं से बुलाया जा सकता है; लेकिन मैं अभी भी प्रत्येक लक्षित भाषा में कोड जेनरेटर और कुछ रनटाइम समर्थन लाइब्रेरी लिखने की अपेक्षा करता हूं।

हाँ, क्षमा करें, मेरा मतलब विपरीत ^^ (आरपीसी परत) था

@PoignardAzur ओह, और मुझे लगता है कि आप इंटरफेस को देखने में विशेष रूप से रुचि रखते हैं, क्योंकि आप सोच रहे हैं कि उन्हें एफएफआई में कैसे लपेटना है। तो फिर आप चाहते हैं:

• capability.h : क्षमताओं और आरपीसी आमंत्रण का प्रतिनिधित्व करने के लिए सार इंटरफेस, जो सिद्धांत रूप में विभिन्न प्रकार के कार्यान्वयन द्वारा समर्थित हो सकता है। (यह सबसे महत्वपूर्ण हिस्सा है।)
• rpc.h : एक नेटवर्क पर RPC का कार्यान्वयन।
• rpc-twoparty.h : एक साधारण कनेक्शन पर RPC के लिए ट्रांसपोर्ट एडॉप्टर।

इस प्रस्ताव को अब #1291: OCAP बाइंडिंग से हटा दिया गया है।