असाइनमेंट ऑपरेटर बाएं हाथ से क्यों काम करता है?

Question

मैंने अभी हाल ही में एक दोस्त को प्रोग्रामिंग सिखाना शुरू किया (हम पायथन का उपयोग कर रहे हैं), और जब हमने चर निर्माण और असाइनमेंट ऑपरेटर पर चर्चा शुरू की, तो उसने पूछा कि दाईं ओर का मूल्य बाईं ओर के नाम को क्यों सौंपा गया है, और इसके विपरीत नहीं ।

मैंने पहले इसके बारे में बहुत अधिक नहीं सोचा था, क्योंकि यह मुझे स्वाभाविक लगता था, लेकिन उसने कहा कि बाएं से दाएं उसे अधिक स्वाभाविक लगता था, क्योंकि हम में से अधिकांश ने प्राकृतिक भाषाएं पढ़ी थीं।

मैंने इसके बारे में सोचा, और निष्कर्ष निकाला कि यह कोड को पढ़ने में बहुत आसान बनाता है, क्योंकि जिन नामों को सौंपा गया है (जिन्हें प्रोग्रामर को पुन: उपयोग करने की आवश्यकता होगी) आसानी से दिखाई देते हैं, बाईं ओर संरेखित होते हैं।

aligned = 2
on = 'foo' + 'bar' + 'foobar'
the = 5.0 / 2
left = 2 + 5

विरोध के रूप में:

2 = aligned 
'foo' + 'bar' + 'foobar' = on
5.0 / 2 = the 
2 + 5 = right 

# What were the names again...?

अब मुझे आश्चर्य है कि क्या इस मानक के लिए अन्य कारण भी हैं। क्या इसके पीछे कोई इतिहास है? या क्या कोई तकनीकी कारण है कि यह एक अच्छा विकल्प है (मुझे संकलक के बारे में ज्यादा जानकारी नहीं है)? और क्या कोई प्रोग्रामिंग भाषाएं हैं जो दाईं ओर असाइन होती हैं?

Comments

R दाईं ओर स्थित ( value -> variable) को असाइन कर सकता है ।

— आप

शायद यह खराब चर नामों के कारण है? Num अंकगणित 2` और L मुर्गियाँ 2 फीट 5 + ’के बारे में कैसा है?

— जॉब

क्या आपके दोस्त का नाम है ... योदा?

— एड्रियन

अगर वह इस बारे में बताना शुरू कर देती है, तो मुझे आश्चर्य होता है कि जब वह C ++ & co देखती है तो वह क्या करेगी।

— ब्लैकबियर

बस एक ओर ध्यान दें: खान अकादमी के शुरुआती प्रोग्रामरों के लिए पायथन पर कुछ पाठ हैं: khanacademy.org/#computer-science और Google के पास अधिक उन्नत के लिए कुछ हैं: code.google.com/edu/languages/google-python

— लिंडन लोमड़ी

Answer 1

Ditto @paxdiablo। प्रारंभिक प्रोग्रामिंग भाषाएं गणितज्ञों द्वारा लिखी गईं - वास्तव में वे सभी थीं। गणित में, अपने स्वयं के सिद्धांत द्वारा - बाएं से दाएं पढ़ने - यह काम करने के तरीके में समझ में आता है।

x = 2y - 4

गणित में, आप यह कहेंगे: Let x 2y -4 के बराबर होगा।

इसके अलावा, बीजगणित में भी आप ऐसा करते हैं। जब आप किसी चर के लिए समीकरण हल करते हैं, तो आप उस चर को अलग कर देते हैं जिसे आप बाईं ओर हल कर रहे हैं। यानी y = mx + b;

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

Comments

@FarmBoy: गणित में, असाइनमेंट और समानता एक ही बात है, क्योंकि कंप्यूटर में जैसा है वैसा फॉर्मूला में कोई क्रम नहीं है। (एक बराबर बी और एक ही समय में बी बराबर होती है)

— पेत्रुजा

@ एफबी कुछ एकल असाइनमेंट कार्यात्मक भाषाओं जैसे कि एर्लैंग को छोड़कर। असाइनमेंट और एश्योरिंग समानता गणित में समान हैं

— पीयर स्ट्रिट्ज़िंगर

@Petruza नहीं, गणित में असाइनमेंट और समानता एक ही बात नहीं है। अगर मैं कहूं कि 'लेट x = 2y - 3' यह 'x = 2y - 3' से अलग है। मैं गणित करता हूं, आमतौर पर संदर्भ उन्हें अलग करता है। चूँकि यह टिप्पणी मुझे विवादित कर रही थी, इसलिए मैं सार्वभौमिक रूप से प्रशंसित था, मैं उल्लेख करता हूँ कि मेरे पास पीएच.डी. गणित में, मुझे इस पर पूरा यकीन है।

— एरिक विल्सन

मैं पीएचडी के पास कहीं भी गणित नहीं जानता, जो मैं बताता हूं कि जैसा कि कोई अनुक्रमिकता नहीं है, प्रोग्रामिंग के विपरीत, एक असाइनमेंट या एक समानता दोनों में गणित में निष्पादन का कोई आदेश नहीं है, जिसमें असाइनमेंट के दोनों पक्ष हो सकते हैं कुछ समय में अलग है, और वे समय में किसी अन्य बिंदु पर बराबर हो जाते हैं। लेकिन गणित में, असाइनमेंट में जैसे let a be...कि कोई समय नहीं है, असाइनमेंट के दोनों पक्ष समान हैं, इसलिए असाइनमेंट वास्तव में एक समानता है, कोई आश्चर्य नहीं कि दोनों एक ही संकेत का उपयोग क्यों करते हैं:=

— पेट्रूजा

@Petruzza - लेकिन वहाँ है श्रृंखलामयता। गणितीय दस्तावेज़ शुरू से अंत तक लिखे जाते हैं, किसी भी अन्य दस्तावेज़ के समान। यदि मैं x = 1अध्याय एक में जोर देता हूं , लेकिन x = 2अध्याय दो में जोर देता हूं , तो यह कुछ भयानक विरोधाभास नहीं है - प्रत्येक जोर केवल एक निश्चित संदर्भ में लागू होता है। अनिवार्य प्रोग्रामिंग में अंतर आंशिक रूप से एक बाधा को हटाने (हमें संदर्भ के परिवर्तन की आवश्यकता नहीं है), और आंशिक रूप से कार्यान्वयन और उपयोगिता के बारे में है।

— स्टीव 314

Answer 2

BASICप्रारंभिक कंप्यूटर भाषाओं में से एक का "उचित" रूप था:

10 LET AREA = HEIGHT * WIDTH

जो एक चर को निर्दिष्ट करने की गणितीय मानसिकता से मेल खाता है, जैसे "Let H वस्तु की ऊँचाई हो"।

COBOLउसके COMPUTEकथन के साथ भी ऐसा ही था । चीजों को करने के कई तरीकों के साथ, यह केवल एक मनमाना निर्णय हो सकता है जिसे कई भाषाओं के माध्यम से आगे बढ़ाया गया था।

Comments

मुझे लगता है कि यह रूप तब अधिक स्वाभाविक है जब प्रोग्राम लाइनों को "कथन" के रूप में "ऑपरेशन" के विपरीत माना जाता है। जैसे, में, I declare that X must equal THISअधिक रैखिक के बजायEvaluate THIS and store it in X

— voithos

रुको, BASIC एक 'प्रारंभिक' कंप्यूटर भाषा थी?

— एलेक्स Feinman

@ एलेक्स ने माना कि यह 1960 के दशक से है, मैं कहूंगा कि यह बहुत जल्दी है।

— बेन रिचर्ड्स

दूसरी ओर, COBOL में आप लिख सकते हैं MULTIPLY HEIGHT BY WIDTH GIVING AREA, इसलिए परिणाम प्राप्त करने वाला चर कथन के दाईं ओर है।

— user281377

Answer 3

दरअसल, एक प्रोग्रामिंग भाषा है जो दाईं ओर असाइन होती है: TI-BASIC ! सिर्फ इतना ही नहीं, यह असाइनमेंट ऑपरेटर के रूप में भी '=' का उपयोग नहीं करता है, बल्कि "STO" ऑपरेटर के रूप में जाना जाने वाले तीर का उपयोग करता है।

उदाहरण:

5→A
(A + 3)→B
(A - B)→C

उपरोक्त उदाहरण में, तीन चर घोषित किए जा रहे हैं और मान दिए जा रहे हैं। A 5 होगा, B 8 होगा, और C -3 होगा। पहली घोषणा / असाइनमेंट को 'स्टोर 5 ए' के ​​रूप में पढ़ा जा सकता है।

जैसे कि TI-BASIC असाइनमेंट के लिए इस तरह की प्रणाली का उपयोग करता है, मैं इसे होने के लिए विशेषता देता हूं क्योंकि यह एक कैलकुलेटर के लिए एक प्रोग्रामिंग भाषा है। संख्या गणना के बाद TI कैलकुलेटर पर "STO" ऑपरेटर को सामान्य कैलकुलेटर ऑपरेशन में सबसे अधिक बार उपयोग किया जाता था। यदि यह वह संख्या थी जिसे उपयोगकर्ता याद रखना चाहता था, तो वे "STO" बटन को हिट करेंगे, और कैक्लुलेटर उन्हें एक नाम के लिए संकेत देगा (स्वचालित रूप से अल्फा लॉक को उलझा देगा ताकि कीस्ट्रोक्स संख्याओं के बजाय अक्षरों का उत्पादन करें):

Sin(7 + Cos(3))
                    -.26979276
Ans→{variable name}
                    -.26979276

और उपयोगकर्ता वैरिएबल को नाम दे सकता है जो उन्होंने चुना है। अल्फा लॉक को चालू करने के लिए, नाम टाइप करें, फिर "STO" दबाएं, और "Ans" कुंजी को मारना सामान्य ऑपरेशन के लिए बहुत अधिक बोझिल होगा। चूंकि सभी कैलकुलेटर फ़ंक्शन TI-BASIC में उपलब्ध हैं, इसलिए किसी अन्य असाइनमेंट ऑपरेटर को "STO" के रूप में नहीं जोड़ा गया था, अधिकांश अन्य भाषाओं की तुलना में पीछे की ओर एक ही कार्य किया जाता है।

(किस्सा: टीआई-बेसिक मैं सीखी गई पहली भाषाओं में से एक थी, इसलिए जब मैंने पहली बार कॉलेज में जावा सीख रहा था तो मुझे लगा कि जैसे LEFT को असाइन करना असामान्य और 'बैकवर्ड' था!)

Comments

+1 मैं पूरी तरह से भूल गया! TI बेसिक मेरी बहुत पहली भाषा थी, लेकिन मुझे यह विवरण याद नहीं है।

— बरजक

वास्तव में STO ऑपरेटर मशीन के काम करने के तरीके के करीब है, और कोई भी भाषा वास्तव में कैसे काम करती है। मान की गणना पहले की जाती है और फिर मेमोरी में संग्रहीत की जाती है।

— क्रेट्ज

Answer 4

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

अब, यह कैसे अधिक स्वाभाविक है (कम से कम एक अंग्रेजी बोलने वाले के लिए)? आइए देखें कि हम अंग्रेजी में कैसे लिखते / कहते हैं:

स्टीवन अब 10 साल का है (10 साल पुराने स्टीवन के विपरीत अब है)। मेरा वजन 190 पाउंड से अधिक है (जैसा कि मैं 190 पाउंड से अधिक वजन का विरोध करता हूं)।

कोड में:

steven = 10
i > 190

निम्नलिखित भी अधिक प्राकृतिक लगता है:

"अगर मैरी 18 यो है, तो उसके पास एक कैंडी हो सकती है"। "अगर मैं 21 यो से छोटा हूं, तो मैं अपने भाई को मेरे लिए टकीला से पूछूंगा"।

if (mary == 18) { ... }
if (i < 21) { ... }

से:

"अगर १ is यो मरियम है ..." "अगर २१ मेरी उम्र से अधिक है ..."

अब कोड:

if (18 == mary) { ... }
if (21 > i) { ... }

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

बेशक, किसी भी चीज़ की आदत हो सकती है। उदाहरण के लिए, संख्या 81 इस प्रकार है:

अस्सी एक (अंग्रेजी) अस्सी और एक (स्पेनिश) एक और अस्सी (जर्मन)।

अंत में, 4 हैं! = रूसी में "हरे सेब झूठ बोलने" के 24 वैध तरीके हैं - आदेश (लगभग) कोई फर्क नहीं पड़ता, सिवाय इसके कि 'पर' को 'तालिका' के साथ आना चाहिए। इसलिए, यदि आप एक मूल रूसी वक्ता हैं (उदाहरण के लिए), तो आप परवाह नहीं कर सकते हैं कि कोई लिखता है a = 10या 10 = aक्योंकि दोनों समान रूप से प्राकृतिक लगते हैं।

जबकि भाषाविज्ञान एक आकर्षक विषय है, मैंने कभी औपचारिक रूप से इसका अध्ययन नहीं किया और यह नहीं जानता कि कई भाषाएँ। उम्मीद है कि मैंने हालांकि पर्याप्त प्रति-उदाहरण प्रदान किए हैं।

Comments

... और फ्रांसीसी में, 81 को "चार बार इक्कीस" कहा जाता है ... :)

— मार्टिन सोज्का

@ मार्टिन, मेरा मानना ​​है कि दानिश बहुत समान है।

— बजे एक CVn

@ मॉर्टिन वास्तव में अजीब है, क्योंकि चार बार इक्कीस 84 है।

— पीटर ओल्सन

@ पेटर: आपने अपने कोष्ठक को गलत पाया है, यह है(four times twenty) one

— एकलकरण

@ जोब: अपने "अगर 18 यो मैरी है ..." पढ़ना, मुझे अनिवार्य रूप से याद दिलाते हुए कहा गया था कि "जब आप नौ सौ साल के हो जाएंगे, तो आप जितने अच्छे दिखेंगे, हम्म नहीं?" रिटर्न ऑफ द जेडी :-)

— जोर्की

Answer 5

इसकी शुरुआत 1950 के दशक में FORTRAN से हुई थी। जहां FORTRAN, FORmula TRANslation का संक्षिप्त नाम था - प्रश्न के सूत्र सरल बीजगणितीय समीकरण हैं, जो कन्वेंशन द्वारा हमेशा बाईं ओर असाइन किए जाते हैं।

दूसरी ओर समकालीन COBOL के पास इसका अर्थ अंग्रेजी जैसा था और इसे दाईं ओर (ज्यादातर!) सौंपा गया था।

MOVE 1 TO COUNTER.
ADD +1 TO LINE-CNT.
MULTIPLY QTY BY PRICE GIVING ITEM-PRICE.

Comments

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

— जोशुआ हेड्स

Answer 6

खैर, जैसा कि @ diceguyd30 ने बताया, दोनों सूचनाएं हैं।

• <Identifier> = <Value>का अर्थ है " आइडेंटिफ़ायर को मान दें "। या उस का विस्तार करने के लिए: मूल्य के लिए चर पहचानकर्ता को परिभाषित (या फिर से परिभाषित) करें ।
• <Value> -> <Identifier>"स्टोर वैल्यू टू आइडेंटिफ़ायर " का मतलब है । या इसका विस्तार करने के लिए: पहचानकर्ता द्वारा निर्दिष्ट स्थान में मूल्य डालें ।

बेशक, आम तौर पर पहचानकर्ता बोलना वास्तव में कोई एल-मूल्य हो सकता है।

पहला दृष्टिकोण चर की अमूर्त अवधारणा का सम्मान करता है, दूसरा दृष्टिकोण वास्तविक भंडारण के बारे में अधिक है।

ध्यान दें कि पहला दृष्टिकोण भाषाओं में भी सामान्य है, जिसमें असाइनमेंट नहीं हैं। यह भी ध्यान दें, कि चर परिभाषा और असाइनमेंट अपेक्षाकृत करीब <Type> <Identifier> = <Value>बनाम <Identifier> = <Value>।

Answer 7

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

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

Comments

मैं आपके स्पष्टीकरण को समझता हूं, लेकिन क्या कंपाइलर सिर्फ बयान के अंत तक आगे नहीं देख सकता था?

— 22

हो सकता है कि आज की भाषाओं में लेक्सर सरल हो, लेकिन कई प्रोग्रामिंग भाषाओं ने भी नाम विधियों का समर्थन किया है, अकेले विधि को ओवरलोड करते हैं, जब इस तरह का वाक्यविन्यास नया था?

— एक CVN

हाय @voithos। हाँ - संकलक आगे देख सकता है, लेकिन यह संभवतः संकलक लेखन के शुरुआती दिनों में जटिलता का एक अस्वीकार्य स्तर रहा होगा - जो अक्सर हाथ से कोडित कोडांतरक था! मुझे लगता है कि असाइन किए गए चर को बाईं ओर रखना एक व्यावहारिक विकल्प है: यह आदमी और मशीन दोनों के लिए पार्स करना आसान है।

— डेव जेवेल

मुझे लगता है कि यह एक अधिकार के लिए असाइनमेंट के लिए तुच्छ होगा। जब एक अभिव्यक्ति जैसे 3 + 4 == 6 + 7, दोनों पक्षों का मूल्यांकन ऑपरेटर से पहले किया जाता है, क्योंकि भाषा को पुनरावर्ती रूप से परिभाषित किया गया है। भाषा तत्व 'चर = अभिव्यक्ति', आसानी से 'अभिव्यक्ति = चर' में बदला जा सकता है। अस्पष्ट परिस्थितियों का कारण बनता है या नहीं, बाकी भाषा पर निर्भर करता है।

— क्रेट्ज

@Kratz - यह अब संकलक के लिए सच है, लेकिन बहुत पुरानी व्याख्या की गई भाषाओं के लिए एक मामूली मुद्दा हो सकता है जो टोकन स्रोत के साथ काम करता है। OTOH, जो चर-पर-बाएँ के बजाय चर-पर-दाएं का पक्ष ले सकता है।

— स्टीव 314

Answer 8

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

identifier = function();
function();

दो स्पष्ट रूप से दूसरे टोकन से विमुख हैं। दूसरी ओर,

function() = identifier;
function();

मज़ा नहीं। जब आप असाइनमेंट एक्ट्रेसेस को नेस्ट करना शुरू करते हैं तो यह खराब हो जाता है।

function(prev_identifier = expression) = identifier;
function(prev_identifier = expression);

बेशक, मशीनों के लिए आसान नहीं है, इंसानों के लिए भी आसान नहीं है। एक और आसान उदाहरण किसी भी पहचानकर्ता के प्रारंभिककरण की खोज करना होगा।

identifier1 = expressionOfAnArbitraryLength;
identifier2 = expressionOfAReallyReallyReallyArbitraryLength;
identifier3 = expression;
identifier4 = AlongLineExpressionWithAFunctionCallWithAssignment(
    identifier = expr);

आसान है, बस बाईं ओर देखो। दायीं ओर, दूसरी ओर

expressionOfAnArbitraryLength = identifier1;
expressionOfAReallyReallyReallyArbitraryLength = identifier2;
expression = identifier3;
AlongLineExpressionWithAFunctionCallWithAssignment(expr = identifier
    ) = identifier4;

खासकर जब आप grepकार्डों को पंच नहीं कर सकते हैं, तो आपको जो पहचानकर्ता चाहिए उसे ढूंढना बहुत कठिन है।

Comments

ठीक उसी बिंदु पर जो मैंने सोचा था, हाँ।

— वॉइथोस

Answer 9

Asssembly भाषाओं में गंतव्य बाएं बाएँ opcode के भाग के रूप में है। उच्च स्तरीय भाषाओं का झुकाव पूर्ववर्ती भाषाओं के सम्मेलनों का पालन करना था।

जब आप देखते हैं =(या :=पास्कलिश बोलियों के लिए), तो आप उन का उच्चारण कर सकते हैं is assigned the value, फिर बाएं से दाएं प्रकृति का अर्थ होगा (क्योंकि हम ज्यादातर भाषाओं में बाएं से दाएं पढ़ते हैं)। चूंकि प्रोग्रामिंग भाषा मुख्य रूप से उन लोगों द्वारा विकसित की गई थी जो बाएं-से-दाएं पढ़ते हैं, कन्वेंशन अटक गए।

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

Comments

हां, लेकिन मुझे संदेह है कि संपादकों के पाठ को भी सही तरीके से संरेखित किया जाएगा ...

— voithos

आप विधानसभा भाषाओं के बारे में सामान्यीकरण नहीं कर सकते। वे गंतव्य संचालक के रूप में भिन्न होते हैं।

— जल्दी से_अगले

@quickly_now: सही; वास्तव में, अधिकांश आदिम मशीन भाषाओं (आज के मानकों तक भी कोडर नहीं) में भी गंतव्य नहीं था, क्योंकि आमतौर पर सिर्फ एक या दो सामान्य-उद्देश्य संचायक होते थे। अधिकांश संक्रियाओं ने संचयकर्ता को गंतव्य के रूप में निहित किया, 'स्टोर' ऑपकोड को छोड़कर, जिसमें केवल स्मृति पता निर्दिष्ट था और स्रोत नहीं (जो संचयकर्ता था)। मुझे नहीं लगता कि ALGOL जैसी भाषाओं के लिए असाइनमेंट सिंटैक्स पर इसका कोई प्रभाव था।

— जेवियर

@ तंगुरेना - कुछ असेंबलर भाषाओं में बाईं ओर नियति है। ओपकोड का नहीं (यह असेंबल्ड ऑब्जेक्ट कोड है), लेकिन इंस्ट्रक्शन मेनेमोनिक के लिए दलीलों की सूची छोड़ दी गई है। हालांकि, दूसरों के पास सही जगह है। mov.b #255, d0उदाहरण के लिए, 68000 कोडांतरक में, आप यह लिखेंगे d0कि रजिस्टर कहां करना है। पुराने असेंबलरों में प्रति निर्देश केवल एक तर्क है। 6502 LDA #255(लोड एक्युमुलेटर) में, आप तर्क दे सकते हैं कि Aबाईं ओर है, लेकिन यह बाईं ओर STA wherever(स्टोर Accumulator) में भी है।

— स्टीव 314

और यहां तक ​​कि इंटेल 4004 (8086 परिवार के 4-बिट परम पूर्वज, 8008 और बीच में 8080 के साथ) को उच्च स्तरीय भाषाओं में असाइनमेंट के बाद विकसित किया गया था । यदि आप यह मान रहे हैं कि 8086 श्रृंखला 50 और उसके पहले के कोडांतरकों का प्रतिनिधित्व करती है, तो मुझे बहुत संदेह है कि यह सच है।

— स्टीव ३१

Answer 10

इसके लायक क्या है, COBOL में अधिकांश कथन बाएं से दाएं पढ़ा जाता है, इसलिए दो ऑपरेंड को पहले नाम दिया गया था, और अंतिम स्थान, जैसे multiply salary by rate giving tax:।

लेकिन मैं यह नहीं कहूंगा कि आपका छात्र COBOL पसंद कर सकता है, इस डर से कि मैं इतना (कम ही सही) झंडा लहराऊंगा, इस तरह की टिप्पणी नहीं की जा सकती है! :-)

Answer 11

उसने कहा कि बाएँ-से-दाएँ उसे अधिक स्वाभाविक लगता था, क्योंकि हममें से अधिकांश ने प्राकृतिक भाषाएं पढ़ी थीं।

मुझे लगता है कि यह एक गलती है। एक ओर, आप कह सकते हैं "10 से x असाइन करें" या "10 से x पर जाएं"। दूसरी ओर, आप "x को 10 पर सेट करें" या "x 10 हो जाता है" कह सकते हैं।

दूसरे शब्दों में, क्रिया की आपकी पसंद के आधार पर, निर्दिष्ट-चर वैरिएबल हो सकता है या नहीं हो सकता है, और बाईं ओर हो सकता है या नहीं। तो "क्या स्वाभाविक है" बस असाइनमेंट का प्रतिनिधित्व करने के लिए पूरी तरह से आपके आदतन विकल्प पर निर्भर करता है।

Answer 12

Pseudocode में असाइनमेंट ऑपरेटर बहुत दाईं ओर लिखा जाता है। उदाहरण के लिए

2*sqrt(x)/(3+y) -> z

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

A+2B → C

फोर्थ में चर दाईं ओर भी है

expression variable !

X86 में, इंटेल सिंटैक्स में बाईं ओर गंतव्य होता है, लेकिन जीएएस सिंटैक्स आदेश को उलट देता है, जिससे कई लोगों को कुछ भ्रम हो जाता है, विशेष रूप से घटाव या तुलना जैसे मापदंडों के आदेश के बारे में निर्देश पर। ये निर्देश 2 अलग-अलग बोलियों में समान हैं

mov rax, rbx    ; Intel syntax
movq %rbx, %rax ; GAS syntax

वे दोनों rbx में rax को मान देते हैं। कोई अन्य असेंबली लैंग्वेज मुझे नहीं पता कि GAS की तरह दाईं ओर डेस्टिनेशन लिखा है।

कुछ प्लेटफार्मों ने अभिव्यक्ति को बाईं ओर और चर को दाईं ओर रखा:

MOVE expression TO variable      COBOL
expression → variable            TI-BASIC, Casio BASIC
expression -> variable           BETA, R
put expression into variable     LiveCode

https://en.wikipedia.org/wiki/Assignment_%28computer_science%29#Notation

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

हालाँकि कुछ लोग "मूव x को y" कहना पसंद करते हैं और राइट पर वेरिएबल लिखते हैं।

Answer 13

मुझे लगता है कि यह सोचने का तार्किक तरीका है।
पहले एक बॉक्स (वेरिएबल) होना होता है, फिर आप उसके अंदर एक ऑब्जेक्ट (वैल्यू) डालते हैं।
आप ऑब्जेक्ट को हवा में न रखें और फिर उसके चारों ओर एक बॉक्स रखें।

Comments

हाँ आप कीजिए। अधिकांश भाषाओं में दाईं ओर का मूल्यांकन बाईं ओर से पहले किया जाता है।

— जेवियर

इसका "सड़क के दाईं ओर ड्राइविंग" प्रकार की चीज़ है। यह तर्कसंगत लगता है लेकिन केवल इसलिए कि इसका तरीका आपने हमेशा किया है। सभी श्रेष्ठ देश वामपंथ पर चलते हैं।

— जेम्स एंडरसन

@JamesAnderson श्रेष्ठ देश? : ओ

— नवाफ़ल

आप सही हैं, रोमन वर्णमाला के रूप में बाएं से दाएं लेखन प्रणाली के लिए यह केवल तर्कसंगत है, जो मुझे लगता है कि लगभग हर प्रोग्रामिंग भाषा द्वारा उपयोग किया जाता है, यदि सभी नहीं।

— पेत्रुजा