पैकेज, सिस्टम, मॉड्यूल, लाइब्रेरी - क्या?

मेरी टिप्पणियों के अनुसार, कम से कम सप्ताह में एक बार क्लो लिस्ट में या किसी अन्य लिस्प सूची में , newbies भ्रमित हो जाते हैं कि पैकेज से संबंधित क्या है। वे एक पैकेज को "डाउनलोड करने" के बारे में बात करते हैं, एक पैकेज की आवश्यकता होती है, वे आश्चर्यचकित होते हैं कि सिस्टम लोड करने के बाद आपको पैकेज रोलर्स , आदि का उपयोग करने की आवश्यकता है। यह मुझे गुस्सा दिलाता है, मुझे यह भी लगता है कि यह एक कारण हो सकता है कि शुरुआती लोग यह सोचते हैं कि लिस्प में पुस्तकालयों का उपयोग करना वास्तव में की तुलना में अधिक जटिल है।

आमतौर पर मैं एक उपयोगी स्पष्टीकरण लिखने की कोशिश करना बंद कर देता हूं, और स्वाभाविक रूप से यह स्पष्टीकरण बहुत सरल है। मैंने यह पृष्ठ इसलिए बनाया ताकि अगली बार मैं इसे यहाँ भेज सकूँ, बजाय इसके कि बार-बार एक ही बात समझाऊँ।

सबसे पहले, आपके पास एक स्पष्ट सिर होना चाहिए। "पैकेज" शब्द भारी भरकम है। डेबियन या जेंटू जैसे लिनक्स वितरण में "पैकेज," "पैकेज" जावा, पर्ल, या पायथन प्रोग्रामिंग भाषाओं में हैं। यह संभावना है कि आप "पैकेज" क्या है या क्या होना चाहिए, इसके बारे में एक पक्षपाती राय के साथ लिस्प के पास आया था।

संकुल

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

सामान्य लिस्प में पैकेज बनाने, संशोधित करने, जांच करने और हटाने के लिए फ़ंक्शन और मैक्रो हैं। पैकेज (और प्रतीकों) का एक बहुत अच्छा परिचय पीटर सिबेल के उत्कृष्ट प्रैक्टिकल कॉमन लिस्प के अध्याय 21 में पाया जा सकता है। शब्द की परिभाषा एएनएसआई कॉमन लिस्प विनिर्देश के अध्याय 11 (ऑनलाइन संस्करण) में पाई जाती है।

सामान्य तौर पर, यह सभी पैकेजों के बारे में है। तकनीकी रूप से, आप पैकेज डाउनलोड नहीं कर रहे हैं। आप कोड ( LOAD का उपयोग करके) डाउनलोड कर सकते हैं, जो बदले में पैकेज बनाएगा, और यह एक महत्वपूर्ण अंतर है।

इसके अलावा, यदि आपका लिस्प शिकायत करता है कि उसे कोई पैकेज नहीं मिल रहा है, तो इसका मतलब है कि लिस्प के रूप में पैकेज छवि में नहीं है (यानी, FIND-PACKAGE रिटर्न NIL ), क्योंकि किसी ने भी इसे अभी तक नहीं बनाया है। इसका मतलब यह नहीं है कि लिस्प मशीन ने फाइल सिस्टम को खोजा और कुछ भी नहीं मिला। (इस विफलता का एक सामान्य कारण यह है कि घटनाएं गलत क्रम में होती हैं। नीचे देखें।)

प्रणाली

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

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

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

हालांकि एएसडीएफ काफी लोकप्रिय है, यह सर्वव्यापी नहीं है। यह कई Lisp सिस्टम जैसे SBCL, OpenMCL या AllegroCL के साथ प्रीलोडेड आता है, सबसे अधिक संभावना है कि यह अन्य Lisp सिस्टम में बूट होगा, लेकिन यह तथ्य इसे कॉमन लिस्प का हिस्सा नहीं बनाता है। यह एक स्पष्ट विनिर्देश के बिना और विभिन्न संस्करणों के साथ कोड का एक सेट है जो एक दूसरे के साथ असंगत हैं।
समझ जाओ ...

मॉड्यूल

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

उदाहरण के लिए, लिस्पवर्क्स में आप उपयोग कर सकते हैं

 (require "foreign-parser") 

एक पार्सर को लोड करने के लिए जो C में परिभाषाएं पढ़ सकता है , लेकिन यह OpenMCL पर काम नहीं करेगा। आप भी कॉल कर सकते हैं

 (require :asdf) 

OpenMCL पर ASDF डाउनलोड करने के लिए, लेकिन LispWorks पर नहीं।

कुछ वितरण REQUIRE को कॉन्फ़िगर करने के लिए हुक की पेशकश करते हैं, और सामान्य-लिस्प-नियंत्रक जैसे एक्सटेंशन होते हैं जो REQUIRE को ASDF से जोड़ते हैं, लेकिन सामान्य तौर पर, एक मॉड्यूल ऐसा कुछ है जो कार्यान्वयन-विशिष्ट है और सिस्टम (ASDF) के साथ भ्रमित नहीं होना चाहिए, और , खासकर पैकेज के साथ।

पुस्तकालयों

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

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

लेकिन मेरे लिए अभी भी कुछ भी काम नहीं करता है!

अक्सर लोग शिकायत करते हैं कि वे इस तरह के कोड वाली फाइल को संकलित नहीं कर सकते हैं:

 ;;        (require :cl-ppcre) (asdf:oos 'asdf:load-op :cl-ppcre) (defun my-simple-number-scanner (string) (cl-ppcre:scan "^[0-9]+$" string)) 

ऐसा क्यों? मैं इस फ़ाइल को क्यों डाउनलोड कर सकता हूं, लेकिन इसे संकलित नहीं कर सकता? और लोड करने के बाद मैं इसे क्यों संकलित कर सकता हूं? क्या यह अजीब नहीं है?

नहीं, अजीब नहीं है। कंपाइलर पहले फॉर्म को पढ़ता है (जो संकलित करने के लिए एक निर्देश है - यदि आवश्यक हो - और CL-PPCRE सिस्टम को लोड करें, लेकिन इसे निष्पादित न करें। अंत में, कंपाइलर को केवल कोड को संकलित करने में रुचि है। पहले फॉर्म को निष्पादित करने के बाद, वह दूसरे रूप में कार्य करता है, फ़ंक्शन की परिभाषा के लिए। यहां एक त्रुटि संदेश संभव है, क्योंकि इस फॉर्म को पढ़ने की कोशिश करने वाला एक लिस्प स्कैनर "सीएल-पीपीसीआरई: स्कैन" वर्णों के अनुक्रम का पता लगाएगा, जिसे सीएल-पीपीसीआरई पैकेज से एक बाहरी चरित्र का संकेत देना चाहिए, लेकिन सीएल-पीपीसीआरई पैकेज अभी तक मौजूद नहीं है। सिस्टम बूट CL-PPCRE, अन्य बातों के अलावा, CL-PPCRE पैकेज बनाया जा रहा है, लेकिन यह अभी तक नहीं हुआ है। CLHS के अध्याय 3 को पढ़ें।

आप दूसरे फॉर्म को पढ़ने से पहले CL-PPCRE लोड करने के लिए कंपाइलर को बताने के लिए EVAL-WHEN का उपयोग कर सकते हैं। हालाँकि, आपको अपना कोड व्यवस्थित करने का दूसरा तरीका खोजना चाहिए। पहला फ़ॉर्म केवल यह घोषणा कर रहा है कि आपका कोड CL-PPCRE सिस्टम पर निर्भर करता है। यह लिस्प कोड के समान फ़ाइल में नहीं होना चाहिए। अपने कार्यक्रम के लिए एक सिस्टम परिभाषा लिखें और वहां निर्भरताएं डालें।