वन-पास कंपाइलर

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

यह कंपाइलर की लॉजिकल फंक्शन को रेफेर करता है, न कि मात्र एक बार सौर्स फ़ाइल की एक्चुअल रीडिंग को। उदाहरण के लिए, सौर्स फ़ाइल को एक बार टेम्पररी स्टोरेज में रीड किया जा सकता है परन्तु उस प्रतिलिपि को कई बार स्कैन किया जा सकता है। आईबीएम 1130 फोरट्रान कंपाइलर ने सौर्स को मेमोरी में स्टोर किया और कई पासों का उपयोग किया; इसके विपरीत, डिस्क स्टोरेज यूनिट की लैक वाले सिस्टम पर असेंबलर के लिए आवश्यक है कि कार्ड के सौर्स डेक को कार्ड रीडर/पंच के सामने दो बार प्रेजेंट किया जाए।

गुण

वन-पास कंपाइलर मल्टी-पास कंपाइलर की तुलना में स्माल और फ़ास्ट होते हैं।

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

कठिनाइयाँ

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

लोकल रेफेरेन्स

मान लीजिए कि सिंबल < को तुलना से कम के रूप में आइडेंटिफिकेशन हो जाता है, उदाहरण के लिए इससे अधिक के विपरीत। कैरेक्टर कोडिंग सीमाओं के कारण, ग्लिफ़ ≤ मानक एन्कोडिंग में उपलब्ध नहीं हो सकता है, इसलिए एक मिश्रित प्रतिनिधित्व की अनुमति दी जानी चाहिए, <=। भले ही यह रेफेरेन्स अगले सिंबल द्वारा निर्धारित किया जाता है, यह अज्ञात है जब < का एनकाउंटर होता है। इसी तरह, सिंबल = का मतलब हमेशा = नहीं होता है, क्योंकि जब यह किसी मिश्रित सिंबल का हिस्सा होता है। अन्य मिश्रित सिंबलों में .lt सम्मिलित हो सकता है। उस स्थिति के लिए जब स्पेशल करैक्टर < अनुपलब्ध हो। फिर भी एक और संभावना जहां ग्लिफ़ ¬ (नहीं) के लिए एक करैक्टर कोड अनुपलब्ध है, <> ¬= के लिए है या बराबर नहीं है - कुछ सिस्टम ~ या ! का उपयोग करते हैं। ¬ के लिए अभी भी और वेरिएशन है। एक मेथर्ड यह है कि < के पश्चात् स्कैन को आगे बढ़ाया जाए और = का एनकाउंटर करने पर, पीछे चला जाए। निःसंदेह इसका मतलब यह है कि टेक्स्ट के उस पार्ट्स पर दो बार गुजरना होगा, जिससे बचना होगा। उस मामले के लिए, सौर्स फ़ाइल किसी ऐसे उपकरण से आ सकती है जो कार्ड रीडर जैसे गो-बैक-एंड-रीरीड ऑपरेशन का समर्थन नहीं करता है। प्रारंभिक निर्णय लेने के बजाय, जिसे पश्चात् में पूर्ववत करना पड़ सकता है, लेक्सिकल एनालिस्ट क्वांटम सुपरपोजिशन की धारणा की तरह कई इंटरप्रिटेशनओं को बनाए रख सकता है, जो पश्चात् में निर्धारण सिंबल को देखने पर ही एक स्पेसिफिक आप्शन में बदल जाता है। स्पेशल रूप से, COBOL कंपाइलर दशमलव स्थिरांक में दिखाई देने वाले फुल स्टॉप और स्टेटमेंटों के अंत में दिखाई देने वाले फुल स्टॉप के मध्य अंतर करने के लिए एक पास समर्पित करते हैं। ऐसी योजना सिंगल -पास कंपाइलर के लिए उपलब्ध नहीं है।

इसी प्रकार वस्तुओं के नाम के साथ भी। कुछ रिप्रजेंटेशनएँ स्वयं को सिंगल -करैक्टर नामों तक ही सीमित रखती हैं, इसलिए सिंगल -करैक्टर नाम के रूप में करैक्टर x, टेक्स्ट जैसे नाम के भीतर करैक्टर x से काफी भिन्न होता है - अब रेफेरेन्स तत्काल एडजासेंट करैक्टर से आगे बढ़ जाता है। अनुक्रमिक सौर्स धारा की वस्तुओं को रिप्रजेंटेशन के टोकन में अलग करना लेक्सिकल एनालिस्ट का कार्य है। सिर्फ वर्ड ही नहीं, क्योंकि < और <= टोकन भी हैं। नाम सामान्यतः एक लेटर से प्रारम्भ होते हैं और लेटर और डिजिटों के साथ जारी रहते हैं, और शायद कुछ अतिरिक्त सिंबल जैसे _। संख्याओं को निर्दिष्ट करने के लिए अनुमत सिंटेक्स आश्चर्यजनक रूप से समष्टि है, उदाहरण के लिए +3.14159E+0 मान्य हो सकता है। टोकन के मध्य अंतरिक्ष करैक्टर की एक आर्बिट्रेरी संख्या की अनुमति देना सामान्य है, और फोरट्रान स्पष्ट टोकन के भीतर रिक्त स्थान की अनुमति देने (और अनदेखा करने) में भी असामान्य है ताकि GO TO और GOTO समान हों जैसे कि <= और < =। यघपि, कुछ प्रणालियों को कुछ टोकन को सीमित करने के लिए रिक्त स्थान की आवश्यकता हो सकती है, और अन्य, जैसे कि पायथन, प्रोग्राम ब्लॉक के दायरे को इंगित करने के लिए अग्रणी रिक्त स्थान का उपयोग करते हैं जो अन्यथा प्रारंभ ... अंत या समान मार्करों द्वारा इंगित किया जा सकता है।

एक्सप्रेशंस के भीतर रेफेरेन्स

जो रिप्रजेंटेशन अर्थमेटिक एक्सप्रेशंस की अनुमति देती हैं वे सामान्यतः प्रेसड़ेंस नियमों के साथ इन्फ़िक्स नोटेशन के सिंटेक्स को फॉलो करती हैं। इसका अर्थ यह है कि किसी एक्सप्रेशन के बेसिक्यांकन के लिए कोड का निर्माण सुचारू रूप से नहीं होता है क्योंकि एक्सप्रेशन के टोकन सौर्स टेक्स्ट से प्राप्त होते हैं। उदाहरण के लिए, एक्सप्रेशन x + y*(u - v) लोड x के एक्यूइवलेंट की ओर नहीं ले जाती है, क्योंकि x को y में नहीं ऐड किया जाता है। यदि अर्थमेटिक के लिए स्टैक स्कीम का उपयोग किया जाता है, तो कोड लोड एक्स से प्रारम्भ हो सकता है, परन्तु निम्नलिखित + टोकन से संबंधित कोड का फॉलो नहीं होता है। इसके अतिरिक्त, (u - v) के लिए कोड जनरेट किया जाता है, उसके पश्चात् y से गुणा किया जाता है और उसके पश्चात् ही x ऐड जाता है। अर्थमेटिक एक्सप्रेशंस का पार्सर अपने एनालिसिस के समय सौर्स के साथ आगे और पीछे नहीं चलता है, यह प्रेसड़ेंस नियमों द्वारा ड्रिवेन डिफर्ड ऑपरेशन के लोकल स्टैक को नियोजित करता है। अर्थमेटिक एक्सप्रेशंस को रिवर्स पोलिश नोटेशन या इसी तरह प्रेजेंट करने की आवश्यकता से इस डांस से बचा जा सकता है; उपरोक्त उदाहरण के लिए u v - y * x + जैसा कुछ और जिसे स्ट्रिक्टली से लेफ्ट से राईट स्कैन किया जाएगा।

एक ऑप्टिमाइजेशन कंपाइलर रेपिटेशन को आइडेंटिफिकेशन ने और हटाने या अन्य पोटेंशियल सुधार करने के लिए अर्थमेटिक एक्सप्रेशन के रूप का एनालिसिस कर सकता है। कंसीडर करना

a*sin(x) + b*sin(x)

कुछ रिप्रजेंटेशन, जैसे अल्गोल, अर्थमेटिक एक्सप्रेशन के भीतर असाइनमेंट की अनुमति देती हैं, इसलिए प्रोग्रामर कुछ इस तरह लिख सकता था

a*(t:=sin(x)) + b*t

परन्तु ऐसा करने के लिए रिक्वायर्ड एक्सेरशन के अतिरिक्त, रिजल्टी स्टेटमेंट का रूप मेस्सी होता है और अब इसे कोडित किए जा रहे ऐर्थ्मेटिक एक्सप्रेशन से सिम्प्लिसिटी से तुलना नहीं की जा सकेगी। फाल्सियाँ सिम्प्लिसिटी से हो जायेंगी। इसके अतिरिक्त, कंपाइलर एनटायर एक्सप्रेशन के रूप का प्रतिनिधित्व कर सकता है (सामान्यतः एक ट्री स्ट्रक्चर का उपयोग करके), उस स्ट्रक्चर का एनालिसिस और इम्प्रूव कर सकता है, और फिर बेहतर फॉर्म के लिए कोड उत्सर्जित कर सकता है। क्रमिक असाइनमेंट स्टेटमेंट के ब्लॉक में एक स्पष्ट स्पैन होगा। इसमें सौर्स टेक्स्ट के माध्यम से सेकंड पास सम्मिलित नहीं होता है।

मिडिल रेंज रेफेरेन्स

यद्यपि लेक्सिकल एनालिस्ट ने इनपुट स्ट्रीम को टोकन की एक स्ट्रीम में स्प्लिट कर दिया है (और किसी भी कमेन्ट्री को डिस्कार्ड कर दिया है), रिप्रजेंटेशन के सिंटेक्स के अनुसार इन टोकन की इंटरप्रिटेशन अभी भी रेफेरेन्स पर डिपेंड हो सकती है। फोरट्रान स्यूडो कोड में निम्नलिखित स्टेटमेंटों पर विचार करें:

if (expression) = etc.
if (expression) label1,label2,label3

if (expression) then

फर्स्ट, "if" नामक वन-डायमेंशनल ऐरे के एक एलिमेंट के लिए कुछ अर्थमेटिक एक्सप्रेशन (आदि) के वैल्यू का असाइनमेंट होता है। फोरट्रान इस अर्थ में असामान्य होता है कि इसमें कोई रिजर्व्ड वर्ड नहीं होता हैं, इसलिए एक टोकन "राईट" का अर्थ यह नहीं है कि कोई राईट-स्टेटमेंट प्रोग्रेस पर है। अन्य स्टेटमेंट वास्तव में इफ-स्टेटमेंट होता हैं - दूसरा एक अर्थमेटिक-इफ होता है जो एक्सप्रेशन के रिजल्ट के संकेत की एक्सामिन करता है और इसके नेगेटिव, जीरो, या पॉजिटिव होने के आधार पर 1, 2, या 3 लेबल पर जम्प करता है; तीसरा एक लॉजिकल-इफ होता है, और इसके लिए आवश्यक है कि इसकी एक्सप्रेशन का रिजल्ट बूलियन हो - इस प्रकार, लेक्सिकल एनालिस्ट से निकलने वाले टोकन की सही इंटरप्रिटेशन तब तक नहीं की जा सकती जब तक कि एक्सप्रेशन को स्कैन नहीं किया जाता है और क्लोजिंग ब्रैकेट के पश्चात् वहां दिखाई नहीं देता है या तो एक एकुल्स साइन, एक डिजिट (लेबल 1 का टेक्स्ट होने के कारण: फोरट्रान लेबल के रूप में मात्र इंटेगेर्स का उपयोग करता है, यघपि यदि लेटर्स को अनुमति दी जाती है तो स्कैन को कोमा फाइंड पर डिपेंड रहना होगा) या एक लेटर से प्रारम्भ होने वाली कोई चीज़ (वह तब होनी चाहिए), और तो अब, रेफेरेन्स सौर्स टेक्स्ट की एक आर्बिट्रेरी अमाउंट तक फैला हुआ होता है क्योंकि एक्सप्रेशन आर्बिट्रेरी होता है। यघपि, तीनों केस में कंपाइलर स्कैन के आगे बढ़ने पर एक्सप्रेशन के बेसिक्यांकन के लिए कोड जनरेट कर सकता है। इस प्रकार, लेक्सिकल एनालिसिस सदैव स्वीकार्य सिंटेक्स की वगरिएस के कारण आइडेंटिफिकेशन े गए टोकन के अर्थ को निर्धारित नहीं कर सकता है, और इसलिए यदि बैकट्रैकिंग से बचना है तो सिंटेक्स एनालिसिस को पॉसिबल स्टेट्स का एक सुपरपोजिशन बनाए रखना होगा।

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

इस समस्या को रिजर्व वर्ड्स के उपयोग के माध्यम से कम किया जा सकता है, उदाहरण के लिए "if", "then", और "else" एक इफ-स्टेटमेंट के पार्ट्स होते हैं और वेरिएबल्स के नाम नहीं हो सकते हैं, परन्तु आश्चर्यजनक रूप से बड़ी संख्या में उपयोगी वर्ड अनुपलब्ध हो सकते हैं। एक और मेथर्ड होता है "स्ट्रॉपिंग", जिसके तहत रिजर्व वर्ड्स को मार्क किया जाता है, जैसे कि उन्हें फुल स्टॉप, या एपोस्ट्रोफ जैसे स्पेशल करैक्टर के मध्य रखकर, जैसा कि अल्गोल के कुछ वर्जन में होता है। इसका अर्थ है कि 'if' और if अलग-अलग टोकन होते हैं, पश्चात् वाला एक सामान्य नाम होता है, परन्तु उन सभी एपोस्ट्रोफ की सप्लाई जल्द ही इर्कसम करने वाली हो जाती है। कई रिप्रजेंटेशनओं के लिए, स्पेसिंग सप्लाई पर्याप्त जानकारी प्रदान करती है, यघपि यह समष्टि हो सकती है। अधिकांशतःर यह मात्र एक स्थान (या टैब, आदि) नहीं होता है, जबकि एक लेटर या डिजिट के अतिरिक्त एक करैक्टर होता है जो पॉसिबल टोकन के टेक्स्ट को समाप्त करता है। उपरोक्त उदाहरण में, इफ-स्टेटमेंट की एक्सप्रेशन ब्रैकेट्स के भीतर होनी चाहिए जिससे (निश्चित रूप से "if" की आइडेंटिफिकेशन समाप्त हो जाए और इसी तरह,) तब की आइडेंटिफिकेशन को इनेबल्स कर सके; इसके अतिरिक्त, किसी कंपाउंड के अन्य पार्ट्स if-स्टेटमेंट को नई लाइनों पर प्रदर्शित होना चाहिए: else और End if (या Endif ) और else if । इसके विपरीत, अल्गोल और अन्य के साथ ब्रैकेट्स की आवश्यकता नहीं होती है और इफ-स्टेटमेंट के सभी पार्ट्स एक लाइन में हो सकते हैं। पास्कल के साथ, ए या बी तो आदि वैलिड है, परन्तु यदि ए और बी एक्सप्रेशन हैं, तो उन्हें ब्रैकेट्स में एनक्लोज्ड किया जाना चाहिए।

कंपाइलर द्वारा निर्मित सौर्स फ़ाइल लिस्ट को उसके द्वारा आइडेंटिफिकेशन किये जाने वाले रिजर्व वर्ड्स को अंडरलाइन या 'बोल्ड' या इटैलिक में प्रेजेंट करके रीड करना आसान बनाया जा सकता है, परन्तु आलोचना हुई है: अल्गोल एकमात्र ऐसी रिप्रजेंटेशन है जो इटैलिक और सामान्य फुल स्टॉप के मध्य अंतर करती है। वास्तव में ये कोई मज़ाक की बात नहीं है. फोरट्रान में, एक डू-स्टेटमेंट का प्रारम्भ जैसे DO 12 I = 1,15 होता है तो ये DO 12 I = 1.15 से अलग हो जाता है ( DO12Iएक वैरिएबल के लिए असाइनमेंटवैल्यू 1.15 होती है ; याद रखें कि स्पेस इर्रेलेवंट होता हैं) मात्र कोमा और फुल स्टॉप के मध्य के अंतर से, और एक प्रिंटेड लिस्ट के ग्लिफ़ अच्छी तरह से नहीं बने हो सकते हैं।

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

प्री-प्रोसेसर स्पैन

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

if condition then this source else other source fi

अधिकांशतः प्री-प्रोसेसर सोर्स स्टेटमेंट को सामान्य सोर्स स्टेटमेंट से अलग करने की कुछ अरेंजमेंट के साथ, जैसे कि pl/i, या # इत्यादि में % सिंबल से प्रारम्भ होने वाला स्टेटमेंट। एक और सिंपल आप्शन एक वेरिएशन है

define this = that

परन्तु सावधानी की जरूरत है, जैसे कि

define SumXY = (x + y)
sum:=3*SumXY;

चूँकि ब्रैकेट्स के बिना, रिजल्ट sum:=3*x + y; इसी तरह, रिप्लेसमेंट टेक्स्ट की बाउंड निर्धारित करने और रिजल्टी टेक्स्ट को कैसे स्कैन किया जाएगा, यह निर्धारित करने में सावधानी बरतने की आवश्यकता होती है। कंसीडर करना

#define three = 3;
#define point = .;
#define one = 1;
x:=three point one;

यहां डिफाइन स्टेटमेंट को सेमीकोलन द्वारा समाप्त किया जाता है, और सेमीकोलन स्वयं रिप्लेसमेंट का पार्ट्स नहीं होता है। इनवोकेशन x:=threepointone; नहीं हो सकता क्योंकि वह एक अलग नाम है, परन्तु three point one 3 . 1 होगा और सब्सिकेंट स्कैन उसे सिंगल टोकन के रूप में मानने में सक्षम हो भी सकता है और नहीं भी।

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

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

लॉन्ग-रेंज कॉन्टेक्स्ट

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

if condition then code true else code false fi

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

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

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

दुर्पार्ट्स्यपूर्ण निर्णय

यघपि ऊपर दिए गए विवरण में इस धारणा को नियोजित किया गया है कि कोड को पश्चात् में तय किए जाने के लिए छोड़े गए कुछ फ़ील्ड के साथ जनरेट किया जा सकता है, एक इम्प्लिसिट धारणा थी कि ऐसे कोड अनुक्रमों का आकार स्थिर था। यह मामला नहीं हो सकता है। कई कंप्यूटरों में अलग-अलग अमाउंट में स्टोरेज लेने वाले ऑपरेशन के लिए प्रावधान होता है, स्पेशल रूप से सापेक्ष एड्रेसिंग, जिसके तहत यदि डेस्टिनेशन -128 या +127 एड्रेसिंग चरणों के भीतर है, तो आठ-बिट एड्रेस फ़ील्ड का उपयोग किया जा सकता है, अन्यथा पहुंचने के लिए बहुत बड़े एड्रेस फ़ील्ड की आवश्यकता होती है। . इस प्रकार यदि कोड एक आशाजनक संक्षिप्त एड्रेस फ़ील्ड के साथ जनरेट किया गया था, तो पश्चात् में वापस जाना और लंबे फ़ील्ड का उपयोग करने के लिए कोड को समायोजित करना आवश्यक हो सकता है, जिसके रिजल्टस्वरूप परिवर्तन के पश्चात् पहले कोड रेफेर स्थानों को भी समायोजित करना होगा। इसी तरह, परिवर्तन के दौरान पीछे की ओर जाने वाले पश्चात् के रिफरेन्स को भी ठीक करना होगा, यहां तक ​​कि वे भी जो ज्ञात पतों पर थे। और साथ ही, फिक्सअप जानकारी को स्वयं ही सही ढंग से ठीक करना होगा। दूसरी ओर, लंबे पते का उपयोग उन सभी केस के लिए किया जा सकता है जब निकटता निश्चित नहीं है, परन्तु रिजल्टी कोड अब आदर्श नहीं होगा।

वन-पास अनुक्रमिक इनपुट, अनियमित अनुक्रम आउटपुट

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

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

उपयोग से पहले घोषणा

विभिन्न एक्सप्रेशंस के लिए कोड बनाते समय, कंपाइलर को ऑपरेंड की प्रकृति जानने की आवश्यकता होती है। उदाहरण के लिए, एक स्टेटमेंट जैसे A:=B; ए और बी इंटेगेर्स हैं या फ़्लोटिंग-पॉइंट वैरिएबल (और कौन सा आकार: सिंगल , डबल या चौगुनी परिशुद्धता) या समष्टि संख्या, ऐरे, स्ट्रिंग, प्रोग्रामर-परिभाषित प्रकार इत्यादि के आधार पर अलग-अलग कोड जनरेट कर सकते हैं। इस मामले में, एक सरल दृष्टिकोण स्टोरेज के वर्ड्स की उचित संख्या को स्थानांतरित करना होगा, परन्तु, स्ट्रिंग्स के लिए यह अनुपयुक्त हो सकता है क्योंकि प्राप्तकर्ता आपूर्तिकर्ता से छोटा हो सकता है और किसी भी मामले में, स्ट्रिंग का मात्र एक हिस्सा उपयोग किया जा सकता है - शायद इसमें एक हजार लेटर ों के लिए जगह है, परन्तु वर्तमान में इसमें दस सम्मिलित हैं। फिर अधिक समष्टि निर्माण भी हैं, जैसे कि COBOL और pl/i द्वारा प्रस्तावित A:=B by name; इस मामले में, ए और बी समुच्चय (या कंस्ट्रक्ट) हैं, उदाहरण के लिए ए में कुछ पार्ट्स हैं A.x, A.y और A.other जबकि बी के पार्ट्स हैं B.y, B.c और B.x, और उसी क्रम में. नाम सुविधा का अर्थ इसके ईक्यूवलेन्ट्स है A.y:=B.y; A.x:=B.x; परन्तु क्योंकि B.c ए, और में कोई ईक्यूवलेन्ट्स नहीं है A.other बी में कोई ईक्यूवलेन्ट्स नहीं है, वे सम्मिलित नहीं हैं।

यह सब इस आवश्यकता से नियंत्रित किया जा सकता है कि वस्तुओं को उपयोग से पहले डिक्लेअर किया जाए। कुछ रिप्रजेंटेशनओं में स्पष्ट डिक्लेरेशन की आवश्यकता नहीं होती है, पहली बार किसी नए नाम का एनकाउंटर करने पर एक इम्प्लिसिट घोषणा जनरेट होती है। क्या फोरट्रान कंपाइलर को पहले से अज्ञात नाम का एनकाउंटर करना पड़ता है जिसका फर्स्ट लेटर I, J,...,N में से एक है, तो चर एक इंटेगेर्स होगा, अन्यथा एक फ़्लोटिंग-पॉइंट वैरिएबल होगा। इस प्रकार एक नाम DO12I एक फ़्लोटिंग-पॉइंट वैरिएबल होगा। यह एक सुविधा है, परन्तु फाल्स टाइप किए गए नामों के साथ कुछ अनुभवों के पश्चात्, अधिकांश प्रोग्रामर इस बात से सहमत हैं कि किसी भी इम्प्लिसिट कंपाइलर आप्शन का उपयोग नहीं किया जाना चाहिए।

अन्य सिस्टम्स प्रकार तय करने के लिए पहली मुठभेड़ की प्रकृति का उपयोग करती हैं, जैसे कि एक स्ट्रिंग, या एक ऐरे, इत्यादि। इंटरप्रिटेशन की गई रिप्रजेंटेशनएँ स्पेशल रूप से लचीली हो सकती हैं, निर्णय रन टाइम पर लिया जा सकता है, कुछ इस प्रकार

यदि स्थिति तो pi:= 3.14 अन्यथा pi:=3.14 fi;
पाई प्रिंट करें;

क्या ऐसी रिप्रजेंटेशन के लिए कोई कंपाइलर होना चाहिए, उसे वेरिएबल पाई का प्रतिनिधित्व करने के लिए एक समष्टि यूनिट बनानी होगी, जिसमें यह संकेत होगा कि इसका वर्तमान प्रकार क्या है और ऐसे प्रकार का प्रतिनिधित्व करने के लिए संबंधित स्टोरेज होगा। यह निश्चित रूप से लचीला है, परन्तु गहन गणना के लिए सहायक नहीं हो सकता है जैसे कि A.x = b को हल करने में जहां A सौ क्रम का एक मैट्रिक्स है, और अचानक, इसका कोई भी एलिमेंट एक अलग प्रकार का हो सकता है।

प्रक्रियाएँ और कार्य

उपयोग से पहले घोषणा भी प्रक्रियाओं और कार्यों के लिए एक आसान आवश्यकता है, और यह प्रक्रियाओं के भीतर प्रक्रियाओं के घोंसले पर भी इन्वोक होती है। ALGOL, पास्कल, PL/I और कई अन्य की तरह, MATLAB और (1995 से) फोरट्रान एक फ़ंक्शन (या प्रक्रिया) को किसी अन्य फ़ंक्शन (या प्रक्रिया) की परिरिप्रजेंटेशन को सम्मिलित करने की अनुमति देते हैं, जो मात्र युक्त फ़ंक्शन के भीतर दिखाई देता है, परन्तु इन प्रणालियों के लिए आवश्यक है कि उन्हें युक्त प्रक्रिया के अंत के पश्चात् परिभाषित किया जाए।

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

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

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

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

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

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

पास्कल उदाहरण

ऐसे निर्माण का एक उदाहरण पास्कल (प्रोग्रामिंग रिप्रजेंटेशन) में आगे की घोषणा है। पास्कल के लिए आवश्यक है कि उपयोग से पहले सबरूटीन को डिक्लेअर या पूर्ण रूप से परिभाषित किया जाए। यह वन-पास कंपाइलर को उसके प्रकार की जाँच करने में मदद करता है: ऐसी प्रक्रिया को कॉल करना जिसे कहीं भी डिक्लेअर नहीं किया गया है, एक स्पष्ट एरर है। उपयोग से पहले घोषणा नियम के बावजूद, आगे की घोषणाएं आपसी रिकर्सन प्रक्रियाओं को एक-दूसरे को सीधे कॉल करने में मदद करती हैं:

function odd(n : integer) : boolean;
begin
    if n = 0 then
        odd := false
    else if n < 0 then
        odd := even(n + 1) { Compiler error: 'even' is not defined }
    else
        odd := even(n - 1)
end;

function even(n : integer) : boolean;
begin
    if n = 0 then
        even := true
    else if n < 0 then
        even := odd(n + 1)
    else
        even := odd(n - 1)
end;

फ़ंक्शन के लिए एक अग्रेषित घोषणा जोड़कर even समारोह से पहले odd, वन-पास कंपाइलर को बताया जाता है कि इसकी एक परिरिप्रजेंटेशन होगी even पश्चात् में फंक्शन में.

function even(n : integer) : boolean; forward;

function odd(n : integer) : boolean;
  { Et cetera }

जब फ़ंक्शन के मुख्य पार्ट्स की वास्तविक घोषणा की जाती है, तो या तो पैरामीटर हटा दिए जाते हैं या बेसिक फ़ॉरवर्ड घोषणा के बिल्कुल समान होने चाहिए, या एक एरर मार्क की जाएगी।

प्री-प्रोसेसर रिकर्सन

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

अग्रेषित घोषणाएँ हानिकारक मानी जाती हैं

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

यह भी देखें

• एल्गोल 68आर
• बड़े सिस्टम बरोज़#ALGOL
• नेलियाक
• एक्सपीएल