O42a प्रोग्रामिंग भाषा

मुझे प्रोग्रामिंग पसंद नहीं है। मुझे एक परिणाम की आवश्यकता है।

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

लेकिन मुख्य बात यह है कि यह काम करता है। और जितनी जल्दी बेहतर होगा।

सभी जो विचार को परिणाम से अलग करते हैं, प्रोग्रामिंग है, जिसका सार विचारों की प्रस्तुति, समस्या को हल करने का तर्क है, मशीन प्रसंस्करण के लिए सुलभ प्रतिनिधित्व में है।

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

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

ओ 42 ए का मुख्य विचार एक प्रोग्रामर के काम को स्वचालित करना है। और यह एक एकल के लिए भाषाई संस्थाओं के प्रकारों की मौलिक कमी से प्राप्त होता है जो सीधे उन सभी को बदल सकता है। ऐसी इकाई के कुशल मशीन प्रतिनिधित्व का कार्य पूरी तरह से संकलक के पास है।

विचार

मुझे तुरंत कहना चाहिए: ऐसी इकाई को स्विस चाकू की तरह कुछ नहीं होना चाहिए, इसकी सार्वभौमिकता में बेकार है। लेकिन यह ऐसी ईंटों से कुछ भी बनाने के लिए एक आदिम ईंट नहीं है (जैसे लिस्प में सूची)।

विभिन्न प्रोग्रामिंग प्रतिमानों में, कई संस्थाएं हैं जो एक दूसरे के साथ असंगत प्रतीत होती हैं। तो आप उनके सहजीवन को कैसे प्राप्त करते हैं?

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

मैं इस विचार को यथासंभव व्यापक रूप से लागू करना चाहता था। क्या यह पता नहीं चलेगा कि अलग-अलग प्रोग्रामिंग प्रतिमानों से अलग-अलग अवधारणाएं आम तौर पर जितनी दिखती हैं, उससे कहीं अधिक हैं? इस मामले में मुख्य बात कम हठधर्मिता है।

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

आप एमवीसी प्रतिमान से मॉडल के लिए सिंटैक्स को दृश्य और प्रोग्राम संस्थाओं में मैप कर सकते हैं। और आप इसे डीएसएल कह सकते हैं।

यहाँ वाक्य रचना के साथ मैं वर्णन शुरू करूँगा। मुझे लगता है कि इसकी कम से कम महत्वपूर्ण विशेषताएं सबसे बड़ी अस्वीकृति का कारण बनेंगी।

सिंटेक्स बेसिक्स

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

O42a में कोई कीवर्ड नहीं हैं। आपकी जरूरत की हर चीज के लिए, आइकन्स का इस्तेमाल किया जाता है। पहली नज़र में, यह एक भयानक निर्णय की तरह लग सकता है। हालांकि, यह ध्यान में रखा जाना चाहिए कि भाषा में केवल एक ही सार है, और इतने सारे वाक्यात्मक निर्माण नहीं हैं जिसमें यह भाग लेता है। इसलिए बहुत सारे बैज की आवश्यकता नहीं है।

नाम

ओ 42 ए में नाम केस-असंवेदनशील हैं और इसमें शब्दों, लैटिन संख्या और रिक्त स्थान से अलग हाइफ़न शामिल हैं:

Hello World Links 2- 3- 4 -90 

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

 Hello world links2-3-4 -90  

टिप्पणियाँ

ओ 42 ए पर टिप्पणियाँ भी असामान्य हैं। टिल्ड को डेलिमिटर के रूप में उपयोग किया जाता है। इसके अलावा, वे दोनों लोअरकेस और ब्लॉक टिप्पणियों के लिए उपयोग किए जाते हैं।

एक पंक्ति टिप्पणी दो या अधिक टिल्ड के साथ शुरू होती है:

 a + b ~~ The sum 

एक पंक्ति टिप्पणी पंक्ति के अंत में या दो या अधिक टिल्ड के साथ समाप्त होती है:

 a +~~~plus~~~ b 

एक ब्लॉक टिप्पणी तीन या अधिक टिल्डों की एक क्षैतिज रेखा के साथ शुरू और समाप्त होती है। व्हाट्सएप को छोड़कर कोई अन्य वर्ण लाइन के समान लाइन पर नहीं होना चाहिए:

 ~~~~~~~~~~~~~~~~~~~~~~~~~~ Copyright (C) 2012 This file is part of o42a. ~~~~~~~~~~~~~~~~~~~~~~~~~~ 

प्रलेखन उद्देश्यों के लिए, मार्कडाउन का उपयोग किया जाना चाहिए।

लाइन ब्रेक और अंडरस्कोर

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

 Sum = _left operand + _right operand 

एक अंडरस्कोर को पिछली पंक्ति के अंत में या अगली पंक्ति की शुरुआत में रखा जा सकता है।

इसके अलावा, एक अंडरस्कोर का उपयोग नामों को अलग करने के लिए किया जाना चाहिए, क्योंकि नामों में स्वयं स्थान हो सकते हैं:

 Print error _nl ~~     "\n" ~~      (stderr  C). 

अन्य

दशमलव संख्या:

 1 234 567 

भाषा में वास्तविक संख्या या हेक्साडेसिमल संकेतन के लिए कोई शाब्दिक नहीं हैं। हालाँकि, यह कोई समस्या नहीं है, क्योंकि वाक्यांश हैं (बाद में उन पर अधिक):

 float '3,141 592 653 59' 

स्ट्रिंग्स "चिपके" हैं जैसे कि सी:

 "abc" "def" ~~  ,  : "abcdef" 

बैकस्लैश का उपयोग करके परिरक्षण सामान्य है। यूनिकोड कोड पॉइंट हमेशा हेक्साडेसिमल में लिखे जाते हैं और एक विशेष तरीके से बच जाते हैं:

 "\t \42a\ \" \' \\ \r\n" 

मल्टी-लाइन टेक्स्ट के लिए समर्थन है। बहु-पंक्ति पाठ में काम नहीं करता है:

 """"""    """""" 

वस्तुएं

एक वस्तु ओ 42 ए का मुख्य सार है।

एक वस्तु दूसरी वस्तु से विरासत में मिली है। वस्तुओं को बनाने का यही एकमात्र तरीका है।

सभी वस्तुएं प्रत्यक्ष या अप्रत्यक्ष रूप से Void वस्तु से विरासत में मिली हैं - एकमात्र वस्तु जो किसी से विरासत में नहीं मिली है।

क्षेत्र और विरासत

किसी ऑब्जेक्ट में फ़ील्ड हो सकते हैं। एक फ़ील्ड एक नेस्टेड ऑब्जेक्ट है।

यहाँ एक उदाहरण क्षेत्र घोषणा है:

 Object := void ( Field := "Value" ~~ `Field` -    `Object`   `String`. ) 

डिफ़ॉल्ट रूप से, फ़ील्ड में एक सार्वजनिक गुंजाइश होती है। लेकिन आप उन्हें आंतरिक (निजी) और संरक्षित (संरक्षित) घोषित कर सकते हैं।

ओ 42 ए में कोई भी अभिव्यक्ति या तो एक मौजूदा वस्तु तक पहुंचती है या एक नया निर्माण करती है। कोई और भाव नहीं हैं। इस प्रकार, ओ 42 ए में कोई भी अभिव्यक्ति किसी वस्तु का संदर्भ है। एक स्ट्रिंग शाब्दिक मानक String ऑब्जेक्ट से विरासत में मिली वस्तु का संदर्भ है। नंबर - क्रमशः Integer ।

आप एक बृहदान्त्र के माध्यम से वस्तु के क्षेत्र तक पहुँच सकते हैं:

 Object: field 

कोई भी वस्तु विरासत में मिल सकती है। जब कोई वस्तु विरासत में मिलती है, तो उसके सभी क्षेत्र भी विरासत में मिलते हैं। उसी समय, खेतों को ओवरलोड किया जा सकता है:

 Derived object := object ( ~~ `Derived object`   `Object`. Field = "New value" ~~  `Field` . ) 

फ़ील्ड को अधिभारित करने के लिए := बजाय = चिह्न का उपयोग करें।

हालाँकि, आप किसी क्षेत्र को विरासत में मिली वस्तु के समान नाम के साथ घोषित कर सकते हैं:

 Another object := object ( Field := 123 ~~        `Field`. ) 

इस स्थिति में, नई ऑब्जेक्ट में एक ही नाम के दो फ़ील्ड होंगे। आप उन्हें इस प्रकार एक्सेस कर सकते हैं:

 Another object: field ~~ 123 Another object: field @object ~~ "Value" Another object: field @another object ~~ 123 

प्रोटोटाइप और अमूर्त क्षेत्र

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

इन उद्देश्यों के लिए, आप प्रोटोटाइप का उपयोग कर सकते हैं:

 Interface :=> void ( ~~~ .     `:=>`. ~~~ Name :=< string ~~~  .     `:=<`. ~~~ ) 

प्रोटोटाइप और साधारण वस्तुओं के बीच का अंतर यह है कि उनकी सामग्री (उदाहरण के लिए फ़ील्ड) तक पहुँचा नहीं जा सकता है। निम्नलिखित कोड में त्रुटि होगी:

 Interface: name ~~ : `Interface` -  . 

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

इसके अलावा, प्रोटोटाइप में अमूर्त क्षेत्र हो सकते हैं। ऐसे क्षेत्रों को विरासत के दौरान अतिभारित किया जाना चाहिए:

 Implementation 1 := interface ( Name = "Implementation 1" Implementation 1-specific field := 1 ) Implementation 2 := interface ( Name = "Implementation 2" Implementation 2-specific field := 2 ) 

इसके उद्देश्य से, एक प्रोटोटाइप एक सामान्य वर्ग है। इसके विपरीत, ओ 42 ए में एक सामान्य वस्तु एक वर्ग और इसका उदाहरण दोनों है।

बाद वाले को जावा प्रोग्रामर से परिचित होना चाहिए। ये अनाम वर्ग हैं:

 Runnable task = new Runnable() { @Override public void run() { System.err.println("Done!"); } } 

यह अभिव्यक्ति एक अनाम वर्ग और उसके उदाहरण दोनों का निर्माण करती है। ओ 42 ए के बीच अंतर यह है कि इस तरह से बनाए गए "कक्षाएं" आवश्यक रूप से गुमनाम नहीं हैं।

वस्तु मान

प्रत्येक वस्तु का एक अर्थ होता है। इस मान का प्रकार ऑब्जेक्ट से विरासत में मिला है - पूर्वज और बदला नहीं जा सकता है, जब तक कि यह void न हो।

ओ 42 ए में कई प्रकार के मूल्य हैं। उनमें से प्रत्येक को एक मानक वस्तु द्वारा दर्शाया गया है। यहाँ कुछ सरल प्रकार दिए गए हैं:

• Void एक खाली मूल्य है, बाकी सभी के लिए आधार प्रकार।
• Integer 64-बिट पूर्णांक है।
• Float 64-बिट फ्लोटिंग पॉइंट नंबर है।
• String - यूनिकोड वर्णों की एक स्ट्रिंग।

अधिक जटिल प्रकार मौजूद हैं: उदाहरण के लिए, पंक्तियाँ और सरणियाँ, रिश्ते और चर। आवश्यकतानुसार समय के साथ टाइप सिस्टम का विस्तार होगा।

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

 = value 

निम्नलिखित घोषणाएं समतुल्य हैं:

 Value := 5 ~~   ,  : Value := integer (= 5) 

एक मूल्य की परिभाषा विरासत में मिली है और इसे अतिभारित किया जा सकता है।

यहाँ दो संख्याओं के योग को निर्धारित करने का एक उदाहरण दिया गया है:

 Sum :=> integer ( Left operand :=< integer Right operand :=< integer = Left operand + right operand ) 

कृपया ध्यान दें कि एक ही परिभाषा विभिन्न मूल्यों को जन्म दे सकती है:

 Sum (Left operand = 1. Right operand = 2) ~~ 3 Sum (Left operand = -1. Right opernad = 10) ~~ 9 

एडेप्टर और नमूने

ऑब्जेक्ट बनाते समय, पूर्वज के अलावा, आप एक या अधिक नमूने निर्दिष्ट कर सकते हैं जिनके द्वारा ऑब्जेक्ट बनाया जाएगा:

 Object := ancestor & sample 1 & sample 2 (~~  ~~) 

इस मामले में, नमूनों के क्षेत्र और परिभाषाएं नई वस्तु द्वारा विरासत में मिलेंगी, और वस्तु स्वयं नमूनों ( बारबरा लिस्कोव प्रतिस्थापन सिद्धांत के अर्थ में ) के साथ संगत हो जाएगी। विरासत के संभावित संघर्षों को कुछ नियमों के अनुसार हल किया जाएगा।

हां, यह कई विरासत है। लेकिन क्या इसे लागू करना हमेशा उचित होता है? व्यवहार में, विरासत (कई सहित) का उपयोग तीन मामलों में से एक में किया जाता है:

1. यह इंगित करने के लिए कि वस्तु उसके द्वारा विरासत में मिली वस्तु का एक प्रकार है, जो कि कण के बजाय "यह" है। उदाहरण के लिए, "तरबूज एक बेरी है।"
2. ऑब्जेक्ट को कुछ गुण देने के लिए, कुछ भाषाओं में इस उद्देश्य के लिए "अशुद्धियाँ" (लक्षण, मिश्रण) का उपयोग किया जाता है।
3. एक अतिरिक्त प्रोग्राम इंटरफ़ेस को ऑब्जेक्ट में जोड़ने या एक अलग प्रकार का नेतृत्व करने के लिए, इस मामले में रचना का उपयोग करना बेहतर है।

पहले दो मामलों में नमूनों का उपयोग करना सुविधाजनक है, और तीसरे के लिए ओ 42 ए में एक अलग एडेप्टर तंत्र है।

एक एडाप्टर एक ऑब्जेक्ट फ़ील्ड है जिसका पहचानकर्ता एक नाम नहीं है, लेकिन एक अन्य ऑब्जेक्ट है:

 Foo := void ( Value := 123 @String := "Foo=" + value ~~ `String`   `@`  ~~   ,    . ) 

एक एडेप्टर ऑब्जेक्ट हमेशा अपनी पहचानकर्ता ऑब्जेक्ट को विरासत में प्राप्त करता है। कास्टिंग करते समय, ओ 42 ए पहले यह देखने के लिए जांचता है कि क्या ऑब्जेक्ट वांछित से विरासत में मिला है, और फिर इसके लिए एक एडाप्टर का उपयोग करने की कोशिश करता है। तो यहाँ यह कोड है:

 Print [foo] nl 

Foo=123 करेगा, इस तथ्य के बावजूद कि Print पैरामीटर एक स्ट्रिंग होना चाहिए, और String से Foo ऑब्जेक्ट विरासत String नहीं मिला है। संबंधित एडाप्टर को एक पैरामीटर के रूप में पारित किया जाएगा।

मानक मान प्रकार स्ट्रिंग और अन्य प्रकार के लिए एडेप्टर का उपयोग कर डाले जाते हैं।

आप एडॉप्टर को सीधे एक्सेस भी कर सकते हैं:

 Foo @@string 

आप स्वयं एडॉप्टर के क्षेत्र तक भी पहुँच सकते हैं:

 Foo: length @string ~~ 7 

ध्यान दें कि एडेप्टर फ़ील्ड्स तक पहुँचने के लिए सिंटैक्स ऑब्जेक्ट के फ़ील्ड्स तक पहुँचने के लिए समान है। जब तक क्षेत्र के स्रोत (इस मामले में @string ) को @string करना अनिवार्य नहीं है।

अन्य मामलों में भी एडेप्टर का उपयोग किया जाता है। उदाहरण के लिए, मुख्य एप्लिकेशन ऑब्जेक्ट को इंगित करने के लिए:

 Use namespace 'Console' ~~ `Print`  `Main`    `Console`. @Main := * { ~~  ,    `Main`  . Print "Hello, World!" nl } 

एप्लिकेशन में @Main एडॉप्टर एक्सेस करना शामिल होगा, जो प्रसिद्ध टेक्स्ट को प्रिंट करेगा।

कई अनुप्रयोगों का आविष्कार किया जा सकता है। उदाहरण के लिए, आप एक मनमानी वस्तु के हैश फ़ंक्शन की गणना करने के लिए एडेप्टर का उपयोग कर सकते हैं। बस @Hash code एडेप्टर को परिभाषित करें।

एडेप्टर आपको किसी भी ऑब्जेक्ट में वांछित कार्यक्षमता जोड़ने की अनुमति देते हैं। यह Void आधार ऑब्जेक्ट में किसी भी फ़ील्ड की आवश्यकता को समाप्त करता है। इसके अलावा, यह __str__ के रूप में एनोटेट या विशेष रूप से नामित विधियों के विपरीत, टाइप-सुरक्षित है।

सामान्य प्रोग्रामिंग

ओ 42 ए में उनके विशिष्ट प्रकार के मापदंडों के साथ कोई परिचित टेम्पलेट (टेम्पलेट) या सामान्यीकरण (जेनरिक) नहीं हैं। ओ42 ए में प्रत्येक वस्तु पहले से ही एक सामान्यीकरण है, जो उस वस्तु और पड़ोसी क्षेत्रों को शामिल करता है।

तथ्य यह है कि किसी वस्तु का संदर्भ आमतौर पर स्थिर नहीं होता है। इसका मतलब यह है कि यदि आप किसी ऐसी वस्तु को प्राप्त करते हैं, जिसमें ऐसी कड़ी है, तो विरासत में मिली वस्तु उसी लिंक का उपयोग करके किसी अन्य वस्तु को प्राप्त कर सकती है।

यहाँ एक उदाहरण है:

 Base := void ( A := void ( F := 123 ~~ `Base: a`   `F'. ) B := a ( ~~ `Base: b`   `Base: a`.  = 456 ) ) Object := base ( ~~  `Base`. A = * ( ~~  `A`. G := f * 10 ~~   `A: g`. ) ) Object: a: g ~~ 1230 Object: b: g ~~ 4560 

ध्यान दें कि Object: a: g फ़ील्ड को Base: b बाद परिभाषित किया गया था। हालाँकि, अभिव्यक्ति Object: b: g बिल्कुल सही है।

तथ्य यह है कि वस्तुएं न केवल अन्य वस्तुओं को प्राप्त करती हैं, बल्कि अभिव्यक्तियां जो उन्हें संदर्भित करती हैं। एक अलग संदर्भ में निष्पादित होने के नाते, इस तरह की अभिव्यक्ति किसी अन्य ऑब्जेक्ट के लिए हल हो सकती है और इसलिए, थोड़ा भिन्न विरासत पदानुक्रम का कारण बन सकती है। यह महत्वपूर्ण है कि जिस भी संदर्भ में अभिव्यक्ति की अनुमति है, परिणामी वस्तु हमेशा मूल के साथ संगत होती है, अर्थात, या तो यह है, या इसका उत्तराधिकारी है।

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

ऊपर का सारांश

ओ 42 ए में बहुत अधिक है जिसके बारे में मैंने बात नहीं की:

• वाक्यों का निर्माण कैसे करें,
• अनिवार्य प्रोग्रामिंग का समर्थन करने के बारे में,
• वाक्यांशों के बारे में - डोमेन-विशिष्ट अभिव्यक्तियों (कोई लंबो कैलकुलस!) के निर्माण का एक विशेष रूप से वाक्य-विन्यास तरीका!
• ऑपरेटर ओवरलोडिंग के बारे में (ऑपरेटर भी वाक्यांश हैं, वैसे),
• चर और संबंधों सहित जटिल डेटा प्रकार,
• मैक्रोज़ और निर्देशों के बारे में - संकलन के दौरान शामिल मेटाप्रोग्रामिंग तंत्र,
• अनुप्रयोग स्रोत ट्री के मॉड्यूल और संरचना के बारे में।

और हां, मैंने कई विवरणों को छोड़ दिया। यह भविष्य के लेखों के लिए सामग्री है।

हालाँकि, इस लेख का उद्देश्य आपको अवधारणा और इसके कार्यान्वयन से परिचित कराना था। मुझे आशा है कि मैंने सब कुछ स्पष्ट रूप से समझाया।

तो, किसी भाषा की मुख्य और एकमात्र शब्दार्थ इकाई एक ऐसी वस्तु है जो बहुत सारी चीजों को बदल सकती है:

• एक वस्तु एक नाम स्थान है
  इस पर टिप्पणी करने के लिए विशेष रूप से कुछ भी नहीं है: इस क्षेत्र में ऑब्जेक्ट के क्षेत्र प्रतीक हैं।
  
• एक वस्तु एक वर्ग है।
  ऊपर भी वर्णित है। यदि आपको सीधे ऑब्जेक्ट विरासत में मिलते हैं तो कक्षाओं की आवश्यकता नहीं होती है।
  
• एक वस्तु एक फ़ंक्शन है (और एक ही समय में एक विधि)
  ऐसे फ़ंक्शन के तर्क ऑब्जेक्ट के क्षेत्र हैं, और परिणाम इसका मूल्य है।
  ऑब्जेक्ट का इनहेरिटेंस एक फ़ंक्शन कॉल है, फ़ील्ड ओवरलोडिंग एक पैरामीटर प्रतिस्थापन (करी) है।
  लेकिन एक वस्तु अधिक कर सकती है। आखिरकार, इसे फिर से विरासत में लिया जा सकता है, और खेतों को फिर से लोड किया जा सकता है (पुनः ... करी?)।
  
• एक वस्तु एक सामान्यीकरण है
  हाँ, अजीब। हालाँकि, संभावनाएँ और भी अधिक हैं।
  एक सामान्यीकृत ऑब्जेक्ट का पारंपरिक फ़ंक्शंस पर सामान्य लाभ या सामान्य कार्यों पर ऑब्जेक्ट-फ़ंक्शन के समान टेम्प्लेट होता है: पैरामीटर फ़ील्ड को बार-बार ओवरलोड किया जा सकता है। पहले से प्रतिस्थापित प्रकार के पैरामीटर को बदलने के लिए जावा के सामान्यीकरण या C ++ टेम्पलेट के एक उदाहरण की कोशिश करें। और कभी-कभी मैं वास्तव में अनावश्यक अमूर्त वर्गों का उत्पादन नहीं करना चाहता हूं।
  

अतिरेक और सामान्यीकरण

आपको हर चीज के लिए भुगतान करना होगा। और "सब कुछ एक वस्तु है" की कीमत अधिक है।

सबसे सरल अभिव्यक्ति

 a + b 

, जहां a और b पूर्णांक हैं, जिन्हें बस जोड़ने की आवश्यकता है, वास्तव में यह वस्तुओं का ढेर बन जाता है:

 Integers: add ( Left operand = a Right operand = b ) 

निर्माण करने की आवश्यकता है (खेतों को ओवरलोड करके विरासत में मिली), केवल उनके मूल्यों का अनुरोध करने के लिए।

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

अतिरेक को समाप्त किया जा सकता है। इस प्रक्रिया को सामान्यीकरण कहा जाता है। उसके लिए धन्यवाद, ऊपर दिए गए उदाहरण को दो संख्याओं के जोड़ में संकलित किया जाएगा। आखिरकार, अगर कोई व्यक्ति समझता है कि यह सिर्फ इसके अलावा है, तो संकलक यह सिखा सकता है।

सामान्यीकरण की तकनीकें बहुत अच्छी हैं। और इन तकनीकों का कार्यान्वयन अपनी प्रारंभिक अवस्था में है। हालांकि, ऐसे सरल मामलों में, सब कुछ काम करता है। इसे संकलित करके जांचा जा सकता है, उदाहरण के लिए, सामान्य रूप से चालू और बंद ( o42ac -normalize=0 ) के साथ ओ 42 ए टेस्ट सूट। निष्पादन योग्य फ़ाइलों का आकार चार गुना भिन्न होगा।

और यहाँ एलएलवीएम आईआर में "हैलो, वर्ल्ड!" प्रोग्राम है:

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

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

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

लेकिन सामान्यीकरण के अलावा, कुछ और लागू किया जाता है:

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

स्थिति और संभावनाएँ

ओ 42 ए परियोजना को एक व्यक्ति द्वारा पिछले साढ़े तीन वर्षों से पूर्णकालिक आधार पर लागू किया जा रहा है। इसलिए आपको समझना चाहिए कि मैं इस काम को गंभीरता से लेता हूं।

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

परियोजना विकास प्रोटोटाइप के कार्यान्वयन चरण में है। संकलक जावा में लिखा गया है और निष्पादन योग्य कोड उत्पन्न करने के लिए LLVM का उपयोग करता है। स्रोत कोड GPLv3 + लाइसेंस (LGPLv3 + के तहत रनटाइम लाइब्रेरी) के तहत उपलब्ध हैं।इस परियोजना की एक वेबसाइट है, जिसमें नटखट अंग्रेजी में प्रलेखन है, साथ ही एक मंच भी है जो अभी भी खाली है (मैं स्पष्ट कारणों के लिए सीधे लिंक प्रदान नहीं करता हूं)।

O42a-0.2.4 के वर्तमान संस्करण में स्रोत कोड की 130 हजार से अधिक लाइनें हैं । कंपाइलर अभी भी काफी नाजुक है, और लाइब्रेरी लगभग न के बराबर हैं। लक्ष्य प्लेटफ़ॉर्म GNU / Linux x86_64 है, अन्य का परीक्षण नहीं किया गया है।

आने वाले महीनों में, मैं एक संग्रह पुस्तकालय, साथ ही एक I / O पुस्तकालय को लागू करने की योजना बना रहा हूं। उसी समय, मैं कंपाइलर को डीबग करूंगा, शेष प्रश्नों को भाषा पर ही हल करूंगा, और रोसेटा कोड के साथ उदाहरण भी लिखूंगा। यह माना जाता है कि संस्करण 0.3.0 पहले से ही किसी भी तरह इस्तेमाल किया जा सकता है।

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

अगर किसी के पास इस तरह की महत्वाकांक्षी परियोजना करने की गंभीर इच्छा है - तो हमसे संपर्क करें। हालांकि मैं एक साधारण प्रोग्रामर हूं, लेकिन मैं इस राक्षस को मोनेटाइज करने के विचारों के साथ आ सकता हूं। बस ध्यान रखें कि यह एक वेब दो-शून्य-मूल्य-10k-want-milen-स्टार्टअप नहीं है। ये गंभीर विपणन सहित गंभीर, दीर्घकालिक निवेश हैं।

यदि मैं सामान्य रूप से ओपन सोर्स और विशेष रूप से ओ 42 ए प्रोजेक्ट के लाभ के लिए मुफ्त में काम करना चाहता हूं, तो मुझे कुछ कार्य मिलेंगे, जिसमें एक कार्य सीधे ओ 42 ए से संबंधित नहीं है और एक स्वतंत्र प्रोजेक्ट (शुद्ध सी में आवश्यक पुस्तकालय) के रूप में उपयोगी है।

यदि आपके पास विचार है कि आप विकास को कैसे वित्त दे सकते हैं, तो कृपया साझा करें।