एक डीएसएल एक एपीआई के रूप में सरल नहीं हो सका और इसलिए एक पार्सर की आवश्यकता नहीं है? या क्या मैं गलत समझ रहा हूं कि डोमेन विशिष्ट भाषा वास्तव में क्या है? मैंने सोचा कि यह किसी विशेष डोमेन समस्या को हल करने के लिए नियमों के किसी संगठित सेट को संदर्भित करता है। एक एपीआई उस परिभाषा को फिट करने लगती है, है ना?डीएसएल के लिए आवश्यक पार्सिंग उपकरण क्यों हैं?
आप एक सामान्य प्रोग्रामिंग भाषा के भीतर एक डीएसएल एम्बेड कर सकते हैं। यह अक्सर एक अच्छा समाधान है। (आप कह सकते हैं कि यह डीएसएल एक विशेष एपीआई का रूप लेता है।)
आप अपने डोमेन की अवधारणाओं का प्रतिनिधित्व करने के लिए अपने स्वयं के दुभाषिया के साथ एक अलग भाषा भी बना सकते हैं। यह एक बड़ा उपक्रम होता है, और अक्सर आवश्यक नहीं है।
आपके पास अभी भी मेजबान भाषा का अर्थशास्त्र होगा।
उदा।: एक अनिवार्य भाषा में कार्यात्मक प्रोग्रामिंग काम नहीं करती है। तो आपके पास इस अनिवार्य भाषा में एक कार्यात्मक डीएसएल जोड़ा गया है ...
आह। तो एक डीएसएल का उद्देश्य किसी विशेष भाषा की अर्थपूर्ण सीमाओं को विस्तारित करना है? और यही वह जगह है जहां पार्सर की आवश्यकता है - पार्सर आपके कस्टम अर्थपूर्ण एक्सटेंशन को 'व्याख्या करता है' - क्या यह सही है? –
यह डीएसएल की मेरी व्याख्या है, हालांकि मुझे केवल बाहरी डीएसएल के साथ अनुभव है। कहें, एसक्यूएल;) – Leonidas
आप कार्यान्वयन के साथ अवधारणा को भ्रमित कर रहे हैं। एक डोमेन-विशिष्ट भाषा सामान्य रूप से समस्याओं को हल करने के विवरण के लिए सामान्य भाषा होने के बजाय समस्या डोमेन के "करीबी" के रूप में माना जाता है, जो किसी विचार का कोई प्रतिनिधित्व है।
हां, एक डीएसएल एक एपीआई के रूप में लागू किया जा सकता है, जो समस्या डोमेन में विशेष अवधारणाओं को संदर्भित करता है, लेकिन एक पाठ फ़ाइल के रूप में प्रतिनिधित्व करते समय एक डीएसएल समान रूप से मान्य है।
व्यावहारिक प्रोग्रामर: जर्नलमैन से मास्टर में डीएसएल का एक अच्छा विवरण और परिस्थितियों के साथ वे परिस्थितियों में उपयोगी विवरण शामिल हैं। अत्यधिक सिफारिशित।
हां, बिल्कुल - केवल एपीआई डीएसएल के रूप में अच्छी तरह से काम करेगा यदि मेजबान भाषा में इसका समर्थन करने के लिए पर्याप्त लचीलापन है।
रूबी इस तरह के लिए एक बहुत अच्छी भाषा है, विशेष रूप से वैकल्पिक माता-पिता और अन्य लचीलापन दिए गए हैं।
रेल अक्सर डेटाबेस चालित वेब अनुप्रयोगों लिखने के लिए एक डीएसएल के रूप में जाना जाता है।
रेक लेखन (स्मार्ट) मेकफ़ाइल के लिए डीएसएल के साथ एक बिल्ड सिस्टम है।
मेरा अपना OOFILE एक रूपरेखा आप C++ डाटाबेस अनुप्रयोग लिखने के लिए एक डीएसएल के रूप में मानते सकता है - यह dBase से प्रेरित था और सी ++ ऑपरेटर ओवरलोडिंग, स्थानीय वस्तुओं और धारा मुहावरों का बहुत भारी उपयोग करता है।
फर्थ क्लासिकल रूप से एक ऐसी भाषा है जो डीएसएल और एपीआई के बीच की रेखा को धुंधला करता है, जो फॉरथ प्रोग्राम के रूप में अंतरिक्ष-अलग शब्दों की एक श्रृंखला से थोड़ा अधिक होता है। शायद फर्थ डीएसएल का सबसे प्रभावशाली उदाहरण Abundance - प्रचुरता एक उपयुक्त-आधारित व्यावसायिक प्रोग्रामिंग भाषा है, जिसे बीबीएल फर्थ में लिखा गया है। बीबीएल एक 32 बिट डॉस फोर्थ कंपाइलर है। के रूप में वितरित किया गया है। चेतावनियां देखें। यह बेहोश दिल के लिए नहीं है। यह मुख्य रूप से तीसरी दुनिया के लिए सॉफ्टवेयर विकसित करने वाले किसी व्यक्ति के लिए ब्याज का होगा जहां आपको पुरानी क्लंकर एक्सटी और एटी कंप्यूटर पर तेजी से निष्पादन की आवश्यकता है। आप इसके साथ कुछ बहुत परिष्कृत डेटा एंट्री प्रोग्राम लिख सकते हैं जो आधुनिक डेटा एंट्री प्रोग्राम्स के आसपास मंडल चलाएंगे।
और निश्चित रूप से, एक ग्राफिकल डीएसएल को कोई पार्सिंग की आवश्यकता नहीं होगी।
यह वास्तव में भ्रामक उत्तर है। डीएसएल प्रोग्रामर से कुछ को "डीएसएल टुकड़े स्वीकार करना" है, और जांचें कि क्या दर्ज किया गया है वैध है। चाहे वह स्ट्रिंग-आधारित भाषाओं के लिए एक पारंपरिक पार्सर जेनरेटर है, या एक एड्होक ग्राफ़िक यूआई जो बक्से को जोड़ने वाले बक्से और तीरों को स्वीकार करता है, या ग्राफ़-व्याकरण से स्वचालित रूप से जेनरेट किया गया UI, आपको अभी भी यह मशीनरी होना है। और एक पाठ आधारित डीएसएल के लिए मशीनरी वर्तमान में एक ग्राफिकल लैंगेज के लिए एक से अधिक रखना आसान है। आप कह सकते हैं कि एक सुअर एक कुत्ता है, लेकिन यह अभी भी एक सुअर है। –
@Ira: मुझे लगता है कि आपको विजुअल स्टूडियो एसडीके में डीएसएल टूलकिट देखना चाहिए। कोई पार्सिंग नहीं है। टुकड़ों की कोई स्वीकृति नहीं है। यूआई मेनू या कीबोर्ड कमांड के साथ ड्रैगिंग और ड्रॉप करने जैसे जीयूआई जेस्चर स्वीकार करता है, और डीएसएल इंस्टेंस के इन-मेमोरी प्रस्तुति का निर्माण करता है। यह _building_ है, _parsing_ नहीं। –
यदि कोई अवैध संकेत है, तो यह "पार्सिंग" है। स्ट्रिंग पार्सर्स स्मृति में भी डेटा संरचनाओं का निर्माण करते हैं, और मैं यह देखने में असफल रहता हूं कि चर्चा में कोई फर्क पड़ता है कि क्या पार्सिंग है। आप कह सकते हैं, "लेकिन मुझे पार्सर लिखना नहीं था"। ठीक है, मैं सहमत हो सकता हूं, लेकिन फिर उस और बाइसन के बीच भेद (जिसे आपको लिखना नहीं है) ज्यादा नहीं है; कहीं, किसी को (आप?) कहना है कि कानूनी संरचना क्या है, और कुछ यह जांचना है कि आप "इशारा करते हुए" ऐसी कानूनी संरचना का उत्पादन करते हैं। आपके पास * एक पार्सर है, और यह पार्सिंग है। –
"डीएसएल" के रूप में एपीआई के साथ मौलिक दोष यह है कि लैंगेज में, वाक्यविन्यास और अंतर्निहित अर्थशास्त्र के कानूनी आदेश हैं। जब आप एपीआई का उपयोग करते हैं, तो आप संकलित एपीआई कॉल का कोई भी अनुक्रम लिख सकते हैं, लेकिन मनमाने ढंग से सीक्यूएन्स कानूनी नहीं हैं। * लैंगेज * में मान यह निर्धारित करता है कि कौन से अनुक्रम कानूनी हैं, और एक अच्छा "पार्सर" (उदाहरण के लिए, एक जो पारदर्शी जांचता है और जांच करता है) बिना इसे चलाने के गैरकानूनी अनुक्रमों को अस्वीकार कर देगा। –
मैं सहमत हूं। बाहरी डीएसएल लिखने के लिए निश्चित रूप से कई कारण हैं। एक आसान उदाहरण यह है: यदि डीएसएल अविश्वसनीय उपयोगकर्ताओं के लिए प्रोग्राम लिखने का इरादा रखता है, तो आप उन्हें किसी भी पुराने प्रोग्रामिंग भाषा में लिखना नहीं चाहते हैं (जैसे कि आपकी डीएसएल को उस भाषा में एम्बेड किया जा सकता है)। दोनों दृष्टिकोणों के लिए पेशेवर और विपक्ष हैं। मेरा विचार है: यह एक अच्छी मेजबान भाषा में एक एम्बेडेड डीएसएल लिखने के लिए परिमाण के आदेश आसान है। इसलिए, इस हद तक कि ऐसा करना उचित है, ऐसा करें। लेकिन अगर एक एम्बेडेड डीएसएल अपर्याप्त है, तो आपको एक बाहरी डीएसएल लिखना होगा जो पर्याप्त है। – yfeldblum
यहां डीएसएल दस्तावेज का एक उदाहरण है http://www.robusthaven.com/blog/parsing-expression-grammar/npeg-dsl- दस्तावेज जिसे आप सी # में इनलाइन का उपयोग कर सकते हैं या भाषा वर्कबेंच http:/का उपयोग करके अपने पार्सर को निर्यात करने के लिए कर सकते हैं। /www.robusthaven.com/blog/parsing-expression-grammar/npeg-language-workbench –