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

go myfunc(); // Golang pthread_create(&thread_id, NULL, &myfunc); /* C with POSIX threads */ spawn(modulename, myfuncname, []) % Erlang threading.Thread(target=myfunc).start() # Python with threads asyncio.create_task(myfunc()) # Python with asyncio 

अंकन और शब्दावली के लिए कई विकल्प हैं, लेकिन एक शब्दार्थ मुख्य कार्यक्रम के समानांतर myfunc को चलाने और निष्पादन के मूल सूत्र को जारी रखना है (Eng। "नियंत्रण प्रवाह")

एक अन्य विकल्प कॉलबैक है :

 QObject::connect(&emitter, SIGNAL(event()), // C++ with Qt &receiver, SLOT(myfunc())) g_signal_connect(emitter, "event", myfunc, NULL) /* C with GObject */ document.getElementById("myid").onclick = myfunc; // Javascript promise.then(myfunc, errorhandler) // Javascript with Promises deferred.addCallback(myfunc) # Python with Twisted future.add_done_callback(myfunc) # Python with asyncio 

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

और ... बस इतना ही। किसी भी लोकप्रिय संगामिति सामान्य प्रयोजन की भाषा लें और आप शायद पाएंगे कि यह इन प्रतिमानों (कभी-कभी दोनों, अतुल्य) में से एक में गिर जाता है।

लेकिन मेरी नई अजीब तिकड़ी पुस्तकालय नहीं। वह इन तरीकों का इस्तेमाल नहीं करती है। इसके बजाय, अगर हम समानांतर में myfunc और एक अन्य anotherfunc चलाना चाहते हैं, तो हम कुछ इस तरह लिखते हैं:

 async with trio.open_nursery() as nursery: nursery.start_soon(myfunc) nursery.start_soon(anotherfunc) 

नर्सरी - नर्सरी, नर्सरी

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

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

बहुत बोल्ड लगता है? लेकिन यह पहले से ही हुआ है: एक बार एक कार्यक्रम के व्यवहार को नियंत्रित करने के लिए goto व्यापक रूप से उपयोग किया goto । अब यह हंसी का अवसर है:

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

सामग्री की तालिका

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

goto क्या है?

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

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

ध्यान दें कि आधुनिक भाषाओं के विपरीत, if ब्लॉक, लूप या फ़ंक्शन कॉल हैं if कोई सशर्त नहीं है - वास्तव में कोई ब्लॉक या इंडेंट नहीं हैं। यह सिर्फ भावों की अनुक्रमिक सूची है। इसलिए नहीं कि इस कार्यक्रम में नियंत्रण कथनों ( JUMP TO ) की आवश्यकता बहुत कम है - बस ऐसे वाक्यविन्यास का अभी तक आविष्कार नहीं हुआ है!

इसके बजाय, FLOW-MATIC के पास निष्पादन के प्रवाह को नियंत्रित करने के लिए दो विकल्प थे। आमतौर पर प्रवाह सुसंगत था - ऊपर से शुरू होता है और नीचे जाता है, एक समय में एक अभिव्यक्ति। लेकिन अगर आप विशेष JUMP TO व्यंजक को निष्पादित करते हैं, तो यह कहीं और नियंत्रण कर सकता है। उदाहरण के लिए, अभिव्यक्ति (13) अभिव्यक्ति के लिए कूदती है (2):

बस लेख की शुरुआत से समानता के आदिम के साथ के रूप में, तो क्या इस "एक तरह से कूद" ऑपरेशन कॉल करने के लिए कोई समझौता नहीं था। लिस्टिंग में, यह JUMP TO , लेकिन goto ऐतिहासिक रूप से रूट ले लिया है (जैसे "वहां जाएं"), जिसका उपयोग मैं यहां करता हूं।

यहाँ इस छोटे से कार्यक्रम में goto कूद का पूरा सेट दिया गया है:

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

लेकिन goto ऐसी समस्या क्यों हुई? क्यों कुछ नियंत्रण कथन अच्छे हैं और अन्य नहीं? अच्छे लोगों का चयन कैसे करें? उस समय यह पूरी तरह से समझ से बाहर था, और यदि आप समस्या को नहीं समझते हैं, तो इसे हल करना मुश्किल है।

क्या go ?

आइये हमारी कहानी से पछताते हैं। हर कोई जानता है कि goto खराब था, लेकिन इस अतुल्यकालिक के साथ क्या करना है? गोलंग के प्रसिद्ध go अभिव्यक्ति को देखें, जिसका उपयोग नए "गोरोइन" (हल्के प्रवाह) को फैलाने के लिए किया जाता है:

 // Golang go myfunc(); 

क्या निष्पादन के अपने प्रवाह का आरेख खींचना संभव है? यह ऊपर दिए गए आरेख से थोड़ा अलग है, क्योंकि यहां धारा विभाजित है। आइए इसे इस तरह बनाएं:

यहां के रंग यह दिखाने के लिए हैं कि दोनों रास्ते चुने गए हैं। पेरेंट गोरोइन (ग्रीन लाइन) के दृष्टिकोण से - नियंत्रण प्रवाह को क्रमिक रूप से निष्पादित किया जाता है: यह ऊपर से शुरू होता है और फिर तुरंत नीचे चला जाता है। इस बीच, वंश कार्य (बकाइन लाइन) के दृष्टिकोण से, धारा ऊपर से आती है और फिर myfunc के शरीर में कूद जाती है। एक नियमित फ़ंक्शन कॉल के विपरीत, एक तरफ़ा कूद है - myfunc शुरू करने से हम पूरी तरह से नए स्टैक पर स्विच करते हैं और रनटाइम तुरंत भूल जाता है कि हम कहाँ से आए थे।

जाहिरा तौर पर मेरा मतलब है कॉल स्टैक

लेकिन यह न केवल गोलंग पर लागू होता है। यह आरेख लेख की शुरुआत में सूचीबद्ध सभी आदिम (नियंत्रण) के लिए सच है:

• थ्रेडिंग लाइब्रेरी आमतौर पर किसी प्रकार की नियंत्रण वस्तु लौटाती है जो उन्हें बाद में थ्रेड में शामिल होने की अनुमति देगी - लेकिन यह एक स्वतंत्र ऑपरेशन है जिसके बारे में भाषा खुद कुछ नहीं जानती है। एक नया धागा बनाने के लिए आदिम में ऊपर दिखाया गया चित्र है।
• कॉलबैक पंजीकरण एक पृष्ठभूमि धागा बनाने के लिए शब्दार्थ के बराबर है (हालांकि यह स्पष्ट है कि कार्यान्वयन अलग है), जो:
  a) तब तक अवरुद्ध होता है जब तक कोई घटना नहीं होती है, और फिर
  b) कॉलबैक फ़ंक्शन लॉन्च करता है
  इसलिए, उच्च-स्तरीय नियंत्रण ऑपरेटरों के संदर्भ में, कॉलबैक पंजीकरण जाने के लिए एक अभिव्यक्ति है।
• Futures साथ और एक ही बात का Promises करता है - जब आप फ़ंक्शन चलाते हैं और यह Promise , तो इसका मतलब है कि उसने पृष्ठभूमि में काम करने की योजना बनाई है और बाद में परिणाम प्राप्त करने के लिए एक नियंत्रण वस्तु लौटाता है (यदि आप चाहते हैं)। प्रबंधन शब्दार्थ के दृष्टिकोण से, यह एक प्रवाह बनाने के समान है। उसके बाद, आप कॉलबैक को प्रोमिस और फिर पिछले पैराग्राफ में पास करते हैं।

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

फिर भी, यह मुझे गुस्सा दिलाता है कि इस श्रेणी के नियंत्रण बयानों के लिए कोई मानक नाम नहीं है। मैं उन्हें कॉल करने के लिए "गो" अभिव्यक्ति का उपयोग करता हूं, जैसे कि "गोटो" सभी goto अभिव्यक्तियों के लिए एक सामान्य शब्द बन गया है। क्यों go ? एक कारण यह है कि गोलंग हमें इस तरह के वाक्य रचना का बहुत ही साफ उदाहरण देता है। और दूसरा है:

समानता को नोटिस करें? यह सही है - go एक goto फॉर्म में से एक है।

लेखन और विश्लेषण की कठिनाई के लिए अतुल्यकालिक कार्यक्रम कुख्यात हैं। साथ ही goto पर आधारित कार्यक्रम। goto होने वाली समस्याओं goto ज्यादातर आधुनिक भाषाओं में हल किया जाता है। यदि हम सीखते हैं कि goto को कैसे ठीक किया जाए, तो क्या यह अधिक सुविधाजनक अतुल्यकालिक एपीआई बनाने में मदद करेगा? चलिए पता लगाते हैं!

क्या हुआ goto ?

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

goto अमूर्तता को नष्ट कर देता है

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

परीक्षण कार्यक्रम त्रुटियों की उपस्थिति दिखा सकते हैं, लेकिन उनकी अनुपस्थिति कभी नहीं।

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

 print("Hello World!") 

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

इस बिंदु पर, ब्लॉक सिंटैक्स का आविष्कार किया गया था और ALGOL जैसी भाषाएं जमा हुईं ~ 5 अलग-अलग प्रकार के नियंत्रण वक्तव्य: उनके पास अभी भी निष्पादन और goto का अनुक्रमिक धागा था:

और भी अधिग्रहीत शर्तों, चक्र और फ़ंक्शन कॉल:

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

• ऊपर से आता है => [कुछ होता है] => प्रवाह नीचे से आता है

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

 print("Hello World!") 

मुझे यह समझने की ज़रूरत नहीं है कि निष्पादन थ्रेड कहाँ जाएगा, यह समझने के लिए print के स्रोतों और उसकी सभी निर्भरताओं को पढ़ना होगा। शायद अंदर print में एक लूप है, और इसमें एक शर्त है जिसमें एक अन्य फ़ंक्शन के लिए कॉल है ... यह सब महत्वपूर्ण नहीं है - मुझे पता है कि थ्रेड print करने के लिए जाएगा, फ़ंक्शन अपना काम करेगा, और अंततः थ्रेड कोड पर वापस आ जाएगा I मैं पढ़ता हूं।

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

और जो अमूर्तता को तोड़ता है - किसी भी फ़ंक्शन के अंदर एक संभावित goto हो सकता है, और यह पता लगाने का एकमात्र तरीका है कि क्या यह मामला आपके सिस्टम के सभी स्रोत कोड को ध्यान में रखना है। भाषा के goto , आप निष्पादन के प्रवाह की भविष्यवाणी नहीं कर सकते। यही कारण है कि goto स्पेगेटी कोड की ओर जाता है।

और जैसे ही दिज्क्स्त्र ने समस्या को समझा, वह इसे हल करने में सक्षम था। यहाँ उनकी क्रांतिकारी धारणा है - हमें goto लिए शर्तों / छोरों / फ़ंक्शन कॉल के बारे में नहीं सोचना चाहिए, लेकिन हमारे अधिकारों के साथ मौलिक आदिम के रूप में - और हमें अपनी भाषाओं से goto को पूरी तरह से हटा देना चाहिए।

2018 से, यह बहुत स्पष्ट लगता है। लेकिन जब आप उनके असुरक्षित खिलौने लेने की कोशिश करते हैं तो प्रोग्रामर कैसे प्रतिक्रिया देते हैं? 1969 में, डिक्स्ट्रा का प्रस्ताव अविश्वसनीय रूप से संदिग्ध लग रहा था। डोनाल्ड नथ ने goto बचाव किया । जो लोग goto साथ कोडिंग में विशेषज्ञ बन गए थे, वे अपने विचारों को नए, अधिक प्रतिबंधात्मक शब्दों में पुनः व्यक्त करने के तरीके के बारे में जानने के खिलाफ ठीक से नाराज थे। और निश्चित रूप से, यह पूरी तरह से नई भाषाओं को बनाने के लिए ले गया।

नतीजतन, आधुनिक भाषाएं दिज्क्स्ट्रा की मूल शब्दों की तुलना में थोड़ी कम सख्त हैं।

वाम: पारंपरिक goto । सही: पालतू goto , जैसा कि सी, सी #, गोलंग, आदि में है। किसी फ़ंक्शन की सीमाओं को पार करने में विफलता का मतलब है कि वह अभी भी आपके जूते पर पेशाब कर सकता है, लेकिन आपको अलग से चीरने की संभावना नहीं है।

वे आपको break , continue या return का उपयोग करके संरचनात्मक नियंत्रण बयानों के घोंसले के स्तर को कूदने की अनुमति देते हैं। लेकिन एक बुनियादी स्तर पर, वे सभी दिज्क्स्ट्रा के विचार के आसपास निर्मित हैं और एक सख्त तरीके से निष्पादन के अनुक्रमिक प्रवाह को बाधित कर सकते हैं। विशेष रूप से, फ़ंक्शन - एक ब्लैक बॉक्स में निष्पादन के धागे को लपेटने के लिए एक मूलभूत उपकरण - अविनाशी हैं। आप एक फ़ंक्शन से दूसरे फ़ंक्शन पर break कमांड निष्पादित नहीं कर सकते हैं और वर्तमान फ़ंक्शन की तुलना में आपको वापस नहीं लौटा सकते हैं। फ़ंक्शन के अंदर निष्पादन के धागे का कोई हेरफेर अन्य कार्यों को प्रभावित नहीं करेगा।

और जिन भाषाओं ने goto ऑपरेटर (सी, सी #, गोलंग, ...) को संरक्षित किया, उन्होंने इसे गंभीर रूप से सीमित कर दिया। कम से कम, वे आपको एक फ़ंक्शन के शरीर से दूसरे में कूदने की अनुमति नहीं देते हैं। यदि आप असेंबलर [2] का उपयोग नहीं कर रहे हैं, तो क्लासिक, असीमित goto अतीत की बात है। दिक्जस्त्र जीता।

गोटो के बिना बहादुर नई दुनिया

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

उदाहरण के लिए, पायथन में संसाधनों को स्वचालित रूप से साफ़ करने के लिए एक शांत वाक्यविन्यास है - एक संदर्भ प्रबंधक । आप लिख सकते हैं:

 # Python with open("my-file") as file_handle: some code 

और यह सुनिश्चित करता है कि फ़ाइल some code रनटाइम पर खोली जाएगी, लेकिन उसके बाद - तुरंत बंद कर दी गई। अधिकांश आधुनिक भाषाओं में समतुल्य ( RAII , use , try-with-resource, defer , ...) हैं। और वे सभी मानते हैं कि नियंत्रण प्रवाह क्रम में है। और क्या होता है अगर हम goto का उपयोग करके ब्लॉक के with कूदते हैं? फाइल खुली है या नहीं? और अगर हम हमेशा की तरह बाहर जाने के बजाय वहां से बाहर कूद जाते हैं?

ब्लॉक के अंदर कोड पूरा होने के बाद, __exit__() विधि शुरू होती है जो खुले संसाधनों को बंद कर देती है, जैसे कि फाइलें और कनेक्शन।

क्या फाइल बंद होगी? goto , संदर्भ प्रबंधक केवल स्पष्ट तरीके से काम नहीं करते हैं।

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

कोई और goto नहीं

तो, पारंपरिक goto - जो फ़ंक्शन सीमाओं की उपेक्षा करता है - न केवल खराब है, क्योंकि इसका सही ढंग से उपयोग करना मुश्किल है। यदि केवल यही होता, तो goto ठहर सकता था - कई खराब भाषा निर्माण बने रहे।

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

"गो" जैसे भावों के खतरों के बारे में

तो, हमने goto कहानी पर ध्यान दिया। लेकिन क्या यह go संचालक पर लागू होता है? खैर ... सब सब में! सादृश्य चौंकाने वाला सटीक है।

गो एब्सट्रैक्ट को तोड़ते हैं।

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

यह प्रोग्राम में प्रवेश करने और छोड़ने के डेटा के प्रवाह के नियंत्रण को संदर्भित करता है। उदाहरण के लिए, कार्यक्रम 3MB / s की गति से डेटा प्राप्त करता है, और 1MB / s की गति से छोड़ता है, और तदनुसार कार्यक्रम अधिक से अधिक मेमोरी खपत करता है, लेखक द्वारा एक और लेख देखें

गो-एक्सप्रेशंस खुले संसाधनों की ऑटो-सफाई को तोड़ते हैं।

आइए फिर से कथन के with एक उदाहरण देखें:

 # Python with open("my-file") as file_handle: some code 

इससे पहले हमने कहा कि हमें "गारंटी" दी गई थी कि some code काम करने के दौरान फ़ाइल खुली रहेगी, और उसके बाद बंद हो जाएगी। लेकिन क्या होगा अगर some code एक पृष्ठभूमि कार्य शुरू करते हैं? : , , with , with , , , . , ; , , some code .

, , - , , .

, Python threading — , , — , with

, , , ( ). , . , .

go- .

, , (exceptions), . " ". , . , , . , , … , . , - . ( , , " - " — ; .) Rust — , , - — . (thread) , Rust .

, , join , errbacks Twisted Promise.catch Javascript . , , . , Traceback . Promise.catch .

, .

go

, goto , go- — , , , . , goto , , go .

, , ! :

• go -, , " ",
• , go -.

, Trio .

go

: , , , . , , :

, , , " " .

? " " ,

) , , ( ),
) , .

. , - . , .. [3]

: , , , "" , . Trio , async with :

, as nursery nursery . nursery.start_soon() , () : myfunc anotherfunc . . , , () , , .

, , — , , . , .

, .

:

, . यहाँ उनमें से कुछ हैं:

.

go- — , , , . — , , . , , .

.

, . :

 run_concurrently([myfunc, anotherfunc]) 

async.gather Python, Promise.all Javascript, ..

, , , . , accept , .
accept Trio:

 async with trio.open_nursery() as nursery: while True: incoming_connection = await server_socket.accept() nursery.start_soon(connection_handler, incoming_connection) 

, , run_concurrently . , run_concurrently — , , run_concurrently , .

.

. , , ? : . , async with open_nursery() nursery.start_soon() , — [4], , , . , , .

, , " ", :

• , , , , , .
• , .
• , .

, .

, , go-, .

, .

, - . , , . :

 async with my_supervisor_library.open_supervisor() as nursery_alike: nursery_alike.start_soon(...) 

, , . .

Trio , asyncio : start_soon() , Future ( , Future ). , ( , Trio Future !), .

, , .

, , — — .

Trio, . , , " " ( ), Cancelled . , , — - , " ", , .. , , . , , , .

.

" ", with . , with , .

.

, , . .

Trio, , … - . , . , — " " — , myfunc anotherfunc , . , , .

, : (re-raise) , . ,

" " , , , , , .

, , . ?

— ( ) , . , , , , .

, , - ( task cancellation ). C# Golang, — .

go

goto , with ; go - . उदाहरण के लिए:

• , , , . ( : - )
• — Python , ctrl-C ( ). , .

, . ?

… : ! , , . , , , break continue .

, . — , 1970 , goto .

. (Knuth, 1974, .275):

, goto , , " " goto . goto ! , , goto , . , , . , — , — "goto" .

: . , , . , , . , , .

, Happy Eyeballs ( RFC 8305 ), TCP . , — , , . Twisted — 600 Python . 15 . , , , . , , . , . ? . .

निष्कर्ष

— go , , , Futures , Promises ,… — goto , . goto , -- goto , . , , ; , . , goto , .

, , ( CTRL+C ) , .

, , , , — , goto . FLOW-MATIC , , - . , , Trio , , .

टिप्पणियाँ

Trio .

:

• "What colour is your function?",
• : The Function Colour Myth

Trio : https://trio.discourse.group/

धन्यवाद

Graydon Hoare, Quentin Pradet, and Hynek Schlawack . , , .

berez .

: FLOW-MATIC (PDF), .

Wolves in Action, Martin Pannier, CC-BY-SA 2.0 , .
, Daniel Borker, CC0 public domain dedication .

[2] WebAssembly , goto : ,

[3] , , , , :
The "parallel composition" operator in Cooperating/Communicating Sequential Processes and Occam, the fork/join model, Erlang supervisors, Martin Sústrik's libdill , crossbeam::scope / rayon::scope Rust. golang.org/x/sync/errgroup github.com/oklog/run Golang.
, - .

[4] start_soon() , , start_soon , , , . , .

Nathaniel J. Smith , Ph.D., UC Berkeley numpy , Python . Nathaniel .

:

• , Bob Nystrom
• , golang
• , PsyHaSTe Haskell, Golang C#
• : Go , Go , python , C# (, JS)

, , , Haskell , , .

( , 0xd34df00d , ) , ( Happy Eyeballs ), .

, Trio ? Haskell Golang ?

: