आप जो चाहते हैं वह वाक्यविन्यास-निर्देशित structure editor है। यह वह है जो एएसटी भवन के साथ पार्सिंग को जोड़ता है और भविष्यवाणी करने के लिए पार्सर का उपयोग करता है कि आप आगे क्या टाइप कर सकते हैं (या तो सिंटैक्स पूर्णता), या कंपाइलर के आखिरी रन के लिए टाई है, ताकि यह संपादन बिंदु की व्याख्या कर सके कि वैध पहचानकर्ता क्या देख सकते हैं कंपाइलर की प्रतीक तालिका का निरीक्षण करके अगला आओ जो कोड में उस बिंदु पर अंतिम प्रासंगिक था।
सबसे कठिन हिस्सा उपयोगकर्ता को एक निर्बाध अनुभव प्रदान कर रहा है; उसे बहुत विश्वास करना है कि वह पाठ संपादित कर रही है या (संरचना संपादकों के साथ अनुभव दिखाता है) वह इसे अजीब के रूप में अस्वीकार कर देगी।
यह समन्वय और काफी प्रयास करने के लिए बहुत सारी मशीनरी है। अच्छी खबर यह है कि आपको संकलक के लिए किसी भी तरह की पार्सर चाहिए; यदि संपादन भी पार्स, संकलक द्वारा आवश्यक एएसटी अनिवार्य रूप से उपलब्ध है। (बेशक आपको भी बैच संकलन के बारे में चिंता करने की ज़रूरत है)। कंपाइलर को एक प्रतीक तालिका बनाना है; तो आप इसे संपादन पूर्ण करने की प्रक्रिया में उपयोग कर सकते हैं। अधिक कठिन खबर यह है कि पार्सर बनाने के लिए बहुत कठिन हैं; वे सिर्फ उपयोगकर्ता-दृश्य वाक्यविन्यास त्रुटि घोषित नहीं कर सकते हैं और छोड़ सकते हैं; बल्कि उन्हें एक ही पल में कई त्रुटियों से सहिष्णु होना चाहिए, टुकड़ों के लिए आंशिक एएसटी रखें, और उन्हें एक साथ सिलाई करें क्योंकि उपयोगकर्ता द्वारा त्रुटियों को हटा दिया जाता है।
Berkeley Harmonia लोग इस क्षेत्र में अच्छे काम कर रहे हैं। समस्याओं का विस्तृत ज्ञान और उन्हें संभालने के लिए एक दृष्टिकोण प्राप्त करने के लिए अपने कुछ कागजात पढ़ने में आपकी परेशानी के लायक है।
अन्य प्रमुख दृष्टिकोण लोगों (विशेष रूप से Intentional Programming और XText) की कोशिश कर रहा हो रहे हैं वस्तु उन्मुख संपादकों, जहाँ आप प्रत्येक एएसटी नोड के लिए संपादन कार्यों देते हैं, और एक एएसटी नोड के साथ स्क्रीन पर हर बिंदु को संबद्ध कर रहे हैं। फिर क्रियाओं को संपादित करने से एएसटी-नोड विशिष्ट क्रियाएं आती हैं (सम्मिलित-चरित्र, सही हो जाएं, ऊपर जाएं, ...) और यह तय कर सकता है कि कैसे कार्य करें और स्क्रीन को कैसे संशोधित करें। तर्कसंगत रूप से आप इन संपादकों को कुछ भी कर सकते हैं; यह अभ्यास में थोड़ा कठिन है। मैंने इन संपादकों का उपयोग किया है; वे पाठ संपादकों की तरह महसूस नहीं करते हैं। कुछ उत्साही उपयोगकर्ता हैं, लेकिन वाईएमएमवी।
मुझे लगता है कि आपको शायद ऐसा एक संपादक बनाने की कोशिश करने के बीच चयन करना चाहिए, बनाम एक नया लैंगेज परिभाषित करने की कोशिश कर रहा है। एक बार में दोनों करना आपको परेशानियों से डूबने की संभावना है।
स्रोत
2011-04-24 04:12:57
उत्तर के लिए धन्यवाद। जबकि आप कुछ मूल्यवान लिंक प्रदान करते हैं, फिर भी मैं कंपाइलर में पार्सर और आईडीई में पार्सर के बीच वर्णित मतभेदों की सीमा पर कुछ अंतर्दृष्टि याद करता हूं। उदाहरण के लिए मैं आईडीई में पार्सर को पूरे कोड + वर्तमान लाइन के कुछ फ़ंक्शन के रूप में कल्पना करता हूं -> संभव पूर्णता जो कुछ कंपेलरों में पहले से मौजूद है (उदाहरण के लिए जीसीसी, जब आप किसी फ़ंक्शन में गलत तर्क प्रकार प्रदान करते हैं तो विकल्प प्रस्तावित करता है)। –
आईडीई पार्सर को कंपाइलर पार्सर की तुलना में "और अधिक करना है, जैसा कि आपने ध्यान दिया है) जैसा कि आपको पता होना चाहिए कि * कानूनी * अगला (कंपाइलर के रूप में) क्या है और क्या * संभावित * अगला है (जो संकलक आमतौर पर बिल्कुल परवाह नहीं करता है)।"संभावित" पूरे आवेदन के संदर्भ पर आधारित है; ज्यादातर जो कंपाइलर से बने प्रतीक तालिका डेटा से आते हैं और आईडीई द्वारा तर्कसंगत रूप से अपडेट किए जाते हैं। (जीसीसी आपको विकल्प दे रहा है वास्तव में यह "संभावित" प्रकार का निदान कर रहा है। निश्चित रूप से, यह सहायक है, यही कारण है कि आप इसे आईडीई में भी चाहते थे :) –