क्या कोई संकलक हैं जो अपने आप ही वाक्यविन्यास त्रुटियों को ठीक करने का प्रयास करते हैं? [बन्द है]

Question

मैंने कुछ समय पहले सुना था कि एक संकलक हुआ करता था जो संदर्भ का विश्लेषण करके और जो इरादा था उसका संदर्भ देकर वाक्यविन्यास त्रुटियों को ठीक करने का प्रयास करता था।

क्या ऐसा कंपाइलर वास्तव में मौजूद है? जाहिर है इसका बहुत कम व्यावहारिक मूल्य है, लेकिन इसके साथ खेलना और सीखना बहुत दिलचस्प होगा।

Comments

क्या IntelliSense इस श्रेणी में आता है? कई संकलक में अपेक्षित [अर्धविराम] के समान त्रुटियां हैं।

— रॉबर्ट हार्वे

@ रॉबर्ट: नहीं, लेकिन यह एक अच्छी बात है।

— नाथन उस्मान

मेरे एक मित्र ने C प्रीप्रोसेसर पर काफी हैकिंग की, उदाहरण के लिए 'inlcude -> शामिल', और कुछ लोग यह पता लगाने की कोशिश कर रहे थे कि खुली हालत कहाँ बंद होनी चाहिए थी। यह उनके गुरु की थीसिस थी, जिसे उन्होंने कुछ आसान के लिए जल्दी छोड़ दिया। फिर भी, काफी दिलचस्प सवाल!

— टिम पोस्ट

AC # कंपाइलर बहुत उपयोगी त्रुटि संदेशों के साथ विफल हो जाता है। हर त्रुटि कोड के लिए ऑनलाइन उपलब्ध अच्छे प्रलेखन के साथ संयुक्त काम करता है बल्कि अच्छी तरह से काम करता है। यह ऑटो-सही सिंटैक्स के लिए एक बुरा विचार है, हालांकि HTML दुभाषिए (जैसे ब्राउज़र) अक्सर इसे वैसे भी करते हैं।

— अय्यूब

आप जिस कंपाइलर का उल्लेख कर रहे हैं, वह मूल PL / I था। यह मान लिया कि प्रोग्रामर ने जो कुछ भी लिखा है उसका कुछ मतलब होना चाहिए, और यह अनुमान लगाने की कोशिश की कि क्या हो सकता है। मेरे अनुभव में, यह वास्तव में बहुत बुरी तरह से अनुमान लगाया गया था!

— david.pfx

Answer 1

कुछ अर्थों में, संकलन का कार्य यह बताता है कि कुछ सिंटैक्स क्या करना है, और इसलिए सिंटैक्स त्रुटि तब होती है जब कंपाइलर इसका पता लगाने में सक्षम नहीं होता है। आप संकलक के साथ संकलक को और अधिक लचीला बनाने और अधिक लचीले होने के लिए अधिक "अनुमान" जोड़ सकते हैं, लेकिन इसे नियमों के एक विशिष्ट सेट के द्वारा करना चाहिए। और फिर वे नियम भाषा का हिस्सा बन जाते हैं, और अब कोई त्रुटि नहीं है।

तो, नहीं, ऐसे संकलक नहीं हैं, वास्तव में, क्योंकि प्रश्न का कोई मतलब नहीं है। अनुमान लगाना कि सिंटैक्स की त्रुटियां कुछ नियमों के सेट के अनुसार क्या होती हैं, सिंटैक्स का एक हिस्सा बन जाती हैं।

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

Comments

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

— जॉन पूर्डी

स्रोत कोड आकार के लिए पर्ल बलिदान क्रिया।

— नाथन उस्मान

@ जॉर्ज एडिसन: यह या तो एक तनातनी या एक विरोधाभास है।

— जॉन प्यूरी

या एक गहरी अंतर्दृष्टि। :)

— लेनार्ट रेगेब्रुक

Answer 2

वाकई खतरनाक लगता है। यदि कोई कंपाइलर आपके इरादे को भांपने की कोशिश करता है, तो यह गलत है, कोड को ठीक करता है, और फिर आपको नहीं बताता (या आपको कुछ चेतावनी में बताता है कि आप सभी को पसंद करते हैं, अनदेखा करें), तो आप कोड को चलाने वाले हैं गंभीरता से कुछ नुकसान करते हैं।

इस तरह एक संकलक शायद कुछ ऐसा है जो बहुत जानबूझकर नहीं बनाया गया है।

Comments

मुझे पता है। इस तरह के एक संकलक के पास संकलन के लिए कोई उपयोग नहीं होगा, लेकिन अवधारणा काफी दिलचस्प है और सीखने की क्षमता है।

— नाथन उस्मान

लगभग सभी नवीनतम IDE सिंटैक्स के लिए सुझाव प्रदान करते हैं और यह वास्तव में सहायक है। और बाकी भाग के लिए नाग्गु से सहमत हैं

— जिगर जोशी

मैं ऐसे कंपाइलर का इस्तेमाल नहीं करूंगा। यह 'काला जादू' के शीर्षक के अंतर्गत आता है।

— माइकल के

हम्म आप इस पैमाने पर स्काला के प्रकार का अनुमान कहां लगाएंगे? इसे आज़माने के बाद, यह कहेंगे कि कोड को संक्षिप्त करने के लिए यह एक प्रमुख योगदान है। दूसरी ओर, इसने मुझे कभी-कभी पैर में गोली मारी (जैसे कि मुझे लगा कि मैं सूचियों के साथ काम कर रहा हूं लेकिन वास्तव में अभी भी सेट्स के साथ काम कर रहा था)।

— 16

हमारे पास ओएमपी में आटोस्कोप जैसा सामान है, इसलिए इसका थोड़ा सा उपयोग करने योग्य है। बेशक, जिस कोड पर मैं काम करता हूं, वह ऑटोस्कोपिंग बंद हो गया है क्योंकि हम इस पर भरोसा नहीं करते हैं। मैं एक संवादात्मक संकलक देख रहा था जो पूछ सकता है "क्या आपका मतलब XXX था?"। जहाँ तक मैं जाने के लिए तैयार हूँ। और यहां तक ​​कि शायद बहुत खतरनाक है।

— ओमेगा सेंटौरी

Answer 3

एक प्रोग्रामिंग भाषा के लिए आईडीई आमतौर पर इन दिनों पृष्ठभूमि में किसी तरह संकलक चल रहा है, ताकि यह सिंटैक्स रंग, इंटेलीजेंसी, त्रुटियों और इतने पर विश्लेषण सेवाएं प्रदान कर सके। जाहिर है ऐसे संकलक को गहराई से टूटे हुए कोड की समझ बनाने में सक्षम होने की आवश्यकता है; अधिकांश समय जब संपादन, कोड सही नहीं होता है। लेकिन हमें अभी भी इसका मतलब निकालना है।

हालाँकि, आमतौर पर त्रुटि सुधार सुविधा का उपयोग केवल संपादन के दौरान किया जाता है; यह "मेनलाइन" परिदृश्यों में वास्तविक संकलन के लिए अनुमति देने के लिए बहुत अधिक समझ में नहीं आता है।

दिलचस्प बात यह है कि हमने उस फीचर को JScript.NET कंपाइलर में बनाया था; मूल रूप से संकलक को एक मोड में रखना संभव है जहां हम संकलक को आगे बढ़ने की अनुमति देते हैं, भले ही एक त्रुटि का सामना करना पड़ा हो, अगर आईडीई इससे बरामद होता। आप इसमें Visual Basic कोड टाइप कर सकते हैं , उस पर JScript.NET कंपाइलर चला सकते हैं, और दूसरे छोर से काम करने वाले प्रोग्राम का उचित मौका है!

यह एक मनोरंजक डेमो है, लेकिन यह कई कारणों से "मेनलाइन" परिदृश्यों के लिए एक बहुत अच्छी सुविधा नहीं है। एक पूर्ण विवरण काफी लंबा होगा; संक्षिप्त व्याख्या यह है कि यह उन कार्यक्रमों के लिए बनाता है जो अप्रत्याशित रूप से और दुर्घटना से काम करते हैं , और यह एक ही कोड को कई संकलक, या एक ही संकलक के कई संस्करणों के माध्यम से चलाना कठिन बनाता है। सुविधा के बड़े खर्चों को छोटे लाभों द्वारा उचित नहीं ठहराया गया है।

पीटर टॉर, जो पीएम को दिन में वापस लेते हैं, 2003 से इस ब्लॉग पोस्टिंग में इसकी संक्षिप्त चर्चा करते हैं ।

हालांकि हम JScript .NET इंजन की स्क्रिप्ट होस्टिंग API के माध्यम से इस सुविधा को उजागर करते हैं, लेकिन मुझे कभी भी इसका उपयोग करने वाले किसी भी वास्तविक ग्राहक के बारे में पता नहीं है।

Comments

काश मेरे नियोक्ता के पास उस तरह के प्रयोग करने के संसाधन होते; हम रात में यूनिट टेस्ट भी नहीं चलाते हैं क्योंकि इसमें फिक्स करने के लिए बहुत सारे फीचर्स ऐड और बग होते हैं :(

— जॉब

यह उस तरह का उत्तर है जिसकी मैं उम्मीद कर रहा था ... जैसा कि मैंने पहले उल्लेख किया है - जाहिर है कि इस तरह की सुविधा का बहुत कम व्यावहारिक उपयोग होता है, लेकिन कुछ तकनीकों को सीखने का एक शानदार तरीका प्रदान करेगा जो अन्य चीजों पर लागू किया जा सकता है। (भाषा पार्सिंग, आदि)

— नाथन उस्मान

@Job: सामान्य ज्ञान यह है कि यदि आप नियमित रूप से इकाई परीक्षण नहीं चलाते हैं, तो आपको ठीक करने के लिए बहुत अधिक कीड़े होंगे ।

— एरिक लिपिपर्ट

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

— जॉब

Answer 4

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

यह कहना नहीं है कि यह एक बेहतर काम नहीं कर सकता है। यदि यह निम्नलिखित पंक्ति को आगे देखता है, तो यह प्रोग्रामर के इरादे के अनुसार बेहतर अनुमान लगाने में सक्षम हो सकता है, लेकिन दिन के अंत में, अगर कई वैध तरीके से वाक्यविन्यास जा सकता है , तो वास्तव में कोई विकल्प नहीं है प्रोग्रामर के लिए स्पष्ट किया जा रहा है।

Comments

मैं जावास्क्रिप्ट अर्ध-बृहदान्त्र सम्मिलन सुविधा से पूरी तरह से सहमत हूं - पूरी तरह से बेकार।

— नाथन उस्मान

Answer 5

यह मुझे लगता है कि यदि कोई कंपाइलर गलत सिंटैक्स ठीक कर सकता है, तो उस सिंटैक्स को भाषा में दर्ज़ किया जाना चाहिए।

सिंटैक्स त्रुटियों का कारण यह है क्योंकि एक पार्सर अमूर्त सिंटैक्स ट्री को प्रोग्राम से बाहर नहीं बना सकता है। यह तब होता है जब एक टोकन जगह से बाहर है। यह अनुमान लगाने के लिए कि टोकन कहां होना चाहिए, अगर इसे हटा दिया जाना चाहिए, या यदि त्रुटि को ठीक करने के लिए कुछ अन्य टोकन को जोड़ा जाना चाहिए, तो आपको किसी प्रकार के कंप्यूटर की आवश्यकता होगी जो प्रोग्रामर के इरादे का अनुमान लगा सके। एक मशीन कैसे अनुमान लगा सकती है कि:

int x = 5 6;

होने वाला था:

int x = 5 + 6;

यह बस के रूप में आसानी से निम्न में से कोई हो सकता है: 56, 5 - 6,5 & 6 । जानने के लिए कंपाइलर के लिए कोई रास्ता नहीं है।

वह तकनीक अभी तक मौजूद नहीं है।

Comments

ऐसी तकनीक मौजूद नहीं हो सकती। माइंड रीडिंग की अनुमति नहीं है; सभी निर्देशों को स्पष्ट रूप से कोड से आना चाहिए।

— अय्यूब

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

— नाथन उस्मान

Answer 6

जबकि काफी समान बात नहीं है, यह इस तरह का है कि HTML आपदा में क्यों बदल गया। ब्राउज़रों ने खराब मार्कअप को सहन किया और अगली बात जो आप जानते थे, ब्राउज़र ए उसी तरह से रेंडर नहीं कर सकता था जो ब्राउज़र बी ने किया था (हाँ इसके अन्य कारण भी हैं, लेकिन यह कुछ शीर्ष में से एक था, 10 साल पहले के कुछ ढीले-ढाले नियम सम्मेलन बन गए थे )।

जैसा कि एरिक लिपर्ट का कहना है, इनमें से बहुत सी चीजें आईडीई द्वारा संभाला जाता है, न कि कंपाइलर से। कि आप देखते हैं कि स्वचालित बिट्स आपके लिए क्या करने की कोशिश कर रहे हैं।

मुझे लगता है कि अब जो रणनीति प्रमुख है, वह कंपाइलर को ढीला करने के बजाय निरंतर भाषा शोधन है: यदि यह वास्तव में ऐसा कुछ है जो कंपाइलर अपने आप पता लगा सकता है, तो इसके चारों ओर एक अच्छी तरह से परिभाषित भाषा निर्माण शुरू करें।

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

जो तब मुझे सोच में पड़ जाता है: अधिकांश सी शैली की भाषाएँ पहले से ही कुछ हद तक ऐसा करती हैं। उन चीजों के लिए जिन्हें स्वचालित रूप से समझा जा सकता है, बस सिंटैक्स को परिष्कृत करें:

 if (true == x)
 {
    dothis();
 }
 else
 {
    dothat();
 }

इसे कम किया जा सकता है:

if (true == x)
    dothis();
else
    dothat();

अंत में, मुझे लगता है कि यह नीचे आता है: प्रवृत्ति यह है कि आप संकलक को "अधिक" या "शिथिल" नहीं बनाते हैं। यह ऐसी भाषा है जो होशियार या ढीली है।

इसके अलावा, बहुत अधिक "मदद" खतरनाक हो सकती है, जैसे कि क्लासिक "अगर" बग:

if (true == x)
    if (true == y)
       dothis();
else
    dothat();

Comments

यह ध्यान दिया जाना चाहिए कि एक्सएचटीएमएल उस गंदगी के लिए एक समाधान प्रदान करता है जो एचटीएमएल के खराब विनिर्देशों ने बनाया है।

— नाथन उस्मान

if (x && y) dothis(); else dothat();थोड़ा बेहतर लगेगा।

— जॉब

एक बिल्ली हर बार किसी की तुलना trueया उसके खिलाफ मर जाती है false।

— JensG

Answer 7

जब मैं FORTRAN और PL / I को 80 के दशक के उत्तरार्ध में और 90 के दशक की शुरुआत में DEC और IBM minicomputer और mainframe सिस्टम पर कोडिंग कर रहा था, तो मुझे लगता है कि कंपाइलर नियमित रूप से "blah blah error" जैसे संदेशों को लॉग आउट करेंगे, ब्ला ब्ला ब्ला और कंटिन्यू .. । "। इसके बाद, बैच प्रोसेसिंग और पंच कार्ड के दिनों में (मेरे समय से पहले भी) यह एक विरासत थी, जब आपके कोड को चलाने और परिणाम प्राप्त करने के लिए कोड जमा करने के बीच एक बड़ी प्रतीक्षा की संभावना थी। तो इससे प्रोग्रामर को दूसरी गलती का अनुमान लगाने और पहली गलती का सामना करने के बजाय गर्भपात करने की कोशिश करने के लिए बहुत कुछ समझ में आया। ध्यान रखें, मुझे याद नहीं है कि "सुधार" विशेष रूप से परिष्कृत है। जब मैंने अंतःक्रियात्मक यूनिक्स वर्कस्टेशन (सन, एसजीआई आदि) पर कदम रखा,

Comments

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

— जॉन आर। स्ट्रॉहम डिक

हां, मुझे याद है कि आईबीएम पीएल / मैं आशा करता हूं कि कंपाइलर कभी-कभी लापता बीगिन और END बयानों की आपूर्ति करेगा, ISTR यह भी लापता अर्धविराम प्रदान करेगा।

— TMN

Answer 8

संकलक का लक्ष्य निष्पादन योग्य वस्तुओं का उत्पादन करना है जो वांछित व्यवहार करते हैं। यदि कोई प्रोग्रामर कुछ लिखता है जो अमान्य है, भले ही कंपाइलर 90% संभावना के साथ अनुमान लगा सकता है कि क्या इरादा था, तो आमतौर पर प्रोग्रामर को इरादा स्पष्ट करने के लिए प्रोग्राम को ठीक करने की आवश्यकता होती है, जिससे कंपाइलर आगे बढ़ता है और एक निष्पादन योग्य उत्पादन करता है। जो बग को छिपाने का एक महत्वपूर्ण मौका होगा।

बेशक, भाषाओं को आम तौर पर डिज़ाइन किया जाना चाहिए ताकि कोड जो स्पष्ट रूप से इरादा व्यक्त करता है वह कानूनी होगा, और कोड जो स्पष्ट रूप से इरादा व्यक्त नहीं करता है उसे निषिद्ध किया जाना चाहिए, लेकिन इसका मतलब यह नहीं है कि वे हैं। निम्नलिखित कोड पर विचार करें [जावा या C #]

const double oneTenth = 0.1;
const float  oneTenthF = 0.1f;
...
float f1 = oneTenth;
double d1 = oneTenthF;

संकलक होने से असाइनमेंट के लिए एक निहित टाइपकास्ट करने में मदद f1मिलेगी, क्योंकि केवल एक तार्किक चीज है जिसे प्रोग्रामर f1शामिल करना चाहता है ( floatमूल्य 1/10 के करीब)। , अनुचित कार्यक्रमों को स्वीकार करने के compilers को प्रोत्साहित हालांकि बजाय, यह बेहतर हो के लिए होगा कल्पना कुछ संदर्भों में निहित डबल करने के लिए नाव रूपांतरण अनुमति देने के लिए। फ्लिप-साइड पर, d1प्रोग्रामर वास्तव में क्या इरादा कर सकता है या नहीं हो सकता है, लेकिन इसकी कोई भाषा नियम नहीं है।

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

Answer 9

सिंटैक्स त्रुटियां विशेष रूप से सही करने के लिए कठिन हैं। गुम अधिकार का मामला ले लो ): हम जानते हैं कि हम एक को सम्मिलित करके कोड की मरम्मत कर सकते हैं, लेकिन आमतौर पर कई जगह हैं जहां हम एक को सम्मिलित कर सकते हैं और एक वाक्यात्मक रूप से सही कार्यक्रम प्राप्त कर सकते हैं।

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

Answer 10

ऐसा कंपाइलर बस जिस भी भाषा का संकलन कर रहा है, उसका एक सुकून, गैर-मानक कार्यान्वयन होगा।

Answer 11

इसे कई बार आजमाया गया है, लेकिन अक्सर यह वांछित प्रभाव को प्राप्त नहीं करता है: HAL 9000 या GlaDOS।

Answer 12

C में, आप सरणियों को मान से पास नहीं कर सकते, फिर भी संकलक आपको लिखने की अनुमति देता है:

void foo(int array[10]);

जो तब चुपचाप फिर से लिखा गया है:

void foo(int* array);

कितना बेवकूफ है? मैं मूक पुनर्लेखन के बजाय यहां एक कठिन त्रुटि पसंद करूंगा, क्योंकि इस विशेष नियम ने कई प्रोग्रामर को यह विश्वास करने के लिए प्रेरित किया है कि सरणियां और संकेत मूल रूप से एक ही चीज हैं। वो नहीं हैं।