Julia: प्रस्ताव: पदावनत करें फिर फ़ंक्शन पाइपिंग को हटा दें

फंक्शन पाइपिंग फंक्शन कॉलिंग के लिए एक पोस्टफिक्स सिंटैक्स प्रदान करता है, जो इंटरैक्टिव डेटा जनरेशन और आगे विज़ुअलाइज़ेशन/सारांश के लिए आरईपीएल में सुविधाजनक है।

एक उपयोग का मामला जिसे मैंने बहुत से लोगों को टाइप करते देखा है, है

julia> somecomplicatedthingproducingarray
...

<ARROW UP>

julia> somecomplicatedthingproducingarray |> summarize

जहां summarize फ़ंक्शन प्लॉट या हिस्टोग्राम जैसा कुछ है

@jiahao मैं यह तर्क नहीं दे रहा हूं कि यह उपयोगी नहीं है, बल्कि यह कि हमें बेस के अनुरूप होना चाहिए और पैकेजों को इस तरह की चीजें प्रदान करने दें।

उत्तर उपयोग के लिए ans भी है

इस प्रस्ताव में क्या |> अभी भी एक इंफिक्स ऑपरेटर के रूप में पार्स किया जाएगा?

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

बेस के भीतर सिंटैक्स के उपयोग को हटा दें, यदि कोई मौजूद है

यहाँ एक बहुत पुराना प्रयास है जो मैंने ऐसा करने के लिए किया है: https://github.com/tkelman/julia/commit/212727cdc4aaa3221763580f15d42cfe198bcc1c
उस समय, आधार में अधिकांश उपयोग बहुत तुच्छ थे। "इस अनाम फ़ंक्शन के लिए इस चीज़ को पाइप करें" के कुछ परीक्षणों के उपयोग शायद पाइपिंग के साथ अच्छे हैं, लेकिन चूंकि उनमें से अधिकांश एक ही अनाम फ़ंक्शन का कई बार पुन: उपयोग कर रहे थे, यह संभवतः इसे एक नाम देने और इसे कॉल करने के लायक होगा। उस बिंदु पर सामान्य कार्य।

अगर कोई उत्सुक है, तो मेरे पास अभी ChainRecursive.jl है। ChainMap.jl और इसके विभिन्न बच्चों के पूरा होने के बाद, मैं प्रवचन पर एक घोषणा करूँगा।

मुझे यहां कुछ प्रतिरोध की पेशकश करनी चाहिए क्योंकि मेरे कुछ निहित स्वार्थ हैं और एक विशेष पसंद है जो |> संभव बनाता है।

मैं @jiahao के साथ दूसरे स्थान पर हूं कि |> बहुत उपयोगी है जब आप आरईपीएल में चीजों को जल्दी से आज़माना चाहते हैं। इसके अलावा, मुझे यह तब भी उपयोगी लगता है जब आपका तर्क बहुत बड़ा हो या कुछ उचित हो (हाँ, मैंने ऐसा कहा था) । लिंक किए गए उदाहरण के मामले में, यह वास्तव में बेहतर है कि तर्क को फ़ंक्शन कहे जाने की तुलना में अधिक प्रमुख होना चाहिए। sum(x) एक उदाहरण बहुत आसान है, और वास्तव में sum(x) के रूप में लिखा जाना चाहिए)। Escher.jl में सभी फ़ंक्शन जो तत्वों में गुण जोड़ते हैं उनकी एक करीबी विधि होती है। यह |> के साथ बहुत अच्छी तरह से मेल खाता है (जिसकी योजना बनाई गई थी, यह map के साथ भी बहुत अच्छा काम करता है) और लाइन के अंत में चीजों को आजमाने और यूआई अपडेट देखने में सक्षम होना खुशी की बात है तुरंत। मुझे अभिव्यक्ति की शुरुआत और चारों ओर चक्कर लगाने के लिए अपना रास्ता खोजने की ज़रूरत नहीं है। कम से कम एस्चर के साथ प्रयोग के लिए, सुझाया गया विकल्प padded_box_contents_aligned_right_tomato_background (या इससे भी बदतर box34 ) जैसे बनाए गए नामों के चर के लिए बड़े भाव निर्दिष्ट करना है और फिर उन पर एक फ़ंक्शन को कॉल करना है। खूबसूरती से पढ़ने के विपरीत <big UI expression> |> aligncontents(right) |> pad(1em) |> fillcolor("tomato")

मुझे पता है कि इसके बाद मैं एस्चर के अंदर |> को परिभाषित कर सकता हूं और शायद मैं करूंगा, लेकिन यह देखने के लिए मेरे दिमाग को मार देगा WARNING: using Escher.|> in module YourPackage conflicts with an existing identifier. पैकेज लगभग निश्चित रूप से इसके अलग-अलग अर्थ देंगे, जो मेरे लिए बहुत है खतरनाक!

स्टेफनकारपिंस्की और एंडीफेरिस ने हमें #17155 में मनमाना फंक्शन कंपोजिशन दिया, जो कई स्थितियों में एक समान उद्देश्य की पूर्ति कर सकता है।

box |> fill("orange") |> pad(2em) का विकल्प (fill("orange") ∘ pad(2em))(box) के विपरीत box |> fill("orange") ∘ pad(2em) होगा? ये दोनों ओर्थोगोनल लगते हैं।

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

बेस की इस परिभाषा को हटाने से उन लोगों को अनुमति मिलेगी जो इस सिंटैक्स को पसंद करते हैं और इसके साथ और अधिक दिलचस्प चीजें कर सकते हैं।

@ शशि मैं आपके बिंदुओं को समझता हूं, लेकिन आप इस मुद्दे में उद्धृत पैकेजों में से एक का उपयोग करके वही व्यवहार प्राप्त करने में सक्षम होंगे, है ना? उदाहरण के तौर पर, आपके Escher उदाहरण में, आप <strong i="6">@p</strong> vbox(<really big thing>) | pad(2em) करने के लिए FunctionalData का उपयोग कर सकते हैं या @> vbox(...) pad(2em) करने के लिए Lazy का उपयोग कर सकते हैं।

बेस की इस परिभाषा को हटाने से उन लोगों को अनुमति मिलेगी जो इस सिंटैक्स को पसंद करते हैं और इसके साथ और अधिक दिलचस्प चीजें कर सकते हैं।

सिवाय इसके कि यह प्रयोग करने योग्य नहीं होगा, क्योंकि इसका उपयोग करने का एकमात्र सुरक्षित तरीका Escher.|>(...) या Lazy.|>(...) होगा।

हाइपोथेटिक रूप से, कोई |> को इंफिक्स ऑपरेटर के रूप में कैसे उपयोग करेगा यदि आप दो अलग-अलग पैकेजों का उपयोग कर रहे हैं जो इसे परिभाषित और निर्यात करते हैं, यह मानते हुए कि यह Base में परिभाषित नहीं है?

@kmsquire यह उपयोग के मामले पर निर्भर करता है। |> को अभी भी एक इंफिक्स ऑपरेटर के रूप में पार्स किया जाएगा जैसा कि अभी है, इसका बेस में कोई मूल्य नहीं होगा। यदि आप इसे मैक्रो में उपयोग करते हैं, तो इससे कोई फर्क नहीं पड़ता कि कोई विशेष पैकेज इसे कैसे परिभाषित करता है, क्योंकि यह केवल कॉल एक्सप्रेशन में पहला तर्क बन जाता है।

उदाहरण के लिए <| लें, जिसे एक इंफिक्स ऑपरेटर के रूप में पार्स किया गया है लेकिन इसका कोई मूल्य नहीं है। भले ही यह अपरिभाषित है, फिर भी हमारे पास है

julia> dump(:(a <| b))
Expr
  head: Symbol call
  args: Array{Any}((3,))
    1: Symbol <|
    2: Symbol a
    3: Symbol b
  typ: Any

पैकेज Base.:(<|) के लिए विधियों को परिभाषित और निर्यात कर सकते हैं, जिसका अर्थ अलग-अलग चीजें हैं, जैसे कोई + के साथ कर सकता है।

लेकिन पैकेज जो अच्छा फ़ंक्शन पाइपिंग प्रदान करते हैं, मैक्रोज़ में ऐसा करते हैं, मैं ठीक इसी कारण से मानता हूं।

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

अगर हम इसे हटा रहे हैं तो क्या हमें स्ट्रिंग कॉन्सटेनेशन के लिए * को भी हटा देना चाहिए? इसमें समान मुद्दे हैं क्योंकि यह string(a, b) के साथ अनावश्यक है, और कम से कम आश्चर्य के सिद्धांत का उल्लंघन करता है क्योंकि a और b संख्याएं नहीं हैं।

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

|> को अभी भी एक इंफिक्स ऑपरेटर के रूप में पार्स किया जाएगा जैसा कि अभी है, इसका बेस में कोई मूल्य नहीं होगा। यदि आप इसे मैक्रो में उपयोग करते हैं, तो इससे कोई फर्क नहीं पड़ता कि कोई विशेष पैकेज इसे कैसे परिभाषित करता है

अभी भी निश्चित नहीं है कि हमें इसे बेस से हटाने की आवश्यकता क्यों है।

@bramtayl एक अच्छी बात करता है:

मैं कल्पना करता हूं कि यदि पैकेज परिभाषित होते हैं |> यह ठीक होगा परिभाषा आधार है।

और फिर भी एक से अधिक पैकेज का उपयोग करने का एकमात्र तरीका जो इसे परिभाषित करता है, वह है इसे इंफिक्स का उपयोग न करना।

मैं यह नहीं देखता कि मैक्रो के अंदर उपयोग किए जाने के लिए |> के लिए बेस में परिभाषा को हटाना क्यों आवश्यक है।

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

@ararslan ठीक है, वह नहीं था जो मैं पूछना चाहता था, मैंने अपनी टिप्पणी ठीक बाद में अपडेट की, क्षमा करें।

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

शायद कुछ औपचारिक: कृपया रिलीज चक्र की शुरुआत में बहिष्करण और/या वाक्यविन्यास परिवर्तनों पर चर्चा/निर्णय लें, अंत में नहीं। वर्तमान में सभी मुख्य डेवलपर्स और पैकेज जिम्मेदार 0.6 खत्म करने पर समय और ऊर्जा खर्च करते हैं और उनके पास किसी अन्य (अच्छे) विचार के बारे में सोचने का समय नहीं हो सकता है।

"मैं यह तर्क नहीं दे रहा हूं कि यह उपयोगी नहीं है, बल्कि हमें सुसंगत होना चाहिए"

कभी-कभी उपयोगिता निरंतरता को मात देती है? मुझे असंगति के बारे में पता नहीं था, लेकिन मैंने |> सिंटैक्स उपयोगी पाया है। अगर इसे हटा दिया जाता है तो मुझे नहीं लगेगा कि मैंने कुछ ठोस हासिल किया है।

मेरे थम्स-डाउन वोट के लिए एक स्पष्टीकरण, यदि मैं कर सकता हूं:

बेस में वर्तमान में जो कुछ है, वह इसके बजाय पैकेज में हो सकता है। क्या हमें शब्दकोशों को एक पैकेज में ले जाना चाहिए? हो सकता है कि सूची संचालन जैसे सॉर्ट और शफल? संग्रह संचालन, आदि? मुझे यकीन है कि बेस में क्या शामिल किया जाना चाहिए और क्या नहीं, इस बारे में लंबी और विस्तृत चर्चा हुई है, लेकिन मुझे लगता है कि आधार में कुछ कार्यक्षमता शामिल होने के तीन कारण हैं:
1) आधार में अन्य सुविधाओं को सक्षम करने के लिए वह कार्यक्षमता आवश्यक है।
2) वह कार्यक्षमता भाषा का एक अनिवार्य हिस्सा है, कई जूलिया प्रोग्रामर और पैकेज इसका उपयोग करेंगे, और इसलिए एक एकल कार्यान्वयन/वाक्यविन्यास होना वांछनीय है, जिस पर हर कोई सहमत होता है, न कि बहुत से लोगों के अपने स्वयं के रोलिंग के विखंडन के बजाय।
3) आधार में उस कार्यक्षमता को शामिल करना "कच्ची" जूलिया को उपयोग करने के लिए अधिक सुखद बनाता है या इसे अधिक पूर्ण विशेषताओं वाला महसूस कराता है, जो भाषा के प्रचार और अपनाने में मदद करता है।

sum जैसा कुछ शायद सभी 3 बिंदुओं को हिट करता है, और मैं तर्क दूंगा कि फ़ंक्शन पाइपिंग दूसरे और तीसरे बिंदु को हिट करता है:

प्रारंभिक (अच्छी तरह से लिखित) प्रस्ताव और इस धागे में चर्चा दोनों में, एक सामान्य विषय मैक्रोज़ के माध्यम से पाइप जैसी कार्यक्षमता प्रदान करने वाले कई पैकेजों का अस्तित्व है: Lazy.jl, Pipe.jl, ChainMap.jl, आदि। अस्तित्व कई पैकेजों की संख्या दृढ़ता से सुझाव देती है कि समुदाय में कई लोग पाइपिंग को एक उपयोगी और वांछनीय विशेषता पाते हैं, और इस चर्चा सूत्र में इन पैकेजों की उपस्थिति से पता चलता है कि यहां कई लोग पाइपिंग के उपयोग को समझते हैं और समर्थन करते हैं।

यह देखते हुए कि जूलिया समुदाय और अन्य भाषाओं में पाइपिंग एक आम और लोकप्रिय विशेषता है, इस चर्चा में भी लोग इस बात से सहमत प्रतीत होते हैं कि इसके कई उपयोग हैं, खासकर आरईपीएल (जहां जूलिया चमकता है) में, और जूलिया पारिस्थितिकी तंत्र में पहले से ही विखंडन है। ..my read यह नहीं है कि इसे बेस से हटा दिया जाना चाहिए, बल्कि यह कि बेस में उपलब्ध पाइपिंग सिंटैक्स को बढ़ाया जाना चाहिए ताकि विखंडन की कम आवश्यकता हो। अलग-अलग तरीके पेश करने वाले अलग-अलग पैकेज जैसे प्लॉटिंग ठीक लगती है; विभिन्न लोकप्रिय पैकेज जो फ़ंक्शन लागू करने के विभिन्न तरीकों की पेशकश करते हैं, वे बहुत डरावने लगते हैं।

मैं आगे तर्क देता हूं कि बेस से पाइपिंग को हटाना लेकिन इंफिक्स ऑपरेटर को इधर-उधर छोड़ना आश्चर्यजनक है: जूलिया में आप अपने खुद के इंफिक्स ऑपरेटरों को परिभाषित नहीं कर सकते हैं, लेकिन एक अप्रयुक्त इंफिक्स ऑपरेटर |> है जो चारों ओर लटका हुआ है जिसे आप परिभाषित कर सकते हैं कृपया आप? यदि यह अच्छी कार्यक्षमता है, तो हमें अपनी इच्छानुसार परिभाषित करने के लिए एक ठोस 10 या 20 इंफिक्स ऑपरेटर क्यों न दें?

अंत में, मेरा मानना ​​​​है कि पाइपिंग को ठीक से रखना स्वाभाविक है क्योंकि यह अन्य फ़ंक्शन एप्लिकेशन से अलग है। यह एक विशेषता है, बग नहीं, कि यह कार्य लागू करने के अन्य सम्मेलनों से अलग है; यह अंतर वह है जो इसे कुछ उपयोग के मामलों में चमकने देता है। और ऐसे अन्य मामले भी हैं जहां क्रिया से पहले संज्ञा आती है (हाथ से थोड़ा लहराते हुए), और इनमें से कई ऐसे मामलों में बिल्कुल वाक्यात्मक चीनी हैं जहां कच्चे फ़ंक्शन का अनुप्रयोग बोझिल है। मेरे सिर के ऊपर से, असाइनमेंट x = 5 क्रिया से पहले संज्ञा (प्रतीक x ) डाल रहा है (एक मान से बांधें)। इसी तरह $#$ getfield $#$ के बजाय t.a प्रकार के क्षेत्रों तक पहुँचने के लिए। और सबसे गहराई से, सरणी अनुक्रमण z[5] जैसे पढ़ता है " z से 5वां तत्व लें" और आम तौर पर getindex(z, 5) से अधिक प्राकृतिक है।

यदि यह अच्छी कार्यक्षमता है, तो हमें अपनी इच्छानुसार परिभाषित करने के लिए एक ठोस 10 या 20 इंफिक्स ऑपरेटर क्यों न दें?

संभवतः इससे कहीं अधिक है यदि किसी में दावा न किए गए ASCII के अलावा सभी यूनिकोड वाले शामिल हैं जैसे <| , ++ , ...

पूरा सूत्र नहीं पढ़ रहा -- लेकिन बस इतना ही कहना चाहता हूँ
कि मुझे पाइप करने में सक्षम होना पसंद है। मैं उपयोगी से अधिक वोट दूंगा
किसी भी दिन निरंतरता।

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

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

पूरा सूत्र नहीं पढ़ रहा

मैं

मुझे पाइप करने में सक्षम होना पसंद है

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

जूलिया में आप अपने खुद के इंफिक्स ऑपरेटरों को परिभाषित नहीं कर सकते हैं

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

मैं इस पर एक तरह से तटस्थ हूं, लेकिन मैं इस भावना को दूसरे स्थान पर रखूंगा कि |> सामान्य फ़ंक्शन कॉल सिंटैक्स से पीछे की ओर होना इसका पूरा बिंदु है। यहां तक ​​​​कि पाइपिंग के सबसे बड़े प्रशंसक (AFAIK) उदाहरण के लिए sin <| x नहीं पूछ रहे हैं क्योंकि यह वास्तव में sin(x) के साथ बेमानी है। |> उन मामलों के लिए है जहां आंखों और/या मस्तिष्क के लिए बहुत सारे कोष्ठकों के बिना बाएं से दाएं प्रवाहित होने वाले डेटा के बारे में सोचना आसान होता है।

मैं चाहता हूं कि |> अधिक शक्तिशाली हो, उदाहरण के लिए x |> f(_) + 2g(_) |> h आदि की अनुमति दें और इसके लिए केवल एक ऑपरेटर न बनें। हर बार किसी ने x |> f को f(x) के अलावा कुछ मतलब के लिए परिभाषित किया है, यह वास्तव में मुझे ट्रिप करता है क्योंकि ऑपरेटर का पूरा बिंदु जैसा कि हमने इसका उपयोग किया है, यह एक अलग-ऑर्डर कॉल सिंटैक्स है। चूंकि हम कॉल को ओवरलोड कर सकते हैं, इसलिए मुझे x |> f मतलब कुछ और होने का कोई अच्छा कारण नहीं दिख रहा है।

@StefanKarpinski मैक्रोज़ का उपयोग करके पहले से ही अधिक शक्तिशाली पाइप प्राप्त किए जा सकते हैं। उदाहरण के लिए देखें Pipe.jl , जो ठीक वही वाक्य रचना प्रदान करता है जिसका आप वर्णन कर रहे हैं। जब तक |> एक ऑपरेटर है (मैं व्यक्तिगत रूप से |> को एक विशेष मामले के लायक नहीं देखता), मैक्रोज़ किसी भी पाइपिंग डिलीमीटर का उपयोग कर सकते हैं जो इंफिक्स को पार्स करता है, भले ही यह एक नहीं है :call । एक उदाहरण के रूप में, कोई इसी तरह @~ से पाइप (कम से कम इस लेखन के रूप में) का उपयोग कर सकता है। लचीलेपन का वह स्तर जूलिया में मैक्रोज़ का उपयोग करने के लाभों में से एक है।

हम पाइप.जेएल की कार्यक्षमता को भाषा में जोड़ सकते हैं, और फिर आपके पास इसे @pipe लिखने की आवश्यकता के बिना होगा।

|> को पदावनत करने का मुख्य कारण यह होगा कि यदि हम किसी अन्य उद्देश्य के लिए वाक्य रचना को पुनः प्राप्त करना चाहते हैं जो लोगों को बहुत बेहतर लगता है।

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

लेकिन अगर कुछ और नहीं है तो हम |> के लिए चाहते हैं, मुझे इसकी (तुच्छ) परिभाषा को अकेले छोड़ने में थोड़ा नुकसान होता है।

मुझे विश्वास नहीं है कि वर्तमान में बेस में |> का पुनर्व्यवस्थित करने का कोई प्रस्ताव है। बेस में इसे परिभाषित नहीं करने के लिए मेरा तर्क यह है कि यह हमें कार्यक्षमता के नुकसान के बिना अधिक स्थिरता देता है।

क्या इस मौजूदा परिभाषा के बारे में चिंता करने या काम करने के लिए कोई "अधिक शक्तिशाली पाइपिंग" प्रस्ताव या पैकेज कार्यान्वयन को आसान नहीं बनाया जाएगा?

@ararslan "यह सच नहीं है; कुछ भी जो एक इंफिक्स ऑपरेटर के रूप में पार्स करता है उसे परिभाषित या फिर से परिभाषित किया जा सकता है।"

मैनुअल "&& और || ऑपरेटरों" से, उन्हें पार्स किया जाता है लेकिन उन्हें फिर से परिभाषित नहीं किया जा सकता है (यह एक अच्छी बात है)। मैं केवल अपवादों को मानता हूं।

तथाकथित "लॉजिकल ऑपरेटर्स" && और || इंफिक्स हैं। [यूनरी बाइनरी रिलेशन] "ऑपरेटर" आईएमएचओ उनके लिए गलत शब्द है क्योंकि वे नहीं हैं। नहीं तार्किक बिटवाइज़ के समान तरीका है & और | जो ओवरलोडिंग की अनुमति देते हैं (कुछ ऐसा जो मुझे यकीन नहीं है एक अच्छा विकल्प है)।

@PallHaraldsson वे नियंत्रण प्रवाह हैं, न कि ऑपरेटरों को उसी अर्थ में & , | , + , आदि।

कृपया यदि संभव हो तो यहां विषय पर बने रहने का प्रयास करें।

@tkelman यह एक अच्छी बात है। मुझे संदेह है कि हम भविष्य के पाइपिंग सिंटैक्स को पीछे-संगत बना सकते हैं। उदाहरण के लिए, यदि _ आरक्षित है तो |> का एक विशेष अर्थ हो सकता है जब इसके तर्कों में _ हो, और अन्यथा वही काम करें जो वह अभी करता है।

एक और मुद्दा है: अपनी वस्तु के लिए |> काम करने के लिए, क्या आप |> या "फ़ंक्शन कॉल ऑपरेटर" (यानी इसमें विधियों को जोड़ना) परिभाषित करते हैं? यदि |> फ़ंक्शन कॉल के लिए अंतर्निहित सिंटैक्स थे, तो यह सुनिश्चित करने के लिए f(x) और x |> f हमेशा समान होते हैं, यह क्लीनर हो सकता है।

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

मुझे पता है कि यह मुद्दा बंद हो गया है। ऑपरेटर रखने के लिए बस "धन्यवाद" कहना चाहता था।