हम स्रोत कोड के बजाय सिंटैक्स ट्री को संग्रहीत क्यों नहीं करते हैं?

111

हमारे पास बहुत सारी प्रोग्रामिंग लैंग्वेज हैं। हर भाषा को पार्स किया जाता है और कोड में अनुवादित होने से पहले वाक्यविन्यास की जाँच की जाती है ताकि एक सार वाक्यविन्यास ट्री (एएसटी) बनाया जाए।

हमारे पास यह सार सिंटेक्स ट्री है, हम स्रोत कोड (या स्रोत कोड के बगल में) के बजाय इस सिंटैक्स ट्री को क्यों संग्रहीत नहीं करते हैं?

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

इस दृष्टिकोण के पेशेवरों और विपक्ष क्या हैं?

language-agnostic

— Calmarius
स्रोत

37

लिस्प को आम तौर पर अमूर्त सिंटैक्स ट्री के रूप में लिखा जाता है। यह अधिक अल्गोल जैसी भाषाओं को नहीं पकड़ पाया।

— डेविड थॉर्नले

2

मुझे विश्वास नहीं हो रहा है कि डेविड केवल यह उल्लेख करने के लिए कि एलआईएसपी कार्यक्रम एक सार वाक्यविन्यास वृक्ष हैं।

— वूहोइनटेड

3

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

— नौकरी

1

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

— इरा बैक्सटर

3

पार्सिंग की समस्या को तकनीकी रूप से अच्छी तरह से समझा जाता है, लेकिन यह C या C ++ को पार्स करने का एक आसान काम नहीं है क्योंकि वे गंदी गंदी भाषाएं हैं। कई कंपाइलर पार्सर C या C ++ से ASTs: क्लैंग, जीसीसी, ... वे प्रोग्राम स्टोरेज के लिए अभिप्रेत नहीं हैं, और जीसीसी बुरी तरह से कंपाइलर बनना चाहता है, न कि प्रोग्राम एनालिसिस टूल। हमारे डीएमएस सॉफ्टवेयर रीइंजीनियरिंग टूलकिट C और C ++ की कई बोलियों को पार्स करता है, एएसटीएस, प्रतीक तालिकाओं और विभिन्न प्रकार के प्रवाह विश्लेषण कलाकृतियों का उत्पादन करता है। इस दृष्टिकोण का बड़ा प्रो स्वचालित परिवर्तन उपकरण बनाने की क्षमता है। semanticdesigns.com/Products/DMS/DMSToolkit.html

— इरा बैक्सटर

72

व्हॉट्सएप और टिप्पणियाँ

आम तौर पर एएसटी में व्हॉट्सएप, लाइन टर्मिनेटर और टिप्पणियां शामिल नहीं होती हैं।

अर्थपूर्ण स्वरूपण

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

कोड जो संकलित नहीं किया जा सकता है

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

हो सकता है कि उपयोगकर्ता अनुचित कोड न करें, लेकिन उन्हें निश्चित रूप से स्थानीय रूप से सहेजने की आवश्यकता है।

कोई भी दो भाषाएं पूर्ण मिलान नहीं हैं

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

निजी अनुभव:

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

— केविन मैककॉर्मिक
स्रोत

9

पार्सर्स हैं जो एएसटी में टिप्पणियों और लेआउट पर कब्जा करते हैं। हमारे डीएमएस सॉफ्टवेयर Rengineering टूलकिट यह ठीक है। इसमें अवैध कोड के साथ एक कठिन समय है; इसमें एक सटीक भाषा पार्सर है।

— इरा बैक्सटर

2

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

— पीटर ओल्सन

दिलचस्प उपकरण, पीटर, मुझे इसके बारे में पता नहीं था।

— केविन मैककॉर्मिक

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

— cregox

43

हम स्रोत कोड के बजाय इस सिंटैक्स ट्री को क्यों संग्रहीत नहीं करते हैं? एक टीम में प्रत्येक प्रोग्रामर इस पेड़ को किसी भी भाषा में क्रमबद्ध कर सकता है, वे चाहते हैं और समाप्त होने पर वापस एएसटी को पार्स कर सकते हैं।

वास्तव में, यह एक उचित विचार है। माइक्रोसॉफ्ट के पास 1990 के दशक में एक रिसर्च प्रोजेक्ट था, जो लगभग वैसा ही था ।

कई परिदृश्य दिमाग में आते हैं।

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

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

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

तो, संक्षेप में, यह एक प्यारा विचार है, लेकिन यह तुलनात्मक रूप से छोटे लाभ के लिए अतिरिक्त कार्य है। इसलिए शायद ही कोई ऐसा करता हो।

— एरिक लिपर्ट
स्रोत

3

दरअसल, आप पेड़-भाषा को स्वतंत्र रूप से कर सकते हैं। पेड़ों के निर्माण के लिए आपको भाषा विशिष्ट पार्सर की आवश्यकता होती है। हमारे स्मार्ट डिफरेंसर लाइन ऑफ टूल्स देखें, जो कई भाषाओं के एएसटी की तुलना करते हैं। वे सभी एक ही अंतर्निहित अंतर इंजन का उपयोग करते हैं। semanticdesigns.com/Products/SmartDifferencer

— इरा बैक्सटर

1

मैं किसी दिन विजुअल स्टूडियो में मेरी शैली-सुंदर-प्रिंट-ऑन-लोड-टीम-स्टाइल-सुंदर-प्रिंट-ऑन-सेव को देखने की उम्मीद करता हूं ... वर्षों से उम्मीद कर रहा था ... कोई भाग्य अभी तक नहीं ...

— रोमन स्टार्कोव

19

आप तर्क दे सकते हैं कि यह ठीक उसी प्रकार है जैसे कि बाइट कोड .NET में है। Infact redgate का रिफ्लेक्टर प्रोग्राम बाइट कोड को .NET प्रोग्रामिंग लैंग्वेज की रेंज में ट्रांसलेट करता है।

हालांकि, समस्याएं हैं। सिंटैक्स भाषा विशिष्ट है जितना कि ऐसी चीजें हैं जो आप एक भाषा पर प्रतिनिधित्व कर सकते हैं जिनका अन्य भाषाओं में कोई प्रतिनिधित्व नहीं है। यह .NET में C ++ के साथ होता है। केवल .NET भाषा है जिसमें सभी 7 एक्सेस स्तरों तक पहुंच है।

.NET वातावरण के बाहर यह बहुत पेचीदा हो जाता है। प्रत्येक भाषा तब संबंधित पुस्तकालयों का अपना सेट होना शुरू करती है। यह सी और जावा दोनों में एक सामान्य वाक्यविन्यास को प्रतिबिंबित करना संभव नहीं होगा जो निर्देशों के एक ही निष्पादन को प्रतिबिंबित करता है क्योंकि वे बहुत ही अलग तरीके से simular समस्याओं को हल करते हैं।

— माइकल शॉ
स्रोत

5

कभी F # द्वारा निर्मित MSIL को विघटित करने की कोशिश की गई?

— एसके-तर्क

12

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

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

यह अजीब है कि प्रोग्रामर का प्रतिनिधित्व करने के लिए प्रोग्रामर की डेटा संरचना कितनी बार स्ट्रिंग्स युक्त फ़ाइलों का एक गुच्छा है।

— psr
स्रोत

5

क्या आप VBc और C # कंपाइलर्स को API के रूप में खोलने के लिए Microsoft के " रोसलिन " प्रोजेक्ट के विकास का अनुसरण कर रहे हैं? एक पूर्वावलोकन रिलीज उपलब्ध है।

— कार्सन 63000

11

मुझे लगता है कि सबसे प्रमुख बिंदु ये हैं:

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

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

— कोनराड रुडोल्फ
स्रोत

4

संभावित लाभ यह होगा कि यह "टैब बनाम रिक्त स्थान", "यूनिक्स बनाम विंडोज़ ब्रेसिंग / इंडेंटेशन", "m_ उपसर्गों को सदस्यों के सामने या नहीं" जैसी अंतहीन बहस को समाप्त कर सकता है, क्योंकि उन्हें सरल आईडीई विकल्पों में बदल दिया जा सकता है।

— nikie

1

@ मिक्की ट्रू लेकिन आप पहले से ही astyleरिफॉर्मिंग टूल्स का उपयोग करके ऐसा कर सकते हैं - जैसे या अननिवर्सलीडेंट। आर्कन बाइनरी प्रारूपों के लिए कोई ज़रूरत नहीं है।

— कोनराड रुडोल्फ

2

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

— पीटर टेलर

1

यदि आपको लगता है कि "कोई लाभ नहीं है," तो आपने इंटेंटेशनल सॉफ़्टवेयर के डोमेन वर्कबेन्च को नहीं देखा है।

— क्रेग स्टंट्ज़

1

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

— क्रेग स्टंट्ज

6

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

दूसरी ओर, यदि आप केवल एएसटी स्टोर करते हैं, तो आप टिप्पणी जैसी चीजों को खो देते हैं जिन्हें पुनर्प्राप्त नहीं किया जा सकता है।

— Tesserex
स्रोत

6

और यदि आप टिप्पणी को वाक्यविन्यास पेड़ का हिस्सा बनाते हैं (टिप्पणी नोड्स के साथ जो किसी भी चीज़ का बच्चा हो सकता है)?

— शाफ़्ट

हमारे उपकरण ठीक यही करते हैं। इस धागे में मेरी अन्य टिप्पणियाँ देखें।

— इरा बैक्सटर

4

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

उदाहरण के लिए, X ++ में एक 'सलेक्ट' स्टेटमेंट है, जो बहुत सारे अतिरिक्त कोड (अतिरिक्त कक्षाएं, अतिरिक्त तर्क, आदि) के बिना C # में नहीं लिखा जा सकता है। http://msdn.microsoft.com/en-us/library/aa558063.aspx

जो मैं यहां कह रहा हूं, वह यह है कि कई भाषाओं में वाक्य रचनाएं हैं जो समान भाषा के कोड के बड़े ब्लॉक में अनुवाद करती हैं या ऐसे तत्व भी हैं जो दूसरों में बिल्कुल भी मौजूद नहीं हैं। यहाँ एक उदाहरण है कि एएसटी दृष्टिकोण क्यों काम नहीं करेगा:

भाषा X में एक कीवर्ड K है जो अनुवादित है, एएसटी में 4 बयानों में: एस 1, एस 2, एस 3 और एस 4। एएसटी अब भाषा वाई में अनुवादित है और एक प्रोग्रामर एस 2 बदलता है। अब क्या होता है अनुवाद X के साथ? किसी एक कीवर्ड के बजाय 4 कथनों के रूप में कोड का अनुवाद किया जाता है ...

एएसटी दृष्टिकोण के खिलाफ अंतिम तर्क प्लेटफ़ॉर्म फ़ंक्शन हैं: जब कोई फ़ंक्शन प्लेटफ़ॉर्म में एम्बेडेड होता है तो क्या होता है? .NET के एनवायरनमेंट की तरह। GetEnvironmentVariable। आप इसका अनुवाद कैसे करेंगे?

— विक्टर हर्डुगासी
स्रोत

4

इस विचार के आसपास एक सिस्टम बनाया गया है: JetBrains MPS । एक संपादक थोड़ा अजीब है, या बस अलग है, लेकिन सामान्य तौर पर यह इतनी बड़ी समस्या नहीं है। सबसे बड़ी समस्या यह है अच्छी तरह से, कि यह नहीं एक पाठ किसी भी अधिक है, इसलिए आप सामान्य पाठ आधारित उपकरणों के किसी भी उपयोग नहीं कर सकते -, अन्य संपादकों grep, sed, विलय और diff उपकरण, आदि

— SK-तर्क
स्रोत

2

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

— स्टीवन ज्यूरिस

एएसटी को मानव पठनीय प्रारूप में बचाया जा सकता है और बाइनरी में नहीं। क्या अब आप linux टूल्स के साथ उदाहरण के लिए हर तरीके को कोड में बदल सकते हैं जो पैरामीटर serializable ऑब्जेक्ट के रूप में लेता है? यह लिखना बहुत कठिन होगा, लेकिन एएसटी इसे बहुत आसान बनाता है।

— 22

1

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

— इरा बैक्सटर

@ इरा बैक्सटर, बेशक यह एएसटी के साथ आसान है। लेकिन मौजूदा बुनियादी ढांचे में एकीकृत करना बहुत कठिन है ।

— एसके-तर्क

4

वास्तव में कई उत्पाद हैं, जिन्हें आमतौर पर "भाषा कार्यक्षेत्र" के रूप में जाना जाता है जो एएसटी और वर्तमान को स्टोर करते हैं, उनके संपादकों में, एक विशेष भाषा में एएसटी का "प्रक्षेपण" वापस। जैसा कि @ sk- लॉजिक ने कहा, JetBrains का MPS एक ऐसी प्रणाली है। एक और इरादे सॉफ्टवेयर के इरादे कार्यक्षेत्र है।

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

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

— लैरी ओब्रायन
स्रोत

"भाषा कार्यक्षेत्र" आवश्यक रूप से कच्चे एएसटी के भंडारण पर आधारित नहीं होना चाहिए। वे सादे पाठ सिंटैक्स-उन्मुख हो सकते हैं, उदाहरण के लिए देखें meta-alternative.net/pfront.pdf (और यह वास्तव में Visual Studio और Emacs संपादक को इसके शीर्ष पर लागू किए गए किसी भी ईडीएसएल के साथ विस्तारित करता है)।

— एसके-तर्क

यह एक दिलचस्प पेपर है; यह मुझे याद दिलाता है (महत्वाकांक्षा में, कार्यान्वयन में बिल्कुल नहीं) सुगरज नामक एक उपकरण जो कुछ हफ्तों पहले SPLASH / OOPSLA में प्रस्तुत किया गया था: uni-marburg.de/fb12/ps/research/gugarj

— लैरी ओब्रायन

दिलचस्प, मैं कोशिश करूँगा कि एक के रूप में अच्छी तरह से।

— एसके-तर्क

3

आप मेरा मन पढ़ रहे हैं।

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

समस्याएँ जो आप प्रस्तावित करते हैं:

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

समय के साथ, विकास के प्रयास को बढ़ाया जाएगा और हम टचस्क्रीन और एएसटी का उपयोग करके विकसित होंगे। टंकण एक आवश्यकता से कम हो जाएगा। मैं देख रहा हूं कि हम जहां हैं, वहां से तार्किक प्रगति के रूप में, हम कंप्यूटर का उपयोग कैसे करते हैं, यह देखते हुए कि आज # 1 हल होगा।

हम पहले से ही पेड़ों के साथ काम कर रहे हैं। लिस्प महज क्रमबद्ध एएसटीएस है। XML (और HTML, विस्तार से) सिर्फ एक क्रमबद्ध पेड़ है। खोज करने के लिए, हमारे पास पहले से ही कुछ प्रोटोटाइप हैं: एक्सपीथ और सीएसएस (क्रमशः एक्सएमएल और एचटीएमएल के लिए)। जब चित्रमय उपकरण बनाए जाते हैं जो हमें CSS-शैली के चयनकर्ताओं और संशोधक बनाने की अनुमति देते हैं, तो हम # 2 के भाग को हल करेंगे। जब उन चयनकर्ताओं को रेगेक्स का समर्थन करने के लिए बढ़ाया जा सकता है, तो हम करीब होंगे। अभी भी दो एक्सएमएल या एचटीएमएल डॉक्स की तुलना करने के लिए एक अच्छा ग्राफिकल डिफरेंशियल टूल की तलाश है। जैसे ही लोग उन उपकरणों को विकसित करते हैं, # 2 हल हो जाएगा। लोग पहले से ही ऐसी चीजों पर काम कर रहे हैं; वे अभी वहाँ नहीं हैं, फिर भी।

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

— Meower68
स्रोत

1

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

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

आपको लोड करने पर अपनी खुद की शैली में फ़ाइल को स्वचालित रूप से बदलने और बचत करते समय टीम शैली में बदलने के लिए हुक का निर्माण करने में भी सक्षम होना चाहिए।

— गुस्ताव बर्तराम
स्रोत

1

फिर आपको अभी भी एक अर्थपूर्ण अंतर और मर्ज (यानी, फिर, एएसटी-स्तर) की आवश्यकता होगी।

— तर्क

नहीं, स्रोत को संग्रहीत करने के लिए संपादक सुधार टीम शैली में वापस आता है - इसलिए आप एक ही प्रकार के विरुद्ध एक स्रोत प्रकार की तुलना करेंगे।

— गुस्ताव बर्तराम

एक अच्छा बिंदु, एक सामान्यीकृत प्रतिनिधित्व सभी समस्याओं को हल करता है

— SK-logic

1

नहीं, यह केवल पहचान के लिए दो फ़ाइलों को कंपेयर करने की समस्याओं को हल करता है। यदि आप फ़ाइलों के बीच अंतर देखना चाहते हैं, तो आपको आदर्श रूप से ऐसी चीज़ की ज़रूरत है जो संरचना को समझती हो। मैं अपनी भावनाओं से प्यार करता हूं, लेकिन यह संरचना को नहीं समझता है।

— इरा बैक्सटर

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

— गुस्ताव बर्तराम

1

स्रोत कोड के बजाय एएसटी को पढ़ना और संशोधित करना मुश्किल है।

हालांकि, कुछ संकलक संबंधित उपकरण एएसटी का उपयोग करने की अनुमति देते हैं। जावा बाइटकोड और .NET इंटरमीडिएट कोड एक एएसटी के समान काम करते हैं।

— umlcat
स्रोत

1

टेक्स्ट के साथ ऐसा करने के लिए यांत्रिक उपकरणों के साथ एएसटी को मज़बूती से संशोधित करना आसान है। आप इसे पैटर्न-निर्देशित परिवर्तनों के साथ कर सकते हैं। देखें semanticdesigns.com/Products/DMS/ProgramTransformation.html

— इरा बैक्सटर

2

इसे अब LISPers को बताएं ...

— hugomg

@ इरा बैक्सटर। मुझे पता है, Im वास्तव में एक कस्टम विजुअल टूल पर काम कर रहा है जो सीधे एक एएसटी के साथ काम करता है, हालांकि, कभी-कभी, डेवलपर्स को दृश्य के बजाय पाठ के साथ काम करना पड़ता है। कुछ एएसटी को पाठ में एक छोटी प्रोग्रामिंग भाषा के रूप में भी दर्शाया गया है।

— umlcat 18

@umlcat, क्या आप एएसटीएस के लिए एक दृश्य उपकरण पर अपने काम के बारे में अधिक बता सकते हैं?

— डैनियल अल्बुशेट

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

— umlcat

0

यह एक अच्छा विचार है; लेकिन हर भाषा का एएसटी हर दूसरे से अलग है।

एकमात्र अपवाद जो मुझे पता है कि VB.NET और C # के लिए है, जहां Microsoft का तर्क है कि वे "अलग वाक्यविन्यास के साथ सटीक एक ही भाषा" हैं। यहां तक कि अन्य .NET लैंग्वेज (IronPython, F #, जो भी हो) एएसटी स्तर पर भिन्न हैं।

जेवीएम भाषाओं के साथ एक ही बात है, वे सभी एक ही बाईटेकोड को लक्षित करते हैं, लेकिन भाषा के निर्माण अलग-अलग हैं, जिससे यह अलग-अलग भाषाएं और अलग-अलग एएसटी हैं।

यहां तक कि कॉफ़ीस्क्रिप्ट और Xtend जैसी 'पतली परत' भाषाएँ, अंतर्निहित भाषाओं (जावास्क्रिप्ट और जावा, क्रमशः) के सिद्धांत का एक बहुत हिस्सा साझा करती हैं; एएसटी स्तर पर बनाए रखने वाले (या होने चाहिए) उच्च स्तर की अवधारणाएं पेश करते हैं।

अगर Xtend को Java AST से फिर से तैयार किया जा सकता है, तो मुझे लगता है कि इसे Java-to-Xtend 'uniler' के रूप में परिभाषित किया गया होगा जो जादुई रूप से मौजूदा Java कोड से उच्च स्तर का अमूर्त बनाता है, क्या आपको नहीं लगता?

— जेवियर
स्रोत

1

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

— एरिक लिपर्ट

@ EricLippert: यह शर्म की बात है। ऐसा नहीं है कि मैंने कभी भी भाषा सीखने की योजना बनाई है, लेकिन यह एक अच्छे अपवाद की तरह लगता है। मुझे लगता है कि htat लिस्प-जैसे-डायलन और एल्गोल-जैसे-डायलन को केवल 'एक ही भाषा के साथ अलग वाक्यविन्यास' उदाहरण के रूप में छोड़ देता है।

— जेवियर