जब संरचना-ऑब्जेक्ट्स (और कुछ अन्य प्रकार की ऑब्जेक्ट्स) अक्षर-फ़ाइल द्वारा संसाधित कोड में शाब्दिक, निरंतर ऑब्जेक्ट्स के रूप में दिखाई देती हैं, तो COMPILE-FILE को यह व्यवस्थित करने की आवश्यकता होती है कि परिणामस्वरूप बाइनरी फ़ाइल लोड हो जाती है, एक "समकक्ष" वस्तु बनाई गई है। "समकक्ष" की कई संभावित परिभाषाएं हैं: कभी-कभी, यह महत्वपूर्ण है कि भारित वस्तु के घटक अन्य वस्तुओं के साथ संरचना संरचना साझा करते हैं, कभी-कभी यह महत्वपूर्ण है कि प्रारंभिक तरीके एक निश्चित तरीके से होता है, और कभी-कभी इनमें से कोई भी चीज़ महत्वपूर्ण नहीं होती है। स्थिर ऑब्जेक्ट को फिर से बनाने के तरीके को निर्धारित करने के लिए, COMPILE-FILE जेनेरिक फ़ंक्शन मेक-लोड-फॉर्म को कॉल करता है; इस व्यवहार को किसी भी सीएल संदर्भ या ट्यूटोरियल में वर्णित किया जाना चाहिए। (एक संदर्भ या ट्यूटोरियल को यह भी ध्यान रखना चाहिए कि कार्यान्वयन डिफ़ॉल्ट मेक-लोड-फॉर्म विधियों को परिभाषित नहीं कर सकता है जो संरचना-वर्ग या मानक-वर्ग के सभी उदाहरणों पर लागू होंगे, और यह भी ध्यान रखना चाहिए कि मेक-लोड-फॉर्म-सेविंग
(defmethod make-load-form ((p point) &optional env)
(declare (ignore env))
(make-load-form-saving-slots p))
ध्यान दें कि विधि संकलन समय पर परिभाषित किया जाना है, इसलिए: -SLOTS वस्तुओं जिसका प्रारंभ के लिए मेकअप लोड-फार्म तरीकों में उपयोग करने के लिए की जरूरत नहीं है एक सुविधाजनक समारोह जटिल है, जैसे है कि COMPILE-FILE यह निर्धारित करने के लिए कॉल कर सकता है कि निरंतर POINT ऑब्जेक्ट को कैसे सहेजना है।
इनमें से कोई भी सीसीएल-विशिष्ट नहीं है। यह प्रश्न क्या हो सकता है कि कौन सी चीजें स्थिर हैं, शाब्दिक वस्तुएं और कौन सी चीजें नहीं हैं।
की तरह कोड में:
(defconstant a-point (make-point :x 0 :y 0 :z 200))
(defun return-a-point() a-point)
संकलक की अनुमति (लेकिन आवश्यक नहीं) समारोह रिटर्न-ए-सूत्री में इसे करने के लिए संदर्भ के लिए A-बिंदु के मूल्य से प्रतिस्थापित करने का। (यदि संकलक ऐसा करता है, तो का अर्थ यह होगा कि संकलित किए जा रहे कोड में एक शाब्दिक/निरंतर POINT ऑब्जेक्ट है, और COMPILE-FILE को यह निर्धारित करने के लिए मेक-लोड-फॉर्म को कॉल करने की आवश्यकता होगी कि ऑब्जेक्ट को कैसे सहेजा और लोड किया जाना चाहिए; यदि संकलक इस प्रतिस्थापन नहीं करता है, तो इस उदाहरण में मेक-लोड-फॉर्म को कॉल करने की आवश्यकता नहीं है।)
क्या इस तरह के प्रतिस्थापन का कार्यान्वयन या कार्यान्वयन पर निर्भर नहीं है। यह भी स्पष्ट करता है कि डेफोनॉन्स्टेंट फॉर्म में मूल्य प्रपत्र का संकलन समय, लोड-टाइम, या दोनों पर मूल्यांकन किया गया है, और नोट्स कि देखभाल का उपयोग किया जाना चाहिए (उपयोगकर्ता द्वारा) यह सुनिश्चित करने के लिए कि अभिव्यक्ति हमेशा मूल्यांकन करे वही मूल्य
सीसीएल आम तौर पर संकलन समय पर DEFCONSTANT मान फ़ॉर्म का मूल्यांकन करने का प्रयास करता है, और संदर्भित स्थिरांक के मूल्यों को उनके संदर्भों के प्रतिस्थापन के बारे में काफी आक्रामक है; कुछ मामलों में, इसका मतलब है कि स्थिरांक के मूल्यों के वर्गों पर मेक-लोड-फॉर्म विधियों को परिभाषित किया जाना चाहिए।अन्य कार्यान्वयन कुछ प्रकार की वस्तुओं के लिए इस प्रतिस्थापन को कम करने के लिए कम तैयार हो सकते हैं। दोनों रणनीतियों सही हैं, और पोर्टेबल कोड यह नहीं मान सकता कि कौन सी रणनीतियों का पालन किया जा रहा है (हालांकि बहुत स्पष्ट रूप से पोर्टेबल कोड निश्चित रूप से ऐसी धारणाएं करता है।)
DEFCONSTANT द्वारा परिभाषित चीजों के विभिन्न उपचार इस तरह के सबसे अधिक संभावित कारण की तरह दिखते हैं चीज (अप्रत्याशित कॉल करने के लिए तैयार-फार्म जो किसी को भी परिभाषित करने के लिए परेशान नहीं है)। बस (सीसीएल करता है) लगातार प्रतिस्थापन करने के लिए एक कार्यान्वयन ऐसा करने के लिए चाहता है कि अनुमति देने के लिए
(defconstant a-point (make-point :x 0 :y 0 :z 200))
(defun return-a-point() (load-time-value (symbol-value 'a-point)))
यह एक समान प्रभाव होगा: कोई एक करके एक तरह से इन मुद्दों कि पोर्टेबल होना चाहिए में से कुछ से बच सकते हैं , लेकिन लोड-टाइम-VALUE का उपयोग यह सुनिश्चित करेगा कि निरंतर मूल्य केवल लोड समय पर मूल्यांकन किया जाता है (और वह मेक-लोड-फॉर्म शामिल नहीं होगा।)
मुझे लगता है कि आपका मतलब है कि ' अपने 'DEFCONSTANT' फ़ॉर्म में वापसी-ए-पॉइंट'? –