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

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

यह कंपाइलर की लॉजिकल फंक्शन को रेफेर करता है, न कि मात्र एक बार सौर्स फ़ाइल की एक्चुअल रीडिंग को। उदाहरण के लिए, सौर्स फ़ाइल को एक बार टेम्पररी स्टोरेज में रीड किया जा सकता है परन्तु उस प्रतिलिपि को कई बार स्कैन किया जा सकता है। आईबीएम 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 में कोई ईक्यूवलेन्ट्स नहीं होता है, और A.other का B में कोई ईक्यूवलेन्ट्स नहीं होता है, वे सम्मिलित नहीं होते हैं।

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

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

if condition then pi:="3.14" else pi:=3.14 fi;
print pi;

क्या ऐसी रिप्रजेंटेशन के लिए कोई कंपाइलर होना चाहिए, उसे वेरिएबल pi को रीप्रेजेंट करने के लिए एक काम्प्लेक्स यूनिट बनानी होगी, जिसमें यह इंडिकेशन होगा कि इसका वर्तमान प्रकार क्या है और ऐसे प्रकार को रीप्रेजेंट करने के लिए संबंधित स्टोरेज होगा। यह निश्चित रूप से फ्लेक्सिबल है, परन्तु इंटेंसिव कम्प्यूटेशन के लिए ऑक्सिलिअरी नहीं हो सकता है जैसे कि 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
• नेलियाक
• एक्सपीएल