स्व-होस्टिंग संकलक को नई भाषाओं के लिए पारित होने का एक संस्कार क्यों माना जाता है?


30

मैंने कई स्थानों पर सुना है कि लोग अपेक्षा करते हैं कि सम्मान के लिए भाषाएं उपयोग करें, या कम से कम, एक स्व-होस्टिंग संकलक हैं।

मैं उत्सुक हूं कि ऐसा क्यों है। लिखने के लिए एक संकलक बहुत महत्वपूर्ण सॉफ्टवेयर की तरह लगता है, और मुझे लगता है कि सभी भाषाएँ उन्हें बनाने के लिए अच्छी तरह से अनुकूल नहीं हैं। क्या यह बेहतर काम करने के प्रयास में खर्च करने के लिए अधिक अर्थ नहीं देगा जो बेहतर परिणाम देगा?


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

13
जब तक यह एक विशेष उद्देश्य की भाषा नहीं है, एक भाषा जो एक संकलक को लिखने के लिए अच्छी तरह से अनुकूल नहीं है, शायद मैं जो भी करना चाहता हूं उसके लिए अच्छी तरह से अनुकूल नहीं है।
कोड इंचेचोस

3
AFAIK, यह हमेशा फोरट्रान का सच नहीं है। कई फोरट्रान compilers (जैसे gfortranसे जीसीसी ...) कर रहे हैं नहीं फोरट्रान में कोडित।
बेसिल स्टारीनेवविच

जवाबों:


29

क्या यह बेहतर काम करने के प्रयास में खर्च करने के लिए अधिक अर्थ नहीं देगा जो बेहतर परिणाम देगा?

जैसे क्या?

संकलक के बारे में अच्छी बात यह है कि उनके पास कई निर्भरता नहीं हैं। यह उन्हें एक नई भाषा के लिए अच्छा उम्मीदवार बनाता है जिसकी संभावना बहुत बड़ी या विविध मानक लाइब्रेरी अभी तक नहीं है।

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

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


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

2
@arnaud और तथ्य यह है कि एक जावास्क्रिप्ट कम्पाइलर को एक जावास्क्रिप्ट पर्यावरण की आवश्यकता होगी, जिसे जावास्क्रिप्ट में नहीं लिखा जा सकता है क्योंकि जावास्क्रिप्ट को एक जावास्क्रिप्ट पर्यावरण की आवश्यकता होती है, <paradoxically> दोहराएं , क्योंकि एक जावास्क्रिप्ट वातावरण ऑपरेटिंग सिस्टम द्वारा प्रदान नहीं किया जाता है (और यदि यह जावास्क्रिप्ट में नहीं लिखा होगा)।
Qix 6

3
@Qix en.wikipedia.org/wiki/Bootstrapping_%28compilers%29 लेकिन मुख्य रूप से इसका उपयोग करने का कोई कारण नहीं है। यह एक खराब भाषा के रूप में व्यापक रूप से जाना जाता है, ब्राउज़र संकलन के लिए इसका उपयोग नहीं करने के साथ दूर हो जाते हैं क्योंकि वे स्थिति पर नियंत्रण रखते हैं :), जबकि हम में से बाकी के पास वेब पर कोई विकल्प नहीं है।
डेन

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

30

जिस भाषा को संकलित किया जा रहा है, उसमें संकलक होने का लक्ष्य अक्सर " अपने कुत्ते के भोजन को खाने " का हिस्सा होता है । यह दुनिया को दर्शाता है कि आप सहायक मॉड्यूल और उपकरणों की भाषा, संकलक और पारिस्थितिकी तंत्र को "गंभीर काम के लिए पर्याप्त" या "उत्पादन के लिए तैयार" मानते हैं।

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


1
पूर्णता के लिए: अपने कुत्ते के भोजन को खाना ; देखें कुत्ते को खिलाया (adj।) या डॉगफूडिंग (क्रिया)
Qix

17

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

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

इसका मतलब यह नहीं है कि यह केवल ध्यान देने योग्य है। ऐसी कार्यक्षमता है जो किसी कंपाइलर द्वारा प्रयोग नहीं की जाती है, जैसे डेटाबेस इंटीग्रेशन, ग्राफिकल इंटरफेस, नेटवर्किंग इत्यादि।


मुझे ऐसा लगता है कि एक (मूल) भाषा एक ऐसी भाषा है, जब यह खुद को संकलित कर सकती है और एक लिनक्स कर्नेल को इसे पोर्ट किया जा सकता है (क्योंकि यह अधिकांश आधुनिक-दिन के ओएस के कार्य करने के लिए आवश्यक / अधिकांश कार्यों को शामिल करता है)।
Qix

हालांकि एक कंपाइलर लिखने के लिए डिसेंट यूनिकोड सपोर्ट की जरूरत नहीं है।
पाओलो एबरमन

11

स्टीव येजे ने एक महान ब्लॉग पोस्ट लिखा है, जो कुछ हद तक अप्रत्यक्ष रूप से इसे संबोधित करता है।

बड़ा बिंदु # 1: कंपाइलर्स कंप्यूटर विज्ञान के हर पहलू को शामिल करते हैं। वे एक ऊपरी-स्तरीय पाठ्यक्रम हैं क्योंकि आपको कंप्यूटर विज्ञान के पाठ्यक्रम में सीखी गई अन्य सभी चीजों को जानने की जरूरत है। डेटा संरचनाएं, खोज और सॉर्टिंग, स्पर्शोन्मुख प्रदर्शन, ग्राफ़ रंग? यह सब वहाँ है।

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

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

बिग पॉइंट # 2: 30,000 फीट से, समस्याओं की एक आश्चर्यजनक संख्या संकलक की तरह दिखती है।

कंपाइलर प्रतीकों की एक धारा लेते हैं, कुछ डोमेन-विशिष्ट पूर्वनिर्धारित नियमों के अनुसार उनकी संरचना का पता लगाते हैं, और उन्हें दूसरे प्रतीक स्ट्रीम में बदल देते हैं। बहुत सामान्य लगता है, है ना? अच्छी तरह से हाँ।

चाहे आप विजुअल C ++ टीम में हों या नहीं, आप अक्सर खुद को कुछ ऐसा करने की जरूरत पाएंगे, जो किसी कंपाइलर के हिस्से की तरह दिखता हो। मैं इसे हर दिन शाब्दिक रूप से करता हूं।

अधिकांश अन्य व्यवसायों के विपरीत, प्रोग्रामर न केवल टूल का उपयोग करते हैं, बल्कि अपने स्वयं के टूल भी बनाते हैं। एक प्रोग्रामर जो (कौशल की कमी के कारण, या प्रयोग करने योग्य उपकरणों की कमी जिसके साथ अन्य उपकरण बनाने के लिए) लिख सकता है उपकरण हमेशा के लिए विकलांग हो जाएगा, उन उपकरणों तक सीमित होगा जो किसी और को प्रदान करता है।

यदि एक भाषा "प्रोग्राम बनाने के लिए अच्छी तरह से अनुकूल नहीं है" जो कि प्रतीकों की एक धारा ले सकती है, उनके लिए नियम लागू कर सकती है और इसे प्रतीकों की एक और धारा में बदल सकती है, जो कि एक बहुत ही सीमित भाषा की तरह लगती है, और ऐसा नहीं है जो उपयोगी हो। मेरे लिए।

(सौभाग्य से, मुझे नहीं लगता कि कई प्रोग्रामिंग भाषाएं हैं जो प्रतीकों को बदलने के लिए बीमार हैं। सी शायद आज उपयोग की जाने वाली सबसे खराब भाषा में से एक है, फिर भी सी कंपाइलर्स आमतौर पर स्व-होस्ट किए जाते हैं, ताकि कभी किसी को रोका न जाए।)

एक तीसरा कारण, मैं व्यक्तिगत अनुभव से समाप्त होऊंगा, जिसका उल्लेख येजे द्वारा नहीं किया गया है (क्योंकि वह "क्यों स्व-मेजबान" के बारे में नहीं लिख रहा था): यह बग को हिलाता है। जब आप एक कंपाइलर लिख रहे हैं, तो इसका मतलब है कि हर बार जब आप इसे बनाते हैं (न कि हर बार जब आप इसे चलाते हैं), तो आप इसे काम करने के लिए निर्भर करते हैं, और एक सभ्य आकार के कोडबेस (कंपाइलर खुद) के खिलाफ सही ढंग से काम करने के लिए।

इस महीने मैं एक अपेक्षाकृत नए और प्रसिद्ध गैर-स्व-होस्ट किए गए कंपाइलर का उपयोग कर रहा हूं (आप शायद अनुमान लगा सकते हैं कि कौन सा है), और मैं चीज को जब्त किए बिना 2 दिन नहीं जा सकता। मुझे आश्चर्य है कि वास्तव में डिजाइनरों को इसका कितना उपयोग करना पड़ा।


8

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

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

एक बार आपके पास यह कार्य करने के बाद, आप संकलक स्रोत को भाषा Y में भाषा X में लिखा गया था, और भाषा Y में लिखे संकलक का उपयोग करके भाषा X स्रोत संकलित कर सकते हैं। आउटपुट एक नया संकलक होगा जिसे नई भाषा X में लिखा गया है। भाषा X को संकलित करता है, अर्थात अब यह स्वयं-होस्टिंग है। हालाँकि यह पूर्ण नहीं है क्योंकि आपने केवल भाषा Y में भाषा का सबसेट लागू किया है।

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

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

60 साल या उससे पहले जब कंप्यूटर पहली बार दृश्य पर पहुंचे (और बाद में फिर से जब माइक्रोप्रोसेसर पहली बार आए), तो शुरुआती कंपाइलर को लागू करने के लिए कोई अन्य भाषा Y उपयुक्त नहीं थी। इसलिए पहले कंपाइलर्स को असेंबली कोड में लिखना होता था, और फिर जब कंपाइलर पर्याप्त होता था, तब असेंबली कोड को नई भाषा में लिखे वर्जन से बदल दिया जाता था। कोई असेम्बलर भी नहीं? पूरे प्रोसेसर ने एक और स्तर नीचे गिरा दिया, कोडांतरक शुरू में मशीन कोड में लिखा गया था ।


2

क्या एक प्रोग्रामिंग भाषा का उत्पादन करना संभव है जो एक कंपाइलर लिखने के लिए अच्छी तरह से डिज़ाइन नहीं किया गया है लेकिन किसी अन्य उद्देश्य के लिए अच्छी तरह से डिज़ाइन किया गया है?

एसक्यूएल जैसी भाषा को देखते हुए मुझे लगता है कि उत्तर हां है। लेकिन उस प्रकृति की भाषाएँ सामान्य उद्देश्य नहीं हैं।


1
चुनौती स्वीकार किए जाते हैं: SQL में C कंपाइलर लिखें।
किक्स

2

कौन कहता है? ... वैसे भी, यह सिर्फ एक राय है। कुछ सहमत हो सकते हैं, कुछ नहीं, यहाँ कोई सही या गलत नहीं है। कुछ भाषाओं में अपने आप लिखे कंपाइलर होते हैं, अन्य नहीं। जो कुछ।

फिर भी, मुझे लगता है कि यह एक अच्छा व्यायाम / प्रूफ-ऑफ-कॉन्सेप्ट है यदि कोई भाषा "आत्म-संकलन" करने में सक्षम है ... यह सिर्फ ... अच्छा है ... और यह मानता है कि भाषा कुछ जटिल चीजें करने के लिए अनुकूल है।

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


2

Clang C ++ में लिखा गया है। ऑब्जेक्टिव-सी में क्लैंग ऑब्जेक्टिव-सी कंपाइलर को फिर से लिखना बहुत कठिन नहीं होगा, लेकिन तब यह काफी बेकार हो जाएगा। C ++ कंपाइलर में किसी भी बदलाव को ऑब्जेक्टिव-सी और इसके विपरीत में फिर से बनाना होगा। तो क्यों?

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

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

यह साबित करने की तुलना में अधिक महत्वपूर्ण चीजें हैं कि आप कुछ प्रोग्रामिंग भाषा में एक कंपाइलर लिख सकते हैं।


1

यह दिखाता है कि भाषा जटिल स्ट्रिंग प्रसंस्करण को संसाधित करने और किसी अन्य भाषा में अनुवाद करने / स्वयं की व्याख्या करने में सक्षम है।

एक कंपाइलर (पहली बड़ी परियोजना) बनाने की प्रक्रिया में उस मुद्दे को सामने लाया जाएगा।

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.