जूलिया-देव सूत्र को प्रतिध्वनित करते हुए, मुझे लगता है कि इस प्रस्ताव पर स्टीफन की मुख्य टिप्पणी को उद्धृत करना उपयोगी होगा:

बस यहां अपेक्षाएं स्थापित करने के लिए, मुझे नहीं लगता कि जूलिया 1.0 से पहले "वाक्य रचनात्मक नवाचार" के रास्ते में बहुत कुछ होगा। (एकमात्र अपवाद जिसके बारे में मैं सोच सकता हूं वह है नया f.(v) वेक्टरकृत कॉलिंग सिंटैक्स।) हालांकि मनमाने ढंग से कार्य करने का कोई तरीका होने पर इंफिक्स ऑपरेटरों के रूप में अच्छा व्यवहार हो सकता है, यह भाषा में सिर्फ एक महत्वपूर्ण मुद्दा नहीं है।

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

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

मुझे लगता है कि सुझाए गए "दीर्घकालिक" पार्सर परिवर्तनों के संबंध में जॉनमीलेसवाइट की टिप्पणियां बहुत ही उपयुक्त हैं। लेकिन "मामूली परिवर्तन" और "वैकल्पिक" समूह, जहाँ तक मैं देख सकता हूँ, बहुत आत्म-निहित और कम प्रभाव वाले हैं।

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

व्यक्तिगत रूप से मुझे यह सिंटैक्स काफी बदसूरत और टाइप करने में मुश्किल लगता है। लेकिन मैं सहमत हूं कि अधिक सामान्य इंफिक्स सिंटैक्स होना अच्छा होगा।

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

मैं वास्तव में इसके लिए | को पुनः प्राप्त करने और a |op| b का उपयोग करने पर विचार करूंगा। यकीनन सामान्य इन्फिक्स सिंटैक्स बिटवाइज़ या की तुलना में अधिक महत्वपूर्ण है। (हमने पहले बिटवाइज़ ऑपरेटरों को पुनः प्राप्त करने के बारे में बात की है; वे सिंटैक्स की बर्बादी की तरह लगते हैं जैसा कि यह है।)

a f b सरणी संयोजन और मैक्रो कॉल सिंटैक्स के बाहर उपलब्ध है।

a f b काम कर सकता है, लेकिन यह बहुत नाजुक लगता है। किसी को यह समझाने की कोशिश करें कि क्यों a^2 f b^2 f c^2 कानूनी है लेकिन a f b c और a+2 f b+2 f c+2 ऐसा नहीं है। (मुझे पता है, वह आखिरी मानता है कि प्राथमिकता पूर्व-समय है, लेकिन इससे कोई फर्क नहीं पड़ता कि प्राथमिकता क्या है, यह सामान्य प्रकार की बात एक चिंता का विषय है)।

जहां तक a |op| b : शुरू में मैंने इसी तरह के प्रस्ताव का समर्थन किया, a %op% b , जैसा कि आप Google समूह थ्रेड में देख सकते हैं। लेकिन प्रस्तावित |> और <| के बारे में अच्छी बात यह है कि वे बाइनरी ऑपरेटरों के रूप में प्रत्येक व्यक्तिगत रूप से उपयोगी हैं, और वे स्वाभाविक रूप से वांछित के रूप में काम करने के लिए गठबंधन करते हैं (सही प्राथमिकता और समूह को देखते हुए, यानी। ) इसका मतलब है कि आप मौजूदा पार्सर तंत्र का उपयोग करके इसे अल्पावधि में लागू कर सकते हैं, और इस प्रकार भविष्य में पार्सर डेवलपर्स के लिए सिरदर्द पैदा करने से बच सकते हैं, जैसा कि मैंने ऊपर जॉनमाइल्सवाइट के जवाब में कहा था।

इसलिए जब मैं a |op| b पसंद करता हूं और निश्चित रूप से इसका विरोध नहीं करूंगा, मुझे लगता है कि हमें आवश्यक पार्सर परिवर्तनों को सरल बनाने के लिए दो अलग-अलग ऑपरेटरों के लिए एक रास्ता तलाशना चाहिए। यदि हम अधिकतम टाइपेबिलिटी के लिए जा रहे हैं और "बिटवाइज या" के बजाय | अर्थ "पाइप" होने का विरोध नहीं कर रहे हैं, तो a |op\\ b या a |op& b के बारे में क्या?

"पार्सर डेवलपर्स के लिए सिरदर्द" सबसे कम संभव चिंता है।

"पार्सर डेवलपर्स के लिए सिरदर्द" सबसे कम संभव चिंता है।

एक पार्सर डेवलपर के रूप में, मैं स्पष्ट रूप से इससे सहमत हूं।

|> और <| दोनों पूरी तरह से अच्छे इंफिक्स ऑपरेटर हैं, लेकिन दो अन्य ऑपरेटरों का उपयोग करके सामान्य ऑपरेटर सिंटैक्स को लागू करने के लिए शून्य लाभ है। और बहुत कुछ कहने की जरूरत है कि वाक्य रचना कितनी क्रियात्मक और अप्रभावी है।

दो अन्य ऑपरेटरों का उपयोग करके सामान्य ऑपरेटर सिंटैक्स को लागू करने का कोई लाभ नहीं है।

स्पष्ट होने के लिए, यहां दीर्घकालिक दृष्टि यह है कि बाइनरी f <| y , बाइनरी x |> f , और टर्नरी x |> f <| z होगी, जहां पहला केवल एक फ़ंक्शन है लेकिन दूसरा दो को पार्सर में परिवर्तन के रूप में लागू किया गया है।

यह विचार कि इसे दो सामान्य कार्यों |> और <| का उपयोग करके कार्यान्वित किया जा सकता है, उस दृष्टि का एक अस्थायी पुल है।

और बहुत कुछ कहने की जरूरत है कि वाक्य रचना कितनी क्रियात्मक और अप्रभावी है।

यह एक उचित बिंदु है। |> और <| को | और & से बदलने के बारे में कैसे? वे एक जोड़ी के रूप में और व्यक्तिगत रूप से दोनों को समझते हैं, हालांकि वे हॉकी खिलाड़ी के लिए थोड़ा परेशान हो सकते हैं।

इसके | और & दोनों को चोरी करना ASCII का अच्छा आवंटन नहीं होगा, और मुझे संदेह है कि कई डिलीमीटर सममित होने के लिए पसंद करेंगे।

अगर लोग अन्य कारणों से x |> f <| y टर्नरी ऑपरेटर चाहते हैं, तो यह ठीक है, लेकिन मुझे लगता है कि इसे अलग से माना जाना चाहिए। मुझे यकीन नहीं है कि पार्सर को |> को फ़्लिप किए गए <| में बदलना चाहिए। अन्य समान ऑपरेटर जैसे < उस तरह से काम नहीं करते हैं। लेकिन यह भी एक अलग मुद्दा है।

दोनों की चोरी | और इसके लिए एएससीआईआई का अच्छा आवंटन नहीं होगा, और मुझे संदेह है कि कई डिलीमीटर सममित होने के लिए पसंद करेंगे।

ठीक है।

मैं समझता हूं कि > और < टाइप करना कठिन है। एक मानक कीबोर्ड पर समरूपता और टाइपेबिलिटी के संदर्भ में, मुझे लगता है कि सबसे आसान &% और %& जैसा कुछ हो सकता है, लेकिन यह गंभीर रूप से बदसूरत है, आर समानांतर या नहीं। /| और |/ भी विचार करने योग्य हो सकते हैं।

...

मुझे यकीन नहीं है कि पार्सर को बदलना चाहिए |> एक फ़्लिप करने के लिए <|

मुझे लगता है कि आपने गलत समझा है। a |> b को b(a) पर पार्स करना चाहिए। (विशेष पार्सिंग के बिना संस्करण ((x,y)->y(x))(a,b) होगा, जो एक ही चीज़ का मूल्यांकन करता है, लेकिन अधिक ओवरहेड के साथ।)

ए |> बी को बी (ए) को पार्स करना चाहिए

आह, ठीक है, मिल गया।

मुझे लगता है कि हम वर्षों तक किस पात्र का उपयोग कर सकते हैं, इसके बारे में हम बाइक कर सकते हैं। मैं निर्णय लेने के लिए @StefanKarpinski (इस बातचीत में अब तक के सबसे वरिष्ठ व्यक्ति के रूप में) पर भरोसा करूंगा, और मैं इसके साथ ठीक रहूंगा। भले ही यह ऐसा कुछ है जिसके खिलाफ मैंने तर्क दिया है (जैसे a f b ।)

यह देखने के लिए कि क्या अपील करता है, यहां कुछ विकल्प दिए गए हैं:
a |>op<| b (वर्तमान |> अपरिवर्तित छोड़कर)
a |{ op }| b (कई सामान्य कीबोर्ड पर पास और समान शिफ्ट स्थिति, बहुत बदसूरत नहीं। स्टैंडअलोन के रूप में थोड़ा अजीब।)
a \| op |\ b या a /| op |/ b या उसके संयोजन
a $% op %$ b (अपेक्षाकृत टाइप करने योग्य, आर-प्रेरित। लेकिन थोड़े बदसूरत।)
a |% op %| b
a |- op -| b
a |: op :| b
a | op \\ b
a | op ||| b
a op b

स्टीफन मुझसे ज्यादा सीनियर नहीं हैं।

ऐसा लगता है कि आपने अभी-अभी इस मुद्दे पर BDFL शक्तियों के लिए स्वयं को नामांकित किया है! ;)

a @op@ b ?

मुझे लगता है कि मेरा वोट \| , |\ , /| , और |/ के सभी 4 का उपयोग करना है। मूल्यांकन के लिए नीचे, करी के लिए ऊपर; समारोह की ओर पट्टी। इसलिए:
a \| f (या f |/ a ) -> f(a)
a /| f (या f |\\ a ) -> (b...)->f(a,b...)
f |\ b (या b //| f ) -> (a...)->f(a...,b)
और इस तरह:
a \| f |\ b (या a /| f |/ b ) -> f(a,b)
a \| f |\ b |\ c (या a /| b /| f |/ c ) -> f(a,b,c)

शायद |/ को छोड़कर, 4 मुख्य ऑपरेटरों में से प्रत्येक अपने आप में उपयोगी है। अतिरेक निश्चित रूप से गैर-पायथनिक होगा, लेकिन मुझे लगता है कि तार्किक स्वच्छता जूलियन है। और एक व्यावहारिक मामले के रूप में, आप इंफिक्स मुहावरे के किसी भी संस्करण का उपयोग कर सकते हैं जो आपको टाइप करना आसान लगता है; वे दोनों समान रूप से पठनीय हैं, इसमें एक बार जब आप एक सीख लेते हैं तो आप स्वाभाविक रूप से दोनों को समझ जाते हैं।

जाहिर है, यह समान रूप से समझ में आता है यदि आप सभी स्लैश को स्वैप करते हैं, ताकि ऊपर तीर मूल्यांकन के लिए और करी के लिए नीचे हो।

मैं अभी भी ऑन हाई से शब्द की प्रतीक्षा कर रहा हूं (और इसका मतलब अनुमान लगाने में मेरी नौसिखिया अनाड़ीपन के लिए मैं क्षमा चाहता हूं)। लेकिन अगर इस बाइकशेड से लंबा कोई भी इस या किसी अन्य संस्करण के लिए कम से कम दो नए प्रतीकों के साथ एक निर्णय लेता है, तो मुझे एक अल्पकालिक पैच (फ़ंक्शंस का उपयोग करके) और/या एक उचित (रूपांतरण का उपयोग करके) लिखने में खुशी होगी।

हम जहां तक ​​संभव हो BDFL होने से बचने की कोशिश करते हैं :)

मैंने अभी सोचा था कि मैं कुछ त्वरित चीजें नोट करूंगा।

सबसे पहले, प्रस्तावित किए जा रहे संकेतन का दूसरा लाभ ("स्टैंडअलोन उपयोग") यह है कि <| का उपयोग अन्य संदर्भों में किया जा सकता है, इस तरह से पठनीयता में सुधार होता है। उदाहरण के लिए, यदि आपके पास स्ट्रिंग्स की एक सरणी है, A , और उन सभी को बाईं ओर 10 तक पैड करना चाहते हैं, तो आपको अभी map(i->lpad(i,10),A) लिखना होगा। इसे पढ़ना अपेक्षाकृत कठिन है। इस संकेतन के साथ, यह map(lpad<|10,A) हो जाता है, जो मुझे लगता है कि आप सहमत होंगे, काफी साफ है।

दूसरा, इसके पीछे विचार यह है कि अंकन को सुसंगत रखा जाए। पहले से ही एक |> ऑपरेटर है, जो किसी फ़ंक्शन कॉल के "फिक्स" को प्रीफ़िक्स से पोस्टफ़िक्स में बदलने के लिए मौजूद है। यह सिर्फ नोटेशन बढ़ाता है।

तीसरा, प्रत्यक्ष इन्फिक्स को a f b के रूप में उपयोग करने की संभावना एक बड़ी समस्या है। a + b और a * b की प्राथमिकता समान होगी, क्योंकि + और * फ़ंक्शन नाम हैं, और सिस्टम के लिए यह संभव नहीं होगा परिवर्तनशील वरीयता रखते हैं। वह, या इसे मौजूदा इंफिक्स ऑपरेटरों के साथ अलग तरह से व्यवहार करना होगा, जिससे भ्रम पैदा हो सकता है।

उदाहरण के लिए, यदि आपके पास स्ट्रिंग्स की एक सरणी है, A , और उन सभी को बाईं ओर से 10 तक पैड करना चाहते हैं, तो अभी, आपको map(i->lpad(i,10),A) लिखना होगा। इसे पढ़ना अपेक्षाकृत कठिन है। इस संकेतन के साथ, यह map(lpad<|10,A) हो जाता है, जो मुझे लगता है कि आप सहमत होंगे कि यह काफी साफ है।

मैं दृढ़ता से सहमत नहीं हूं। प्रस्तावित वाक्य रचना है - मुझे क्षमा करें - ASCII सलाद, पर्ल और एपीएल के कुछ सबसे खराब अपराधों पर आधारित, अन्य भाषाओं में मिसाल के बिना आकस्मिक पाठक को यह बताने के लिए कि क्या हो रहा है। वर्तमान सिंटैक्स, जबकि कुछ वर्ण लंबे (पांच?), किसी के लिए भी स्पष्ट है जो जानता है कि i->expr एक लैम्ब्डा सिंटैक्स है - जो कि भाषाओं के एक बड़े और बढ़ते सेट में है।

a + b और a * b की प्राथमिकता समान होगी, क्योंकि + और * फ़ंक्शन नाम हैं, और सिस्टम के लिए परिवर्तनशील प्राथमिकता होना संभव नहीं होगा। वह, या इसे मौजूदा इंफिक्स ऑपरेटरों के साथ अलग तरह से व्यवहार करना होगा, जिससे भ्रम पैदा हो सकता है।

मुझे नहीं लगता कि यह कोई वास्तविक समस्या है; हम केवल यह कह सकते हैं कि a f b infix की प्राथमिकता क्या है, और सभी मौजूदा वरीयता स्तरों को भी बनाए रखें। यह काम करता है क्योंकि प्राथमिकता फ़ंक्शन के नाम से निर्धारित होती है; "+" नामक किसी भी फ़ंक्शन में "+" प्राथमिकता होगी।

हां, हम इसे 1+2 in 1+2 सिंटैक्स के लिए पहले ही कर चुके हैं, और यह कोई समस्या नहीं है।

मुझे नहीं लगता कि यह कोई वास्तविक समस्या है; हम केवल यह कह सकते हैं कि afb infix की प्राथमिकता क्या है, और सभी मौजूदा वरीयता स्तरों को भी बनाए रखें। यह काम करता है क्योंकि प्राथमिकता फ़ंक्शन के नाम से निर्धारित होती है; "+" नामक किसी भी फ़ंक्शन में "+" प्राथमिकता होगी।

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

मैं दृढ़ता से सहमत नहीं हूं। प्रस्तावित वाक्य रचना है - मुझे क्षमा करें - ASCII सलाद, पर्ल और एपीएल के कुछ सबसे खराब अपराधों पर आधारित, अन्य भाषाओं में मिसाल के बिना आकस्मिक पाठक को यह बताने के लिए कि क्या हो रहा है। वर्तमान सिंटैक्स, जबकि कुछ वर्ण लंबे (पांच?), किसी के लिए भी स्पष्ट है जो जानता है कि i->expr एक लैम्ब्डा सिंटैक्स है - जो कि भाषाओं के एक बड़े और बढ़ते सेट में है।

शायद मैं जो कह रहा हूं उस पर मुझे स्पष्ट होना चाहिए। मैं कह रहा हूं कि ऑपरेशन को "lpad by 10" के रूप में वर्णित करने में सक्षम होना i->lpad(i,10) की तुलना में बहुत स्पष्ट है। और मेरे विचार में, lpad<|10 वह निकटतम है जिसे आप गैर-संदर्भ-विशिष्ट रूप में प्राप्त कर सकते हैं।

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

मुझे पूछना चाहिए - lpad<|10 , x|>sin|>exp से अधिक "ASCII सलाद" कैसा है? फिर भी |> संकेतन जोड़ा गया। बैश स्क्रिप्टिंग के साथ तुलना करें, जहां | का उपयोग बाईं ओर के तर्क को दाईं ओर कमांड को पास करने के लिए किया जाता है - यदि आप जानते हैं कि इसे "पाइप" कहा जाता है, तो यह एक _little_ अधिक समझ में आता है, लेकिन यदि आप प्रोग्रामिंग में कुशल नहीं हैं, इसका कोई मतलब नहीं है। उस संबंध में, |> वास्तव में अधिक समझ में आता है, क्योंकि यह एक तीर की तरह अस्पष्ट रूप से दिखता है। और फिर <| संकेतन का एक स्वाभाविक विस्तार है।

कुछ अन्य सुझावों के साथ तुलना करें, जैसे %func% , जो _does_ किसी अन्य भाषा में एक मिसाल है, लेकिन जो उन लोगों के लिए पूरी तरह से अपारदर्शी है जिन्हें भाषा में प्रोग्रामिंग का व्यापक ज्ञान नहीं है।

ध्यान रहे, मैंने पुरानी चर्चाओं में से एक पर थोड़ा पीछे मुड़कर देखा, और मैंने देखा कि एक अन्य भाषा में एक संकेतन का उपयोग किया गया है जो सिद्धांत रूप में काफी अच्छा होगा। हास्केल स्पष्ट रूप से a |> b c d का उपयोग a |> b c d b(a,c,d) प्रतिनिधित्व करने के लिए करता है। यदि फ़ंक्शन नाम के बाद के रिक्त स्थान आपको इस तरह से "पैरामीटर" निर्दिष्ट करने की अनुमति देते हैं, तो यह अच्छी तरह से काम करेगा - map(lpad 10,A) । यूनरी ऑपरेटरों के साथ एकमात्र समस्या उत्पन्न होती है - उदाहरण के लिए, map(+ 10,A) एक त्रुटि उत्पन्न करेगा, क्योंकि यह i->+(i,10) के बजाय "+10" पर व्याख्या करेगा।

a f b पर: प्राथमिकता के मुद्दे ग्लेन-ओ के सुझाव के रूप में खराब नहीं हो सकते हैं, लेकिन जब तक उपयोगकर्ता द्वारा परिभाषित इंफिक्स फ़ंक्शंस की सबसे कम प्राथमिकता नहीं होती है, तब तक वे मौजूद होते हैं। कहते हैं, तर्क के लिए हम उन्हें पूर्व-समय देते हैं। उस मामले में,
a^2 f b^2 => f(a^2,b^2)
a+2 f b+2 => a+f(2,b)+2
a^2 f^2 b^2 => (f^2)(a^2,b^2)
a f+2 b => सिंटैक्स त्रुटि?

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

करी मुहावरे की उपयोगिता पर
मैं ग्लेन-ओ से सहमत हूं कि (i)->lpad(i,10) केवल lpad<|10 से भी बदतर है (या, यदि हम ऐसा चुनते हैं, तो lpad |\ 10 , या जो भी हो)। i एक पूरी तरह से बाहरी संज्ञानात्मक बोझ और त्रुटियों का संभावित स्रोत है; वास्तव में, मैं कसम खाता हूँ कि जब मैं इसे अभी टाइप कर रहा था, मैंने अनजाने में शुरुआत में (i)->lpad(x,10) टाइप किया था। तो, एक इंफिक्स करी ऑपरेशन करना मुझे एक अच्छा विचार लगता है।
हालांकि, अगर यह इरादा है, तो हम जिस भी इंफिक्स मुहावरे पर समझौता करते हैं, हम अपना खुद का करी ऑपरेशन बना सकते हैं। अगर यह a f b है, तो lpad rcurry 10 जैसा कुछ ठीक रहेगा। बिंदु पठनीयता है, कीस्ट्रोक्स नहीं। तो मुझे लगता है कि यह <| के लिए केवल एक कमजोर तर्क है।

a |> b c d . पर
मुझे यह प्रस्ताव बहुत पसंद है। मुझे लगता है कि हम इसे बना सकते हैं ताकि |> दोनों तरफ रिक्त स्थान स्वीकार कर सकें, इसलिए a b |> f c d => f(a,b,c,d) ।

(नोट: यदि मेरे दोनों सुझाव a b |> f c d और ग्लेन-ओ के map(lpad 10,A) , तो यह एक कोने का मामला बनाता है: (a b) |> f c d => f((x)->a(x,b),c,d) । लेकिन मैं सोचें कि यह सहनीय है।)

यह अभी भी a f b के रूप में ऑपरेटर वरीयता के मामले में इसी तरह के मुद्दे हैं। लेकिन किसी भी तरह से मुझे लगता है कि वे अधिक सहनीय हैं यदि आप के साथ के टर्नरी ऑपरेटर की प्राथमिकता होने के बजाय ऑपरेटर |> की प्राथमिकता के संदर्भ में कम से कम उनके बारे में बात कर सकते हैं। ।

0.5 पर lpad.(["foo", "bar"], 10) आज़माएं। मौजूदा |> सभी को बिल्कुल पसंद नहीं है।

@tkelman : मैं इस मुद्दे को देखता हूं, लेकिन आपका क्या मतलब है? आपको लगता है कि इसके लिए अतिरिक्त उपयोग जोड़ने से पहले हमें मौजूदा |> को ठीक करना चाहिए? यदि हां, तो कैसे?

मुझे व्यक्तिगत रूप से लगता है कि हमें मौजूदा |> से छुटकारा पाना चाहिए।

0.5 पर lpad.(["foo", "bar"], 10) आज़माएं। मौजूदा |> सभी को बिल्कुल पसंद नहीं है।

मुझे लगता है कि आप बिंदु चूक गए हैं। हाँ, func.() अंकन अच्छा है, और कुछ स्थितियों में समस्या को दरकिनार कर देता है। लेकिन मैं एक साधारण प्रदर्शन के रूप में map फ़ंक्शन का उपयोग करता हूं। कोई भी फ़ंक्शन जो किसी फ़ंक्शन को तर्क के रूप में लेता है, इस सेटअप से लाभान्वित होगा। एक उदाहरण के रूप में, विशुद्ध रूप से मेरी बात को प्रदर्शित करने के लिए, आप कुछ संख्याओं को कुछ संदर्भ संख्या के साथ उनके कम से कम सामान्य गुणक के आधार पर क्रमबद्ध करना चाह सकते हैं। जो अधिक साफ और पढ़ने में आसान लगता है: sort(A,by=i->lcm(i,10)) या sort(A,by=lcm 10) ?

मैं एक बार फिर यह नोट करना चाहता हूं कि इंफिक्स ऑपरेटरों को परिभाषित करने का कोई भी तरीका एक ऑपरेटर बनाने की अनुमति देगा जो ग्लेन-ओ <| करना चाहता है, ताकि कम से कम वह sort(A,by=lcm |> currywith 10) जैसा कुछ लिख सके a ... f ... b => f(a,b) बनाने के तरीके पर चर्चा करना है। मैं समझता हूं कि मौजूदा |> या प्रस्तावित <| सार्थक ऑपरेटर हैं या नहीं, उस बिंदु से कुछ संबंध हैं, लेकिन आइए कोशिश करें कि हम बहुत अधिक विचलित न हों।

व्यक्तिगत रूप से, मुझे लगता है कि a |> b c प्रस्ताव अब तक का सबसे अच्छा प्रस्ताव है। यह हास्केल से मौजूदा सम्मेलन का पालन करता है; यह तार्किक रूप से मौजूदा |> ऑपरेटर से संबंधित है; यह यथोचित रूप से पठनीय और यथोचित रूप से आसान-से-प्रकार दोनों है। तथ्य यह है कि मुझे लगता है कि यह स्वाभाविक रूप से अन्य उपयोगों तक फैला हुआ है, यह गौण है। यदि आप असहमत हैं, तो कृपया कम से कम मूल मुहावरे पर अपनी भावनाओं का उल्लेख करें, न कि केवल प्रस्तावित माध्यमिक उपयोगों पर।

मेरा मतलब था कि यह स्थिरता के मुद्दों की ओर जाता है, इसलिए मैं कह रहा हूं "या इसे मौजूदा इंफिक्स ऑपरेटरों को अलग तरह से व्यवहार करना होगा, जिससे भ्रम पैदा हो सकता है"।

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

ध्यान दें कि |> पहले से ही तुलना के निकट पूर्वता रखता है। किसी भी अन्य प्राथमिकता के लिए, स्पष्ट रूप से, मुझे लगता है कि कोष्ठक ठीक हैं।

यदि आप मुझसे सहमत नहीं हैं, और यदि हम a |> f b का उपयोग कर रहे हैं, तो समान ऑपरेटर |+> , |*> , और |^> हो सकते हैं, जो |> जैसा ही काम किया, लेकिन उनके केंद्रीय ऑपरेटर की प्राथमिकता थी। मुझे लगता है कि यह अधिक है लेकिन यह एक संभावना है।

प्राथमिकता के मुद्दे को हल करने के लिए एक और संभावना कस्टम इंफिक्स ऑपरेटरों के लिए एक सिंटैक्स का उपयोग करना है जिसमें किसी प्रकार के कोष्ठक शामिल हैं, जैसे (a f b) ।

संबंधित चर्चा: https://github.com/JuliaLang/julia/issues/554 , https://github.com/JuliaLang/julia/issues/5571 , https://github.com/JuliaLang/julia/pull/14476 , https://github.com/JuliaLang/julia/issues/11608 , और https://github.com/JuliaLang/julia/issues/15612।

मुझे पूछना चाहिए - lpad<|10, x|>sin|>exp से अधिक "ASCII सलाद" कैसा है? फिर भी |> संकेतन जोड़ा गया।

मुझे लगता है कि @tkelman तर्क देता है

हमें मौजूदा से छुटकारा पाना चाहिए |>।

आंशिक रूप से क्योंकि _both_ lpad<|10 और x|>sin|>exp ASCII-सलाद क्षेत्र में उद्यम :)।

मुझे लगता है कि @toivoh का (a f b) अनिवार्य माता-पिता के साथ, अब तक का सबसे अच्छा प्रस्ताव है।

https://github.com/JuliaLang/julia/issues/11608 से संबंधित (और इस प्रकार https://github.com/JuliaLang/julia/issues/4882 और https://github.com/JuliaLang/julia/pull भी /14653): यदि (a f b) => f(a,b) , तो यह समझ में आता है यदि (a <strong i="8">@m</strong> b) => (<strong i="10">@m</strong> a b) । यह मौजूदा विशेष केस मैक्रो लॉजिक को y ~ a*x+b के लिए सामान्य (और इस प्रकार अधिक पारदर्शी) (y @~ a*x+b) $ के साथ बदलने की अनुमति देगा।

साथ ही, संक्षिप्त इन्फिक्स परिभाषाओं के लिए "आवश्यक माता-पिता" पसंदीदा मुहावरा हो सकता है। कहने के बजाय (एक बेवकूफ उदाहरण का उपयोग करने के लिए) a + b = string(a) * string(b) , आपको (a + b) = string(a) * string(b) कहने के लिए प्रोत्साहित किया जाएगा (लिंट टूल्स, या कंपाइलर चेतावनियों द्वारा)। मुझे एहसास है कि यह वास्तव में इंफिक्स के लिए "पैरेंस आवश्यक" विकल्प चुनने का प्रत्यक्ष परिणाम नहीं है, लेकिन यह एक सुविधाजनक मुहावरा है जो हमें एलएचएस पर इंफिक्स का उपयोग करने वाले लोगों को गलती से चेतावनी देने की अनुमति देगा लेकिन इसे करने वाले लोगों को हटा देगा प्रयोजन।

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

और हमारे पास यूनिकोड का उपयोग करके परिभाषित इंफिक्स ऑपरेटरों के लिए समर्थन है।
चूंकि https://github.com/JuliaLang/julia/issues/552

मुझे लगता है कि यह अच्छा हो सकता है कि इसे बढ़ाया जाए ताकि आप खोजशब्दों को मूल सुझाव के रूप में जोड़ सकें।
तो हम, उदाहरण के लिए, 1 ⊕₂ 1 == 0 . प्राप्त कर सकते थे
आपके इन्फिक्स के लिए मनमाना नाम रखने में सक्षम होना थोड़ा अधिक लगता है।

एक ऑपरेटर की तरह दिखना और कार्य करना चाहिए।

मैं सहमत हूं कि इंफिक्स ऑपरेटरों के लिए मजबूत नामकरण परंपराएं होनी चाहिए। उदाहरण के लिए: यूनिकोड का एक वर्ण, या एक पूर्वसर्ग में समाप्त होता है। लेकिन वे ऐसे सम्मेलन होने चाहिए जो व्यवस्थित रूप से विकसित हों, न कि संकलक द्वारा लागू की गई आवश्यकताएं। निश्चित रूप से, मुझे नहीं लगता कि #552 कहानी का अंत है; यदि दर्जनों हार्ड-कोडेड ऑपरेटर हैं, तो अधिक प्रोग्रामेटिक रूप से जोड़ने का एक तरीका होना चाहिए, यदि केवल नई सुविधाओं को प्रोटोटाइप करने के लिए।

...

मेरे लिए, (a f b) (और (a <strong i="10">@m</strong> b) ) प्रस्ताव इस बग में बाकी प्रस्तावों से ऊपर है। मैं लगभग एक पैच बनाने के लिए ललचा रहा हूँ।

(a f b) => f(a,b)
(a f b c d) => f(a,b,c,d)
(a f) =>वाक्यविन्यास त्रुटि
(a+2 f+2 b+2) => (f+2)(a+2,b+2)
(t1=a t2=f t3=b) => (t1=f)((t2=a),(t3=b)) (मैक्रोज़ की तरह अंतरिक्ष में न्यूनतम संभव प्राथमिकता है)

...

क्या मेरे लिए पैच सबमिट करना अनुचित होगा?

मैं पिछले दो मामलों को समझ नहीं पाया:

(a+2 f+2 b+2)=>(f+2)(a+2,b+2)
(t1=a t2=f t3=b)=>(t1=f)((t2=a),(t3=b))

मुझे (a f b c d) सिंटैक्स बहुत अजीब लगता है। चूँकि 1 + 2 + 3 को +(1,2,3) के रूप में लिखा जा सकता है तो क्या f(a,b,c) को (a f b f c) के रूप में नहीं लिखा जाना चाहिए?

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

मैं (a f b c d) के साथ दो समस्याएं देख सकता हूं।

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

दूसरा, यह चीजों को अच्छी तरह से करने के लिए कोई रास्ता नहीं छोड़ता है जैसे इसे मौलिक रूप से बनाना। मेरी समझ यह है कि f.(a,b) 0.5 में एक अंकन होने जा रहा है ताकि f प्रसारण के साथ अपने तर्कों पर तत्व के अनुसार संचालित हो सके। इंफिक्स नोटेशन के साथ ऐसा करने का कोई साफ तरीका नहीं होगा, अगर यह (a f b) है। सबसे अच्छा, इसे (a .f b) होना चाहिए, जो मेरे विचार में समरूपता की सुंदरता खो देता है जो .( .+ और .* के साथ प्रदान करता है।

उदाहरण के लिए, हास्केल से उदाहरण का उपयोग करने के मामले की तुलना करें। #6946 पर शशि ने वह बिंदु बनाया जिसका यहाँ समकक्ष है। हास्केल में, आप circle 10 |> move 0 0 |> animate "scale" "ease" लिखेंगे। इस संकेतन का उपयोग करके, यह ((circle(10) move 0 0) animate "scale" "ease") हो जाता है, जो कि animate(move(circle(10),0,0),"scale","ease") से अधिक स्पष्ट नहीं है। और यदि आप |> नोटेशन का उपयोग करके अपनी मंडली को कई स्थानों पर कॉपी करना चाहते हैं, तो आपके पास circle 10 .|> copy [1 15 50] [3 14 25] हो सकता है। मेरे विचार में, यह विचार को लागू करने का सबसे साफ तरीका है - और फिर, कोष्ठक ऑपरेशन के मुद्दों के क्रम से निपटने की अपनी सामान्य भूमिका निभाते हैं।

और जैसा कि मैंने बताया है, a|>f b c में एक प्राकृतिक विस्तार होने का भी लाभ है जिससे समान नोटेशन का अधिक उपयोग हो सकता है - f b c "फ़ंक्शन f के साथ पार्स करेगा पैरामीटर b और c सेट), और इस प्रकार i->f(i,b,c) के बराबर होगा। यह इसे न केवल इंफिक्सिंग के लिए काम करने की अनुमति देता है, बल्कि अन्य स्थितियों के लिए जहां आप पास करना चाहते हैं पैरामीटर के साथ एक फ़ंक्शन (विशेष रूप से एक इनबिल्ट फ़ंक्शन) (यह ध्यान में रखते हुए कि मानक फ़ंक्शन का ऑब्जेक्ट पहले होना है)।

|> यह भी स्पष्ट करता है कि कौन सा कार्य है। यदि आपके पास, कहें, (tissue wash fire dirty metal) , तो एक नज़र में, wash को फ़ंक्शन के रूप में पहचानना काफी कठिन होगा। दूसरी ओर, tissue|>wash fire dirty metal का एक बड़ा संकेतक है जो कह रहा है " wash फ़ंक्शन है"।

कुछ नवीनतम आपत्तियां मुझे यह कहने की तरह लगती हैं "लेकिन आप इस सुविधा का दुरुपयोग कर सकते हैं!" मेरी प्रतिक्रिया है: बेशक आप कर सकते थे। यदि आप चाहें तो मैक्रोज़ का उपयोग करके आप पहले से ही पूरी तरह से अपठनीय कोड लिख सकते हैं। पार्सर का काम वैध उपयोगों को सक्षम करना है; गालियों को रोकने के लिए, हमारे पास परंपराएं/मुहावरे हैं और कुछ मामलों में परिसीमन करने वाले हैं। विशेष रूप से:

मैं पिछले दो मामलों को समझ नहीं पाया:

ये किसी भी तरह से अनुसरण करने के लिए एक उदाहरण बनने के लिए नहीं हैं; वे केवल पूर्वता नियमों के स्वाभाविक परिणाम दिखा रहे हैं। मुझे लगता है कि पिछले दो उदाहरण वाक्य रचना के दुरुपयोग के रूप में योग्य होंगे, हालांकि (a^2 ಠ_ಠ b^2) => ಠ_ಠ(a^2,b^2) पर्याप्त स्पष्ट है।

f(a,b,c) को (afbfc) के रूप में नहीं लिखा जाना चाहिए

(a f b c d) का मेरा प्रस्ताव, स्पष्ट रूप से, एक बाद का विचार था। मुझे लगता है कि यह समझ में आता है, और मैं उदाहरणों के साथ आ सकता हूं जहां यह उपयोगी है, लेकिन अगर यह विवादास्पद है तो मैं इस मुद्दे पर इस प्रस्ताव को लटकाना नहीं चाहता।

[उदाहरण के लिए:

• f किसी ऑब्जेक्ट की "ऑब्जेक्ट विधि" है, शायद जटिल, बी, सी, और डी का उपयोग करके, शायद सरल।
• f एक "स्वाभाविक रूप से प्रसारित" विधि है जैसे push! ]

जबकि (a f b f c) समझ में आता है अगर f + की तरह थे, मुझे लगता है कि अधिकांश ऑपरेटर वास्तव में + की तरह नहीं हैं, इसलिए यह हमारा मॉडल नहीं होना चाहिए।

जब आपके पास अधिक जटिल अभिव्यक्ति हो तो इसे पढ़ना मुश्किल होगा

दोबारा, मेरा जवाब होगा, "तो इसका दुरुपयोग न करें"।

मान लें कि हम f a / (b + f(c,d^e)) जैसी जटिल अभिव्यक्ति लिखने का कोई तरीका चाहते हैं। @toivoh के प्रस्ताव में, वह a / (b + (c f d^e)) होगा। हास्केल-जैसे उपयोग में, यह a / (b + (c |> f d^e)) या "सर्वश्रेष्ठ" होगा, यदि |> इस एक विशेष उदाहरण को ठीक करने के लिए पूर्वता बदल दी गई थी, a / (b + c |> f d^e) । मुझे लगता है कि @toivoh यहां आसानी से उतना ही अच्छा है।

(tissue wash fire dirty metal)

मुझे लगता है कि इसका समाधान इंफिक्स ऑपरेटरों के लिए मजबूत नामकरण परंपराएं हैं। उदाहरण के लिए, यदि कोई परंपरा थी कि इंफिक्स ऑपरेटरों को यूनिकोड का एक वर्ण होना चाहिए, या एक पूर्वसर्ग या अंडरस्कोर में समाप्त होना चाहिए, तो उपरोक्त (tissue wash_ fire dirty metal) जैसा कुछ होगा जो उतना ही स्पष्ट है जितना कि अभिव्यक्ति कभी भी होने की उम्मीद कर सकती है .

...

तत्व अनुसार

यह एक वाजिब चिंता है। (a .f b) एक बुरा विचार है, क्योंकि इसे ((a.f) b) के रूप में पढ़ा जा सकता है। मेरा पहला सुझाव (a ..f b) है लेकिन यह मुझे बहुत खुश नहीं करता है।

circle 10 |> move 0 0 |> animate "scale" "ease"

मैंने jQuery का उपयोग किया है, इसलिए मुझे निश्चित रूप से इस तरह फ़ंक्शन चेनिंग का लाभ दिखाई देता है। लेकिन मुझे लगता है कि यह इंफिक्स ऑपरेटरों के समान मुद्दा नहीं है। (a f b) प्रस्ताव का उपयोग करके, आप उपरोक्त को इस प्रकार लिख सकते हैं:

circle 10 |> (move <| 0 0) |> (animate <| "scale" "ease")

... जो हास्केल संस्करण के रूप में काफी संक्षिप्त नहीं है, लेकिन फिर भी बहुत पठनीय है।

शायद यह () के अंदर केवल तीन चीजों तक सीमित हो सकता है:
(a f (b,c))
.(a f (b,c)) ऑपरेटर का उपयोग कर .(

अंत में, सामान्य बिंदु की प्रतिक्रिया:

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

जाहिर है हम सभी अपनी राय के हकदार हैं। (मैं स्पष्ट नहीं हूं कि क्या थम्स-अप टिप्पणी के उस हिस्से को संदर्भित करता है, लेकिन यदि ऐसा है, तो यह तीन गुना हो जाता है।)

लेकिन मेरे प्रतिवाद हैं:

• जूलिया के पास पहले से ही दर्जनों इंफिक्स ऑपरेटर हैं, जिनमें से कई बेहद विशिष्ट हैं। यह अपरिहार्य है कि अधिक प्रस्तावित किया जाएगा। जब कोई कहता है, "आपके पास ⅋ कैसे हो सकता है, लेकिन § नहीं?", तो मैं जवाब देना चाहूंगा कि "इसे स्वयं करें" और "प्रतीक्षा करें जब तक कि अगले संस्करण को व्यापक रूप से अपनाया न जाए"।
• (a § b) जैसा कुछ प्रमुख रूप से पठनीय है, और सिंटैक्स एक या दो उदाहरणों से सीखने के लिए पर्याप्त हल्का है।
• मैं इस मुद्दे को उठाने वाला पहला व्यक्ति नहीं हूं, और मैं अंतिम नहीं रहूंगा। मैं समझता हूं कि भाषा डिजाइनरों को रेंगने (गलत) सुविधाओं पर बहुत संदेह होना चाहिए, क्योंकि एक बार जब आप एक बदसूरत विशेषता जोड़ते हैं तो बाद में इसे ठीक करना मूल रूप से असंभव है। लेकिन जैसा कि मैंने ऊपर कहा, मुझे लगता है कि (a f b) इतना साफ है कि आपको इसका पछतावा नहीं होगा।

मैं वास्तव में (a f b) . की स्पष्टता के बारे में निश्चित नहीं हूँ

यहां एक संभावित उपयोग-मामला है:
select((((:emp_id, :last_name) from employee_tbl) where (:city, == ,'indianapolis')) orderby :emp_id));

यह निश्चित रूप से इंफिक्स फ़ंक्शंस का व्यवहार्य उपयोग है।
select फ़ंक्शन या तो पहचान फ़ंक्शन है, या डेटाबेस को निर्मित क्वेरी भेजता है।

क्या यह स्पष्ट कोड है?
मैं बस नहीं जानता।

.(a f b)

हाँ, यह समझ में आता है। लेकिन यह बहुत पठनीय नहीं है।

क्या (a @. f b) अधिक पठनीय है? क्योंकि @. मैक्रो को सक्षम करने के लिए यह एक साधारण वन-लाइनर होगा।

[[[इसके बारे में सोचें, अगर हमने माता-पिता की आवश्यकता के बिना इंफिक्स मैक्रोज़ की अनुमति दी है, तो @ ग्लेन-ओ उन्हें वह करने के लिए इस्तेमाल कर सकता है जो वह चाहता है: circle(10) @> move 0 0 @> animate "scale" "ease" => @> (@> circle(10) move 0 0) animate "scale" "ease" =macro> animate(move(circle(10),0,0),"scale","ease") । मुझे लगता है कि समाधान (a f b) से अधिक बदसूरत है, लेकिन कम से कम यह मेरी नजर में इस समग्र बग को हल करेगा।]]]

...

select((((:emp_id, :last_name) from employee_tbl) where (:city, = ,'indianapolis')) orderby :emp_id);

मैं निश्चित रूप से "कहां" के लिए मैक्रो का उपयोग करूंगा ताकि सशर्त अभिव्यक्ति को अजीब तरह से उद्धृत न करना पड़े। इसलिए:

select((((:emp_id, :last_name) from employee_tbl) <strong i="22">@where</strong> city == 'indianapolis') orderby :emp_id);

माता-पिता हल्के से परेशान हैं, लेकिन दूसरी तरफ मुझे पार्सर के बिना इस तरह की अभिव्यक्ति से निपटने का कोई उचित तरीका नहीं दिखता है।

select((((:emp_id, :last_name) from employee_tbl) <strong i="6">@where</strong> city == 'indianapolis') orderby :emp_id);

माता-पिता हल्के से परेशान हैं, लेकिन दूसरी तरफ मुझे पार्सर के बिना इस तरह की अभिव्यक्ति से निपटने का कोई उचित तरीका नहीं दिखता है।

दूसरे विचार पर, उस अभिव्यक्ति में पूर्वता दाएं से बाएं है। तो, इंफिक्स मैक्रोज़ का उपयोग करके, यह भी हो सकता है:

select((:emp_id, :last_name) <strong i="11">@from</strong> employee_tbl <strong i="12">@where</strong> city == 'NYC' <strong i="13">@orderby</strong> :emp_id)

या और भी:

<strong i="17">@select</strong> (:emp_id, :last_name) <strong i="18">@from</strong> employee_tbl <strong i="19">@where</strong> city == 'NYC' <strong i="20">@orderby</strong> :emp_id

इसलिए जबकि मुझे अभी भी पसंद है (a f b) , मुझे लगने लगा है कि इंफिक्स मैक्रोज़ भी एक अच्छा जवाब है।

यहां उदाहरणों के माध्यम से पूरा प्रस्ताव दिया गया है, इसके बाद फायदे और नुकसान हैं:

मुख्य उपयोग:

• a <strong i="28">@m</strong> b => <strong i="30">@m</strong> a b
• a <strong i="33">@m</strong> b c => <strong i="35">@m</strong> a b c
• a <strong i="38">@m</strong> b <strong i="39">@m2</strong> c => <strong i="41">@m2</strong> (<strong i="42">@m</strong> a b) c
• <strong i="45">@defineinfix</strong> f; a <strong i="46">@f</strong> b => macro f(a,b...) :(f($a,$b...)) end; <strong i="48">@f</strong> a b => f(a,b)

कोने के मामले: (अच्छा कोड होने का इरादा नहीं है, बस यह दिखाने के लिए कि पार्सर कैसे काम करेगा)

• t1=a <strong i="54">@m</strong> t2=b t3=c => <strong i="56">@m</strong> t1=a t2=b t3=c (हालांकि यह अच्छी प्रोग्रामिंग शैली नहीं है)
• t1 + a <strong i="59">@m</strong> t2 + b => <strong i="61">@m</strong> t1+a t2+b (हालांकि यह अच्छी प्रोग्रामिंग शैली नहीं है)
• a b <strong i="64">@m</strong> c => सिंटैक्स त्रुटि (??)
• a <strong i="67">@m</strong> b [c,d] => कृपया न करें, लेकिन <strong i="70">@m</strong> a b[c,d] (ETA: नहीं, पैच के साथ यह <strong i="72">@m</strong> a b ([c,d]) के रूप में सामने आता है जो शायद बेहतर है।)
• a <strong i="75">@m</strong> b ([c,d]) => <strong i="77">@m</strong> a b ([c,d])
• [a <strong i="80">@m</strong> b] => खराब शैली, कृपया स्पष्ट करने के लिए कोष्ठक का उपयोग करें, लेकिन [a (<strong i="83">@m</strong> b)] (??)
• a @> f b => @> a f b => f(a,b)
• <strong i="90">@outermacro</strong> a b <strong i="91">@m</strong> c d => <strong i="93">@outermacro</strong> a (<strong i="94">@m</strong> b c d)

लाभ:

• इंफिक्स मैक्रोज़ को परिभाषित करें, इंफिक्स फ़ंक्शन मुफ्त में प्राप्त करें (मैक्रो मूल्यांकन के एक बार के ओवरहेड के साथ। यह पार्सर जादू के रूप में काफी कम-ओवरहेड नहीं है, लेकिन हर मूल्यांकन में अतिरिक्त फ़ंक्शन कॉल करने से कहीं बेहतर है)
• शक्तिशाली DSL को जन्म दे सकता है, जैसा कि ऊपर SQL जैसे उदाहरण में देखा गया है
• एक अलग |> ऑपरेटर की आवश्यकता को हटा देता है, क्योंकि यह एक-लाइनर मैक्रो है। इसी तरह <| और @Glen-O के बाकी प्रस्तावों के लिए।
• (a f b) . के विपरीत, स्पष्ट, दुर्घटना द्वारा उपयोग किए जाने का बहुत कम जोखिम
• जैसा कि दिखाया गया है, @defineinfix मैक्रो मैक्रो के बजाय कार्यों के लिए शॉर्टहैंड उपयोग की अनुमति दे सकता है।

(मामूली) नुकसान:

• आरटीओएल के साथ ज्यादातर मामलों में प्राथमिकता और समूहीकरण अच्छी तरह से काम करता प्रतीत होता है, लेकिन ऐसे अपवाद होंगे जिनके लिए माता-पिता की आवश्यकता होगी।
• मुझे लगता है कि a @> f b या यहां तक ​​कि a <strong i="112">@f</strong> b (a f b) जितना पढ़ने योग्य नहीं है (हालांकि वे बहुत भयानक भी नहीं हैं।)

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

गतिविधि की वह मात्रा आम तौर पर अनुपात से बाहर होती है

मुझे माफ कर दो। मैं शायद आगे-पीछे होने का दोषी हूं।

दूसरी ओर, मुझे लगता है कि इस धागे ने स्पष्ट रूप से "उपयोग करने योग्य" प्रगति की है। नवीनतम सुझावों में से कोई भी (a f b) या [ a @> f b , जिसमें a <strong i="10">@f</strong> b एक शॉर्टकट के रूप में निश्चित है] मेरे विचार में पहले के सुझावों जैसे a %f% b या a |> f <| b ।

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

...

ईटीए: मुझे लगता है कि यह चर्चा अब decision टैग पाने के लिए पर्याप्त परिपक्व हो गई है।

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

select((((:emp_id, :last_name) from employee_tbl) where (:city, == ,"indianapolis")) orderby :emp_id));

बेहतर लिखा है

sql"SELECT emp_id, last_name FROM employee_tbl WHERE city == 'indianapolis' ORDER BY emp_id"

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

और इस मामले में मुझे लगता है कि परिणाम किसी भी इंफिक्स ऑपरेशन की तुलना में बहुत साफ है जिसे परिभाषित किया जा सकता है।
हालांकि इसमें अपना खुद का माइक्रोपार्सर/टोकनाइज़र लिखने का ओवरहेड होता है।

मुझे वास्तव में निर्णय टैग की आवश्यकता नहीं दिख रही है।
पीआर के रूप में इसका कोई कार्यान्वयन नहीं है, न ही कोई प्रयोग करने योग्य प्रोटोटाइप।
जिससे लोग इसका परीक्षण कर सकें।
इसके 8 प्रयोग करने योग्य प्रोटोटाइप के साथ https://github.com/JuliaLang/julia/issues/5571#issuecomment -205754539 के विपरीत

हर बार जब मैं धागा पढ़ता हूं तो इसके प्रति मेरा अनुभव ऊपर और नीचे जाता है। मुझे नहीं लगता कि मैं वास्तव में तब तक जान पाऊंगा जब तक मैं कोशिश नहीं करता। और अभी मैं यह भी नहीं जानता कि मैं इसका क्या उपयोग करूंगा। ( |> और <| की कुछ परिभाषाओं के विपरीत जिनका मैंने F# में उपयोग किया है)

SQL जैसा सिंटैक्स, नौकरी के लिए सही उपकरण गैर-मानक स्ट्रिंग लिटरल्स है

एसक्यूएल एनएसएल के साथ सबसे अच्छा किया जाता है या नहीं, मुझे लगता है कि डीएसएल का एक स्तर है जो इतना जटिल है कि इनलाइन मैक्रोज़ बहुत मददगार होंगे, लेकिन इतना जटिल नहीं है कि यह आपके खुद के माइक्रोपार्सर/टोकनाइज़र लिखने लायक है।

अभी मैं यह भी नहीं जानता कि मैं इसका क्या उपयोग करूंगा। (|> और <| के लिए कुछ परिभाषाओं के विपरीत जिनका मैंने F# में उपयोग किया है)

इनलाइन मैक्रो प्रस्ताव लोगों को, अन्य बातों के अलावा, अपने स्वयं के |> -जैसे या <| -जैसे मैक्रो रोल करने में सक्षम करेगा, ताकि आप इसे F# में जो कुछ भी किया है उसके लिए उपयोग कर सकें।

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

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

मैंने पहले पूछा था कि क्या मेरे लिए एक पार्सर पैच बनाना उचित है, और किसी ने उत्तर नहीं दिया। उस पर अब तक केवल एक ही शब्द है:

मुझे नहीं लगता कि जूलिया 1.0 से पहले "वाक्य रचनात्मक नवाचार" के रास्ते में बहुत कुछ होगा।

जो अब एक पैच बनाने के खिलाफ बहस करने लगता है, क्योंकि यह बस बैठ सकता है और थोड़ा सड़ सकता है। हालाँकि, अब आप कह रहे हैं कि यह इस पर निर्णय लेने के लायक नहीं है (अभी निर्णय न लेने के निर्णय सहित?) जब तक हमारे पास "पीआर [या] प्रयोग करने योग्य प्रोटोटाइप के रूप में कार्यान्वयन" नहीं है।

इसका क्या मतलब है? (पीआर क्या है?) क्या कोई मैक्रो जो '@' के बजाय @ वर्ण का उपयोग करता है वह काम करेगा, ताकि <strong i="22">@testinline</strong> a '@'f b => @f(a, b) ? या मुझे julia-parser.scm पर पैच सबमिट करना चाहिए? (मैंने वास्तव में इस तरह के एक पैच को लिखना शुरू कर दिया है, और ऐसा लगता है कि यह सरल होना चाहिए, लेकिन मेरी योजना बहुत जंग लगी है।) क्या मुझे टेस्ट केस बनाने की ज़रूरत है?

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

"एक पीआर [या] प्रयोग करने योग्य प्रोटोटाइप के रूप में कार्यान्वयन" द्वारा।
मेरा मतलब कुछ ऐसा है जिसके साथ खेला जा सकता है।
तो यह देखा जा सकता है कि व्यवहार में कैसा लगता है।

एक पीआर एक पुल अनुरोध है, इसलिए पैच वह शब्द है जिसका आप उपयोग कर रहे हैं।

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

जैसे यह मेरी कॉल नहीं है, लेकिन मुझे संदेह है कि मैं बिना किसी चीज के अपनी राय बना सकता हूं जिसके साथ मैं खेल सकता हूं।

साथ ही बाइक शेडिंग को आगे-पीछे न करने के लिए +1 करें।

...या शायद मैक्रोज़ और गैर-मानक स्ट्रिंग अक्षर के साथ एक Infix.jl पैकेज।

हम निश्चित रूप से इस बातचीत में "वर्किंग कोड या जीटीएफओ" बिंदु पर पहुंच गए हैं।

ठीक है, यहां काम करने वाला कोड है: https://github.com/jamesonquinn/JuliaParser.jl

ईटीए: क्या मुझे एक विशिष्ट प्रतिबद्धता का संदर्भ देना चाहिए, या नवीनतम मास्टर के लिए उपरोक्त लिंक ठीक है?

...

(इसमें कोई भी सुविधा मैक्रो नहीं है जिसकी मुझे उम्मीद है कि आप चाहते हैं, जैसे कि |> , <| , ~ , और @defineinfix के समकक्ष। ऊपर दिए गए मेरे उदाहरण से ~ या |> ऑपरेटर के लिए अब बेकार विशेष केस लॉजिक _deprecate_ को हटाता है। इसे काम करने के लिए यह सिर्फ पार्सर परिवर्तन है। मैंने बुनियादी कार्यक्षमता का परीक्षण किया लेकिन सभी कोने के मामलों में नहीं।

...

मुझे लगता है कि ~ के साथ मौजूदा बदसूरत हैक से पता चलता है कि इस तरह की चीज़ के लिए एक स्पष्ट उपयोग मामला है। इस पैच का उपयोग करते हुए, आप कहेंगे @~ जब आपको मैक्रो व्यवहार की आवश्यकता होगी; बहुत साफ, बिना किसी विशेष मामले के। या क्या कोई गंभीरता से मानता है कि ~ पूरी तरह से अद्वितीय है और कोई भी इसे फिर कभी नहीं करना चाहेगा?

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

पैच जैसा कि यह खड़ा है, एक ब्रेकिंग परिवर्तन नहीं है, लेकिन मुझे उम्मीद है कि अगर यह योजना बन जाती है तो अगला कदम वर्तमान में मौजूद ~ और |> को हटा देना होगा, जो अंततः नेतृत्व करेगा परिवर्तन तोड़ना।

...

कुछ सरल परीक्षण जोड़े गए।

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

मैक्रोज़ अब तकनीकी रूप से सामान्य हैं, लेकिन उनके इनपुट तर्क हमेशा Expr , Symbol या शाब्दिक होते हैं। इसलिए वे पैकेज में परिभाषित नए प्रकारों के लिए वास्तव में एक्स्टेंसिबल नहीं हैं जिस तरह से फ़ंक्शंस (इन्फिक्स या अन्यथा) हैं। इंफिक्स मैक्रोज़ के लिए संभावित उपयोग के मामलों को प्रीफ़िक्स-एनोटेट मैक्रो डीएसएल या स्ट्रिंग लिटरल्स द्वारा बेहतर ढंग से प्रस्तुत किया जाता है।

(क्षमा करें, मैंने समय से पहले पोस्ट किया था, अभी तय किया गया है।)

#11608 में, मुझे कई नकारात्मक तर्क दिखाई देते हैं:

===

निम्नलिखित में क्या रूपांतरित होगा?
...
y = 0.0 @in@ x == 1.0 ? 1 @in@ 2 : 3 @in@ 4

यह धागे में निपटाया गया था:

इस तरह के मामले इसलिए मैं हमेशा कोष्ठक का उपयोग करता हूं ...

तथा

वही मिसाल ... मैक्रो के बिना लागू: 0.0 in 1 == 1.0 ? 2 in 2 : 3 in 4

===

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

जिसका (आंशिक रूप से) उत्तर दिया गया है (और दूसरा) यहां द्वारा:

"पार्सर डेवलपर्स के लिए सिरदर्द" सबसे कम संभव चिंता है।

===

क्या एक ही मैक्रो-ऑपरेटर के लिए 2 पैकेजों के साथ-साथ परिभाषाएं रखने का कोई तरीका नहीं है जिसे एक उपयोगकर्ता कोड बेस में स्पष्ट रूप से एक साथ उपयोग किया जा सकता है?

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

फिर भी, यह किसी भी मैक्रो के लिए उतना ही बड़ा मुद्दा है। यदि दो पैकेज दोनों मैक्रो निर्यात करते हैं, तो आपके पास "उपयोग" दोनों के साथ बस नहीं हो सकता है।

क्या यह इंफिक्स मैक्रोज़ के साथ अधिक समस्या होने की संभावना है? खैर, यह इस बात पर निर्भर करता है कि लोग उनका उपयोग किसके लिए करते हैं:

• उपयोगकर्ता द्वारा परिभाषित इंफिक्स फ़ंक्शन करने का एक तरीका। उस स्थिति में, वे किसी भी अन्य कार्य से बदतर नहीं हैं; प्रेषण ठीक काम करता है।
• अन्य प्रोग्रामिंग शैलियों का उपयोग करने के तरीके के रूप में, |> और <| जैसे ऑपरेटरों का उपयोग करके @ ग्लेन-ओ ऊपर चर्चा करता है। उस स्थिति में, मुझे लगता है कि टकराव की बहुत कम संभावना के साथ मैक्रो का क्या अर्थ है, इसके बारे में सामान्य सम्मेलनों को जल्दी से विकसित किया जाएगा।
• विशेष-उद्देश्य वाले DSL बनाने के तरीके के रूप में, ऊपर दिए गए SQL उदाहरण की तरह। मुझे लगता है कि इनका उपयोग विशिष्ट संदर्भों में किया जाएगा और टक्कर की संभावना बहुत खराब नहीं है।
• आर की ~ जैसी चीजों के लिए। सबसे पहले, यह सबसे अधिक समस्याग्रस्त दिखता है; आर में, ~ कई अलग-अलग चीजों के लिए उपयोग किया जाता है। हालाँकि, मुझे लगता है कि वहाँ भी, यह प्रबंधनीय है, कुछ इस तरह से:

macro ~(a,b) :(~(:$a, quote($b))) end

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

(नोट: उपरोक्त संपादित किया गया है। प्रारंभ में, मैंने सोचा था कि a ~ b + c b और c के बंधन का उपयोग R के आलसी मूल्यांकन के माध्यम से किया था। लेकिन ऐसा नहीं है। टी; b और c स्पष्ट रूप से पारित डेटा फ्रेम में कॉलम के नाम हैं, स्थानीय दायरे में चर के नाम नहीं हैं जो इस प्रकार निहित रूप से पारित होते हैं।)

===

यहां आगे बढ़ने का एकमात्र तरीका वास्तविक कार्यान्वयन विकसित करना होगा।

जो मैंने किया है।

===

मैक्रोज़ अब तकनीकी रूप से सामान्य हैं, लेकिन उनके इनपुट तर्क हमेशा एक्सप्र, सिंबल या शाब्दिक होते हैं। इसलिए वे पैकेज में परिभाषित नए प्रकारों के लिए वास्तव में एक्स्टेंसिबल नहीं हैं जिस तरह से फ़ंक्शंस (इन्फिक्स या अन्यथा) हैं।

यह उपरोक्त बिंदु से संबंधित है। एक इंफिक्स मैक्रो के रूप में एक विशिष्ट फ़ंक्शन को कॉल करता है, वह फ़ंक्शन अभी भी सामान्य तरीके से प्रेषण के माध्यम से एक्स्टेंसिबल है। जहां तक ​​यह एक विशिष्ट कार्य को कॉल नहीं करता है, यह कुछ संरचनात्मक/वाक्यविन्यास कर रहा है (जैसे कि |> अब क्या करता है) जिसे बढ़ाया या फिर से परिभाषित नहीं किया जाना चाहिए। ध्यान दें कि भले ही यह किसी फ़ंक्शन को कॉल करता हो, यह तथ्य कि यह एक मैक्रो है, अभी भी उपयोगी हो सकता है; उदाहरण के लिए, यह अपने कुछ तर्कों को उद्धृत कर सकता है, या उन्हें कॉलबैक में संसाधित कर सकता है, या यहां तक ​​​​कि नाम और एक चर के बंधन के साथ एक साथ बातचीत कर सकता है, इस तरह से एक प्रत्यक्ष फ़ंक्शन कॉल नहीं कर सकता है।

===

इंफिक्स मैक्रोज़ के लिए संभावित उपयोग के मामलों को प्रीफ़िक्स-एनोटेट मैक्रो डीएसएल या स्ट्रिंग लिटरल्स द्वारा बेहतर ढंग से प्रस्तुत किया जाता है।

जैसा कि संदर्भित सूत्र में बताया गया था:

[इन्फिक्स] पार्स करना आसान है (अंग्रेजी और अधिकांश पश्चिमी वक्ताओं के लिए), क्योंकि हमारी भाषा उसी तरह काम करती है। (यही बात आम तौर पर ऑपरेटरों के लिए होती है।)

उदाहरण के लिए, जो अधिक पठनीय (और लिखने योग्य) है:

select((:emp_id, :last_name) <strong i="8">@from</strong> employee_tbl <strong i="9">@where</strong> city == 'NYC' <strong i="10">@orderby</strong> :emp_id)

या

send(orderby((<strong i="14">@where</strong> selectfrom((:emp_id, :last_name), employee_tbl) city == 'NYC'), :emp_id))

?

===

आखिरकार:

11608 को स्पष्ट सहमति के साथ बंद किया गया था

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

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

मैं इंफिक्स मैक्रोज़ ( a <strong i="6">@m</strong> b => <strong i="8">@m</strong> a b ) के पक्ष में बहस कर रहा हूँ। इसका मतलब यह नहीं है कि मुझे विपक्ष के तर्कों की जानकारी नहीं है। यहां बताया गया है कि मैं इसके खिलाफ सबसे अच्छे तर्क का सारांश कैसे दूंगा:

भाषा सुविधाएँ -100 से शुरू होती हैं। इंफिक्स मैक्रोज़ क्या पेशकश करते हैं जो संभवतः उस पर काबू पा सकते हैं? उनके स्वभाव से, ऐसा कुछ भी नहीं है जिसे आप इंफिक्स मैक्रोज़ के साथ पूरा कर सकते हैं जो उपसर्ग मैक्रोज़ के साथ पूरा नहीं किया जा सकता है।

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

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

हां, अस्पष्ट कोड लिखने के लिए इंफिक्स मैक्रोज़ का उपयोग किया जा सकता है। लेकिन मौजूदा उपसर्ग मैक्रोज़ के दुरुपयोग की संभावना उतनी ही है। यदि दुरुपयोग नहीं किया जाता है, तो इंफिक्स मैक्रोज़ अधिक स्पष्ट कोड प्रदान कर सकते हैं।

• (a+b <strong i="18">@choose</strong> b) धड़कता है binomial(a+b,b) ;
• score ~ age + treatment धड़कता है linearDependency(:score, :(age + treatment)) ;
• domSelect("#logo") @| css "color" "red" @| fadeIn "slow" <strong i="25">@thenApply</strong> addClass "dummy" पवित्र नरक को addOneTimeEventListener(fadeIn(css(domSelect("#logo"),"color","red"),"slow"),"done",(obj,evt)->addClass(obj,"dummy")) से हरा देता है।

मुझे एहसास है कि ये सिर्फ खिलौने के उदाहरण हैं लेकिन मुझे लगता है कि सिद्धांत मान्य है।

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

अज्ञात अज्ञात से ज्ञात अज्ञात में ले जाने के लिए इसे कुछ चीजों की आवश्यकता होती है। और दुर्भाग्य से, ऐसा करने के लिए कोई तंत्र नहीं है। आपके तर्कों को एक संरचना की आवश्यकता है जो मौजूद नहीं है।

अब जबकि <| राइट-एसोसिएटिव (#24153) है, तो क्या शुरुआती a |>op<| b प्रस्ताव काम करता है?

मैंने स्टीवन द्वारा https://github.com/JuliaLang/julia/pull/24404#issuecomment -341570934 में उल्लिखित हैक के लिए एक पैकेज बनाया है:

• https://github.com/Ismael-VC/InfixFunctions.jl

मैं नहीं जानता कि यह कितने संभावित इंफिक्स ऑपरेटरों को प्रभावित करता है, लेकिन मैं वास्तव में <~ का उपयोग करना चाहूंगा। पार्सर सहयोग नहीं करेगा - भले ही मैं चीजों को ध्यान से रखता हूं, यह a <~ b का अर्थ a < (~b) चाहता है।

<- में भी ऐसी ही समस्या है।

क्षमा करें यदि यह पहले से ही इस या किसी अन्य मुद्दे से आच्छादित है, लेकिन मुझे यह नहीं मिला।

हमें संभावित रूप से a < ~b में रिक्त स्थान की आवश्यकता हो सकती है; हमने पहले भी इस तरह के नियम जोड़े हैं। तब हम इंफिक्स ऑपरेटरों के रूप में <- और <~ जोड़ सकते थे।

धन्यवाद @JeffBezanson , यह बहुत अच्छा होगा! क्या यह एक विशेष मामला होगा, या अधिक सामान्य नियम होगा? मुझे यकीन है कि अधिक इंफिक्स ऑपरेटरों को अनुमति देने, स्पष्ट और अनुमानित कोड देने और जितना संभव हो सके मौजूदा कोड को तोड़ने के लिए नियम क्या होना चाहिए, इसमें कुछ विवरण हैं। वैसे भी, मैं मदद और त्वरित प्रतिक्रिया की सराहना करता हूं। नववर्ष की शुभकामनाएं!

उस मामले में a <~ b a < ~b से अलग होगा मैं a =+ 1 को त्रुटि के रूप में देखना चाहता हूं (या कम से कम चेतावनी)

मुझे पता है कि यह काफी पुरानी चर्चा है, और पूछा गया प्रश्न कुछ समय पहले पूछा गया था, लेकिन मुझे लगा कि यह उत्तर देने योग्य है:

अब जबकि <| राइट-एसोसिएटिव (#24153) है, तो क्या शुरुआती a |>op<| b प्रस्ताव काम करता है?

नहीं, दुर्भाग्य से, |> को अभी भी प्राथमिकता मिलती है। किया गया अद्यतन ऐसा बनाता है कि, यदि आप <|(a,b)=a(b) को परिभाषित करते हैं, तो आप $# a(b(c)) प्राप्त करने के लिए सफलतापूर्वक a<|b<|c कर सकते हैं ... लेकिन यह एक अलग अवधारणा है।

2 साल के दौरान जमे हुए, 2 और 5 दिन पहले एक टिप्पणी और एक प्रतिबद्धता!

दस्तावेज़ अनुकूलन योग्य बाइनरी ऑपरेटर देखें f45b6be