पापा कार्लो और वृद्धिशील संकलक

साथियों,

और याद रखें कि नई प्रोग्रामिंग भाषाओं की समस्याओं के बारे में प्रोग्रामिंग लैंग्वेज कॉलिन मैकमिलन के डेवलपर हैबर चेकलिस्ट पर इस तरह का अनुवाद लेख था? लेख बस अद्भुत है! यदि आप इसे नहीं पढ़ते हैं, तो इसे देखना सुनिश्चित करें।

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

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

समस्या

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

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

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

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

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

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

दुर्भाग्य से, एक वृद्धिशील संकलक के लिए एक पार्सर विकसित करना एक काफी गैर-तुच्छ कार्य है। विशेष रूप से यह देखते हुए कि पार्सर को सिंटैक्स त्रुटियों वाले कोड को पार्स करने में भी सक्षम होना चाहिए। उदाहरण के लिए, यदि कोई प्रोग्रामर वर्ग की घोषणा की शुरुआत में एक सिंटैक्स त्रुटि करता है:

import javax.swing.JApplet; import java.awt.Graphics; public class Hello extends JApplet { int x = //    ,    . public void paintComponent(final Graphics g) { g.drawString("Hello, world!", 65, 95); //         . } } 

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

काफी कम तैयार जनरेटर और वृद्धिशील पार्सर्स के कॉम्बिनेटर हैं, और वे बहुत विशिष्ट हैं। कहते हैं, ANTLR जैसे राक्षसी उत्पाद में, नवीनतम संस्करण ने किसी न किसी रूप में वृद्धिशील पार्सिंग के लिए समर्थन जोड़ा। मुझे कहना होगा कि ANTLR एक भारी उत्पाद है, जावास्क्रिप्ट में PEG.js जैसे नियमित (गैर-वृद्धिशील) पार्सर्स के किसी भी पीईपी कॉम्बिनेटर की तुलना में इसके साथ काम करना बहुत अधिक कठिन है।

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

निर्णय

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

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

फिर डेवलपर उन कोड संपादकों के एपीआई के साथ निर्मित संकलक के आउटपुट को जोड़ता है जिसे वह समर्थन करना चाहता है। उदाहरण के लिए, उदात्त पाठ एपीआई के साथ ।

मेरी राय में, यह दृष्टिकोण खरोंच से संकलक और भाषा प्लगइन्स को अलग-अलग विकसित करने की तुलना में बहुत सरल है।

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

परीक्षणों में से एक में, इनपुट पर निम्न जोंस परोसा जाता है, जिसमें स्पष्ट वाक्यविन्यास त्रुटियां होती हैं:

 { "key 1": "hello world", "key 1.1": "key 2": ["array value 1", "array value 2", "array value 3"], } 

फिर भी, आउटपुट पर, पार्सर काफी सफलतापूर्वक उन हिस्सों को पार्स करता है जिनमें त्रुटियां नहीं होती हैं। और वह एक ऐसा पेड़ बनाता है:

 object 1 { entry: entry 27 { key: "key 1" value: string 26 { value: "hello world" } } entry: entry 25 { key: "key 1.1" value: string 24 { value: "key 2" } } } 

सिंटैक्स त्रुटियों की ओर इशारा करते हुए, निश्चित रूप से:

  > code mismatched: { "key 1": "hello world", "key 1.1": "key 2"<<<: ["array value 1", "array value 2", "array value 3"],>>> } 

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

इनपुट फ़ाइल	आकार (पंक्तियाँ)	पिछले (लाइन) के साथ अंतर	एएसटी पार्सिंग और बिल्डिंग टाइम (मिलीसेकंड)
step0.json	634	-	270
step1.json	634	1	7
step2.json	634	2	8

निष्कर्ष और संदर्भ

दुर्भाग्य से, लेख का प्रारूप विवरण को छोड़ते हुए विषय को केवल सबसे सामान्य शब्दों में रेखांकित करना संभव बनाता है। फिर भी, मुझे उम्मीद है कि मैं वृद्धिशील संकलन की समस्या और कोड संपादकों के लिए भाषा एक्सटेंशन के काम का सार बताने में कामयाब रहा।

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

यहां कुछ उपयोगी लिंक दिए गए हैं:

• व्याकरण किट । IntelliJ Idea के लिए प्लगइन डेवलपमेंट में प्रयुक्त JetBrains पार्सर कंस्ट्रक्टर।
• जावा विकास उपकरण । जावा वृद्धिशील पार्सर ग्रहण द्वारा आंतरिक रूप से उपयोग किया जाता है।
• लकवा मार गया । स्काला और जावा के लिए गैर-वृद्धिशील पार्सर निर्माता। इस तथ्य के बावजूद कि वह साधारण, गैर-वृद्धिशील पार्सर का निर्माण करता है, यह स्काला समुदाय में सबसे विकसित और प्रसिद्ध पार्सर निर्माणकर्ताओं में से एक है। मेरी राय में, परियोजना ध्यान देने योग्य है।
• पापा कार्लो । ऊपर उल्लेखित स्काला के लिए मेरा खुद का वृद्धिशील पार्सर निर्माता।