वहाँ (defun hi() "Hi!") की तरह एक समारोह को परिभाषित करने और, या (setf a-number 5) को (hi) या (HI) या (Hi) का उपयोग करके इसे कहते और उस नंबर a-number, A-NUMBER, या A-Number का उपयोग कर उपयोग करने में सक्षम होने के लिए सक्षम होने के लिए एक फायदा है?आम लिस्प केस असंवेदनशील क्यों है?
यदि ऐसा कोई फायदा है, तो अधिकतर अन्य भाषाएं केस-संवेदी क्यों हैं?
किसी इंटरैक्टिव सत्र में कोड में केस संवेदनशील नामों का उपयोग करना और अधिक त्रुटि-प्रवण है।
आम लिस्प केस संवेदनशील है। यह सिर्फ डिफ़ॉल्ट लिस्प पाठक कार्यक्षमता डिफ़ॉल्ट रूप से प्रतीकों के सभी अनपेक्षित पात्रों को अपरकेस में परिवर्तित करता है। यह सामान्य लिस्प मानक में भी परिभाषित किया गया है। पूर्वनिर्धारित सामान्य लिस्प प्रतीक आंतरिक रूप से सभी अपरकेस भी हैं।
पुराने मशीनों पर अपरकेस का उपयोग करना आम था। याद रखें, कॉमन लिस्प का डिजाइन शुरुआती अस्सी (1 9 82) में शुरू हुआ था और एक लक्ष्य पहले मैकलिस्प के साथ संगतता थी और जब कई तरह के कंप्यूटर समर्थन करने के लिए थे (तथाकथित मिनी कंप्यूटर और मेनफ्रेम)। पुराने कंप्यूटरों पर उपयोग की जाने वाली अन्य प्रोग्रामिंग भाषाएं अपरकेस पहचानकर्ताओं का भी उपयोग करती हैं, जैसे कोबोल या पीएल/1।
यह भी ध्यान रखें कि लिस्प अक्सर इंटरैक्टिव रूप से उपयोग किया जाता था, ताकि एक इंटरैक्टिव प्रोग्रामिंग सत्र के दौरान सही नामों का मामला अधिक कठिन हो। यह थोड़ा आसान है जब लिस्प पाठक एक डिफ़ॉल्ट केस (यहां अपरकेस) का उपयोग करता है और इस मामले में सभी इनपुट को परिवर्तित करता है।
आम लिस्प अन्य पाठक मोड का समर्थन करता है और आप प्रतीकों से भी बच सकते हैं: |This is a Symbol with mixed CASE and spaces|।
आज बहुत सारे सॉफ़्टवेयर या तो लोअरकेस या लोअरकेस पसंदीदा के साथ केस संवेदनशील भी हैं। कुछ लिस्प विक्रेता सामान्य लिस्प के गैर-मानक संस्करण प्रदान करते हैं, जहां डिफ़ॉल्ट रूप से सभी प्रतीक लोअरकेस होते हैं और पाठक केस संरक्षित होता है। लेकिन यह मानक कॉमन लिस्प के साथ असंगत बनाता है, जहां उम्मीद है कि (symbol-name 'cl:defun) "DEFUN" है और "defun" नहीं है।
डिफ़ॉल्ट रूप से सीएल में पाठक मामला परिवर्तित हो रहा है, सभी बच निकले वर्ण अपरकेस में बदल जाते हैं। आप readtable-case के साथ इस व्यवहार को कस्टमाइज़ कर सकते हैं। ऐसा इसलिए है क्योंकि समान सम्मेलनों का पालन करने वाली अन्य भाषाओं के साथ इंटरफ़ेस करना आसान है।
(के रूप में अन्य लोगों ने बताया है, यह वास्तव में केस-संवेदी है, लेकिन मानक पाठक व्यवहार सब कुछ upcase है।)
फायदे के लिए के रूप में:
Hashtable और HashTable चाहते हैं विभिन्न चीजों का नामकरण करने के लिए?name और कोई अस्पष्टता नहीं होने पर name फ़ंक्शन हो सकता है। Name उस के शीर्ष पर, एक चर का नाम भी हो सकता है।अच्छे अंक! लेकिन अगर 'हैशटेबल' और 'हैशटेबल' को एक ही चीज़ को स्पष्ट रूप से इंगित करना चाहिए, तो 'नाम' को किसी फ़ंक्शन, क्लास या चर के लिए अनजाने में इंगित नहीं करना चाहिए? – wrongusername
@wrongusername: यह स्पष्ट है। जब आपके पास मूल्यांकन फॉर्म '(नाम foo)' होता है, तो यह स्पष्ट रूप से एक कार्य 'नाम' है; जब आपके पास '(defmethod बार ((baz name)) है ...) ', यह स्पष्ट रूप से एक वर्ग' नाम '(या बल्कि टाइप ...) है; जब आप एक मूल्यांकन फॉर्म '(quux name)' देखते हैं, तो यह स्पष्ट रूप से एक चर है। यह वही है जैसा आप बिना किसी भ्रम के अंग्रेजी में "नाम" का उपयोग कर सकते हैं और एक संज्ञा दोनों में कर सकते हैं। – Svante
यह अच्छी समझ में आता है। धन्यवाद Svante! – wrongusername
इंटरैक्टिव सत्रों के लिए, सामान्य लिस्प मानक को परिभाषित करते समय केस असुरक्षितता डिफ़ॉल्ट होती थी।
लेकिन, वास्तव में क्या होता है यह है कि आम लिस्प पाठक सभी प्रतीकों को इंटर्निंग और मूल्यांकन करने से पहले ऊपर उठाने के लिए परिवर्तित करता है। यह डिफ़ॉल्ट है, लेकिन यदि आप चाहें तो आप इसे हमेशा बदल सकते हैं।
*readtable* ऑब्जेक्ट्स में एक विशेषता है, readtable-case, यह नियंत्रित करता है कि पाठक कैसे प्रतीकों को पढ़ता है और मूल्यांकन करता है। आप setf readtable-case से :upcase (डिफ़ॉल्ट), :downcase, :preserve, :invert कर सकते हैं।
डिफ़ॉल्ट रूप से, readtable-case:upcase पर सेट है, जो सभी प्रतीकों को अपकेस में परिवर्तित करने का कारण बनता है।
आप केस संवेदनशीलता चाहते हैं, आप एक पहली नज़र में
(setf (readtable-case *readtable*) :invert)
=> :invert
करना चाहिए, तो आप सोच सकते हैं कि यह चयन करने के लिए बेहतर होगा: विकल्प की रक्षा, लेकिन यह कुछ मामूली मुद्दा है: सभी प्रतीकों , जैसा कि मानक द्वारा परिभाषित किया गया है, को ऊपर उठाया जाना चाहिए। तो, आप प्रतीकों आप केवल द्वारा परिभाषित करने के लिए मामले की संवेदनशीलता के लिए होता है, और यह राइट क्या करना है जाएगा:
* (DEFUN hi() "Hi!")
=> hi
* (SETF a-number 5)
=> a-number
* (HI)
=> ;error: the stored function is #'HI in the *readtable*, but by
; calling (HI) you try to acces a function named #'hi(downcase), which
; gives an error
* A-NUMBER
=> ;error: same for the variable
* (hi)
=> "Hi!"
* a-number
=> 5
:downcase विकल्प डिफ़ॉल्ट रूप के विपरीत है, downcase के लिए, आप किसी भी हालत संवेदनशीलता दे रही है सब कुछ परिवर्तित। ,
* (setf (readtable-case *readtable*) :invert)
=> :invert
* (defun Hi() "Hi!")
=> Hi
* (Hi)
=> "Hi!"
* (eq 'Hi 'hi)
=> nil
* (eq 'HI 'hi)
=> nil
* (eq 'Hi 'Hi)
=> t
[यह] (http://www.cliki.net/case%20 संवेदनशीलता) सबकुछ थोड़ा और स्पष्ट करता है। '(setf (readtable-case * readtable *): उलटा)' सभी अपरकेस अक्षरों को लोअरकेस और सभी ऊपरी केस को लोअरकेस में उलट देता है क्योंकि सभी मूल कार्य डिफ़ॉल्ट रूप से अपरकेस में लिखे जाते हैं। – William
हम्म:
लेकिन
:invertसाथ, प्रतीकों आप स्रोत कोड में लिखते हैं,defunकी तरह,setfhiसमारोह, upcase परिवर्तित हो, औरCamelCaseमें किसी भी प्रतीक संरक्षित है जैसे कि यह मूल रूप से है सीएल इंटरफ़ेस के साथ कौन सी भाषाएं हैं? – wrongusernameउस समय? शायद फोरट्रान। याद रखें कि आम लिस्प और उसके पूर्ववर्तियों को बहुत समय पहले एक आकाशगंगा में बहुत दूर डिजाइन किया गया था। –
यह विशेष रूप से फोरट्रान नहीं था, यह अक्सर हैडवेयर (टेलीलेट) अपरकेस था और ओएस अपरकेस का उपयोग कर रहा था। इस प्रकार प्रोग्रामिंग भाषाओं ने अपरकेस का भी उपयोग किया: पीएल/1, कोबोल, फोरट्रान, लिस्प, ... लाइन-एडिटिंग मोड में धीमी कनेक्शन के माध्यम से टर्मिनल पर केस संवेदनशील कमांड संपादित करने के लिए यह दर्दनाक था ... –