Design: उचित पूंछ कॉल समर्थन

हां, उचित टेल कॉल का समर्थन किया जाएगा, लेकिन संभवतः एमवीपी में नहीं। यह उन कार्यात्मक भाषाओं के लिए विशेष रूप से उपयोगी होगा जो गारंटीड टेल-कॉल ऑप्टिमाइज़ेशन पर निर्भर करती हैं। #33 और #44 में चर्चा देखें। यह कैसे समर्थित है यह अभी भी हवा में है क्योंकि इसे प्रयोग और प्रदर्शन माप की आवश्यकता है।

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

जैसा कि आप कहते हैं, कार्यात्मक भाषाएं गारंटीड टेल-कॉल ऑप्टिमाइज़ेशन पर निर्भर करती हैं, हालांकि इस तरह की शब्दावली पर भरोसा किया जाता है क्योंकि यह C/C++/etc कंपाइलर्स द्वारा किए गए TCO के प्रकार के साथ भ्रम को आमंत्रित करता है, जहां विभिन्न प्रतिबंध लगाए जा सकते हैं जिन पर कॉल योग्य हैं। तो इसके बजाय "उचित पूंछ कॉल" शब्द का प्रयोग किया जाता है। उचित टेल कॉल वाली भाषा में, टेल पोजीशन में किसी भी कॉल को कॉलिंग एक्टिवेशन फ्रेम के कब्जे वाले स्टोरेज को छोड़ने की आवश्यकता होती है। इसमें अप्रत्यक्ष कॉल शामिल हैं, इसलिए स्थानीय नियंत्रण प्रवाह विश्लेषण के लिए कठिनाई। इसलिए कार्यात्मक भाषा संकलक/रनटाइम में आमतौर पर स्पष्ट पूंछ कॉल संचालन और उन्हें समर्थन देने के लिए सम्मेलन बुलाए जाते हैं।

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

ओह क्षमा करें, मेरा मतलब दस्तावेज़ीकरण को ठीक करने से पहले बंद करना नहीं था। मैंने इस मुद्दे को हल करने के लिए # 190 खोला (और इस मुद्दे को बंद करें)। हम मुद्दों को डिज़ाइन के पाठ में ले जा रहे हैं, क्योंकि यह नए पाठकों के लिए दायर मुद्दों की संपूर्ण स्थिति को पढ़ने के विपरीत चीजों की स्थिति को समझना आसान बनाता है।