मेरी कक्षा परियोजना के लिए, मुझे एक (सरल) योजना संकलक लागू करना है।योजना/लिस्प कार्यान्वयन में कचरा कलेक्टर का उपयोग नहीं कर रहा है
इस बिंदु पर मैं समझ रहा हूं कि मैं विभिन्न सुविधाओं को कैसे कार्यान्वित करता हूं।
क्यों सामान्य योजना कार्यान्वयन एक जटिल जीसी से परेशान है? यदि कोड वास्तव में कार्यात्मक है (कोई दुष्प्रभाव नहीं है) तो वर्तमान में निष्पादित फ़ंक्शन आवंटित स्मृति पर नहीं हो सकता है। कभी! (जब तक यह एक रिसाव न हो!)
इसलिए, क्यों न केवल C, यानी स्टैक आवंटन की तरह सबसे आवश्यक भाषाओं का पालन न करें। हर बार एक नया शब्दावली संदर्भ दर्ज किया जाता है (यानी (define (foo ..) या (letrec ...), स्टैक पर परिवर्तनीय संग्रहण आवंटित करें और फिर संदर्भ समाप्त हो जाने के बाद बस स्टैक पॉइंटर समायोजित करें।
चूंकि योजना में malloc() नहीं है और केवल पूर्वनिर्धारित प्रकारों के आवंटन की अनुमति देता है, एक साधारण कार्यान्वयन पूलिंग या जोन आवंटक का उपयोग कर सकता है, इसलिए "ढेर" कभी भी खंड नहीं होना चाहिए।
मुझे बंद करने के लिए लागू नहीं करना है, लेकिन मुझे लगता है कि बाध्य मानों को एक अलग स्टैक पर कॉपी करके एक ही नस में भी किया जा सकता है जिसका उपयोग बंद राज्यों को विशेष रूप से ट्रैक करने के लिए किया जाता है।
विचार?
लेकिन कोड वास्तव में कार्यात्मक नहीं है, जो ऑपरेशन 'सेट!', 'सेट-कार!' और 'सेट-सीडीआर!' जैसे राज्य को एक मानक योजना कार्यान्वयन का हिस्सा हैं। यदि आपका (सरल) स्कीम कंपाइलर उन परिचालनों की अनुमति नहीं देता है और आपको बंद करने की आवश्यकता नहीं है, तो एक आसान जीसी रणनीति संभव हो सकती है –
एक साधारण उदाहरण के बारे में सोचें: एक फ़ंक्शन एक सूची देता है, जो दूसरे में पारित होता है फ़ंक्शन जो मूल सूची के प्रत्येक दूसरे तत्व से बना एक नई सूची बनाता है। आपके क्षेत्र विश्लेषण का अनुमान कैसे लगाया जाएगा, मूल सूची तत्वों का कौन सा हिस्सा दूसरे फ़ंक्शन को समाप्त करने के लिए आवश्यक नहीं है? यहां तक कि सबसे बुनियादी लैम्ब्डा कैलकुस के लिए क्षेत्रों का अनुमान लगाने का बिल्कुल कोई तरीका नहीं है। –
एक 'सरल' (आपका शब्द, मेरा नहीं) लागू करने के मुद्दे योजना संकलक एक योजना रनटाइम के कचरा कलेक्टर को लागू करने के मुद्दों से बहुत दूर हैं। पहले 'सरल' कंपाइलर पर फ़ोकस करें। – GoZoner