. सिंटैक्स बहुत उपयोगी है, इसलिए हम इसे फ़ंक्शन कॉल का केवल एक पर्याय नहीं बनाने जा रहे हैं। मैं 1.sum(2) sum(1,2) के लाभ को नहीं समझता। मेरे लिए यह चीजों को भ्रमित करने के लिए लगता है।

क्या अपवादों के बारे में सवाल एक अलग मुद्दा है? मुझे लगता है कि जवाब नहीं है, एक तरफ कोशिश में शरीर को लपेटने से अलग..कैच।

1.sum (2) का उदाहरण तुच्छ है (मैं भी राशि (1,2) पसंद करता हूं) लेकिन यह केवल यह प्रदर्शित करना है कि कोई फ़ंक्शन उस प्रकार के पूर्व के स्वामित्व में नहीं है। 1 को एक फंक्शन में पास किया जा सकता है, पहला पैरामीटर रियल होने के नाते, न कि केवल उन फंक्शंस के लिए जो पहले पैरामीटर के इंट होने की उम्मीद करते हैं।

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

validate_for(name).required().gt(3) 
# vs 
gt(required(validate_for(name)), 3) 

जिन अपवादों का मैं जिक्र कर रहा था, वे गैर-नियतात्मक परिणामों (जो कि वैसे भी बुरा अभ्यास है) को वापस करने वाले कार्यों के कारण है। एक उदाहरण a.sum (2) .sum (4) कहलाता है जहाँ .sum (2) कभी-कभी एक Int के बजाय एक String लौटाता है। लेकिन ss (4) एक Int की अपेक्षा करता है। मैं समझता हूं कि संकलक / रनटाइम पहले से ही ऐसी परिस्थितियों का मूल्यांकन करने के लिए पर्याप्त स्मार्ट है - जो फ़ंक्शन योग (राशि (1, 2), 4) को घोंसले में डालने के लिए समान होगा - लेकिन सुविधा अनुरोध के लिए प्रकार की बाधाओं को लागू करने के लिए कार्यक्षमता की आवश्यकता होगी। डॉट फ़ंक्शंस।

लोगों द्वारा पसंद किए जाने वाले उपयोग मामलों में से एक "धाराप्रवाह इंटरफ़ेस" है। ओओपी एपीआई में यह कभी-कभी अच्छा होता है जब विधियाँ ऑब्जेक्ट को लौटाती हैं, तो आप some_obj.move(4, 5).scale(10).display() जैसी चीजें कर सकते हैं

मेरे लिए मुझे लगता है कि यह फ़ंक्शन रचना के रूप में बेहतर रूप से व्यक्त किया गया है, लेकिन |> तर्कों के साथ काम नहीं करता है जब तक कि आप एक आयन का उपयोग नहीं करते हैं। कार्य, जैसे some_obj |> x -> move(x, 4, 5) |> x -> scale(x, 10) |> display , जो बहुत बदसूरत है।

इस तरह की चीज़ों का समर्थन करने का एक विकल्प यह होगा कि |> LHS का मूल्यांकन करने से पहले RHS को पहले तर्क के रूप में बताए, लेकिन फिर इसे एक साधारण फ़ंक्शन के रूप में लागू नहीं किया जा सका जैसा कि अब है।

एक अन्य विकल्प @composed मैक्रो होगा जो इस प्रकार के व्यवहार को निम्न अभिव्यक्ति में जोड़ देगा

आप लाइब्रेरी डिजाइनरों को इसका समर्थन करने के लिए जिम्मेदारी भी स्थानांतरित कर सकते हैं, जहां वे परिभाषित कर सकते हैं

function move(obj, x, y)
    # move the object
end

move(x, y) = obj -> move(obj, x, y)

इसलिए जब आप किसी वस्तु की आपूर्ति नहीं करते हैं तो यह आंशिक फ़ंक्शन अनुप्रयोग (1 तर्क के फ़ंक्शन को वापस करके) करता है जिसे आप तब एक सामान्य |> श्रृंखला के अंदर उपयोग कर सकते हैं।

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

सोमवार, 27 जनवरी, 2014 को, स्पेंसर रसेल नोटिफिकेशन @github.com
लिखा था:

लोगों द्वारा पसंद किए जाने वाले उपयोग मामलों में से एक "धाराप्रवाह इंटरफ़ेस" है। आईटी इस
कभी-कभी ओओपी एपीआई में अच्छा होता है जब विधियां ऑब्जेक्ट को वापस करती हैं, तो आप कर सकते हैं
some_obj.move (4, 5) .scale (10) .display () जैसी चीजें

मेरे लिए मुझे लगता है कि यह बेहतर रूप से कार्य रचना के रूप में व्यक्त किया जाता है, लेकिन
जब तक आप anon का उपयोग नहीं करते। कार्य, जैसे some_obj
|> x -> चाल (x, 4, 5) |> x -> स्केल (x, 10) |> प्रदर्शन, जो सुंदर है
बदसूरत।

इस तरह की चीज़ का समर्थन करने का एक विकल्प होगा यदि |> LHS के रूप में भेज दिया गया
मूल्यांकन करने से पहले आरएचएस के लिए पहला तर्क, लेकिन फिर ऐसा नहीं हो सका
इसे अब एक साधारण कार्य के रूप में लागू किया जाता है।

एक अन्य विकल्प किसी प्रकार का @ कंपोज्ड मैक्रो होगा जो इसे जोड़ देगा
निम्नलिखित अभिव्यक्ति के लिए व्यवहार की तरह

आप लाइब्रेरी में इसे सपोर्ट करने की जिम्मेदारी भी बदल सकते हैं
डिज़ाइनर, जहाँ वे परिभाषित कर सकते हैं

फंक्शन मूव (obj, x, y)
# ऑब्जेक्ट को स्थानांतरित करें
समाप्त

चाल (x, y) = obj -> चाल (obj, x, y)

इसलिए जब आप किसी ऑब्जेक्ट की आपूर्ति नहीं करते हैं तो यह आंशिक फ़ंक्शन अनुप्रयोग करता है
(1 तर्क के एक फ़ंक्शन को वापस करके) जिसे आप तब उपयोग कर सकते हैं a
सामान्य |> श्रृंखला।

-
इस ईमेल का सीधा उत्तर दें या इसे Gi tHubhttps: //github.com/JuliaLang/julia/issues/5571#issuecomment -33408448 पर देखें।
।

ssfrr मुझे आपके सोचने का तरीका पसंद है! मैं फ़ंक्शन संरचना |> अनजान था। मैं देख रहा हूं कि हाल ही में एक समान चर्चा हुई है [https://github.com/JuliaLang/julia/issues/4963]।

kmsquire मुझे कॉलिंग फ़ंक्शन पूर्व पर पैरामीटर निर्दिष्ट करने की अनुमति देने के लिए वर्तमान फ़ंक्शन संरचना को विस्तारित करने का विचार पसंद है। some_obj |> move(4, 5) |> scale(10) |> display । मूल समर्थन का मतलब एक कम बंद होना होगा, लेकिन ssfrr ने जो सुझाव दिया है वह अभी के लिए एक व्यवहार्य तरीका है और एक अतिरिक्त लाभ के रूप में इसे विस्तारित फ़ंक्शन संरचना कार्यक्षमता के साथ संगत होना चाहिए अगर यह लागू हो जाता है।

शीघ्र प्रतिक्रिया के लिए धन्यवाद :)

दरअसल, @ssfrr सही था - इसे एक साधारण फ़ंक्शन के रूप में लागू करना संभव नहीं है।

आप जो चाहते हैं, वह मैक्रोज़ (उदा। Http://clojuredocs.org/clojure_core/clojure.core/-%3E) फैला रहा है। दुर्भाग्यपूर्ण है कि जूलिया में @ -> @ - >> - @ -; >> व्यवहार्य वाक्य रचना नहीं है।

हाँ, मैं सोच रहा था कि infix macros इसे लागू करने का एक तरीका होगा। मैं यह जानने के लिए मैक्रों के साथ पर्याप्त रूप से परिचित नहीं हूं कि सीमाएं क्या हैं।

मुझे लगता है कि यह @ssfrr के कम्पोज़ मैक्रो के लिए काम करता है:

संपादित करें: यह थोड़ा स्पष्ट हो सकता है:

import Base.Meta.isexpr
_ispossiblefn(x) = isa(x, Symbol) || isexpr(x, :call)

function _compose(x)
    if !isa(x, Expr)
        x
    elseif isexpr(x, :call) &&    #
        x.args[1] == :(|>) &&     # check for `expr |> fn`
        length(x.args) == 3 &&    # ==> (|>)(expr, fn)
        _ispossiblefn(x.args[3])  #

        f = _compose(x.args[3])
        arg = _compose(x.args[2])
        if isa(f, Symbol)
            Expr(:call, f, arg) 
        else
            insert!(f.args, 2, arg)
            f
        end
    else
        Expr(x.head, [_compose(y) for y in x.args]...)
    end
end

macro compose(x)
    _compose(x)
end

julia> macroexpand(:(<strong i="11">@compose</strong> x |> f |> g(1) |> h('a',"B",d |> c(fred |> names))))
:(h(g(f(x),1),'a',"B",c(d,names(fred))))

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

+1। यह विशेष रूप से महत्वपूर्ण है जब आप डेटा विश्लेषण के लिए जूलिया का उपयोग कर रहे हैं, जहां आपके पास आमतौर पर डेटा ट्रांसफ़ॉर्मेशन पाइपलाइन है। विशेष रूप से, पायथन में पंडों का उपयोग करने के लिए सुविधाजनक है क्योंकि आप df.groupby ("कुछ") जैसी चीजें लिख सकते हैं। कुल (योग) .std () (रीसेट) (), जो वर्तमान के साथ लिखने के लिए एक बुरा सपना है>> वाक्यविन्यास ।

: +1: इसके लिए।

(मैंने इसके लिए .. infix ऑपरेटर ( obj..move(4,5)..scale(10)..display ) के उपयोग का सुझाव देने में पहले से सोचा था, लेकिन ऑपरेटर |> भी अच्छा होगा)

एक और संभावना है, करी के लिए सिंथेटिक चीनी जोड़ना, जैसे
f(a,~,b) x->f(a,x,b) । तब |> अपना वर्तमान अर्थ रख सकते थे।

ऊह, यह किसी भी अभिव्यक्ति को एक समारोह में बदलने का एक बहुत अच्छा तरीका होगा।

संभवतः क्लोजर के अनाम फ़ंक्शन शाब्दिक जैसे कुछ, जहां #(% + 5) x -> x + 5 लिए आशुलिपि है। यह भी% 1,% 2, आदि के साथ कई तर्कों का सामान्यीकरण करता है, इसलिए #(myfunc(2, %1, 5, %2) x, y -> myfunc(2, x, 5, y) लिए आशुलिपि है

शारीरिक रूप से मुझे नहीं लगता कि वाक्यविन्यास बहुत ही पठनीय जूलिया में फिट बैठता है, लेकिन मुझे सामान्य विचार पसंद है।

ऊपर मेरे उदाहरण का उपयोग करने के लिए (और% के बजाय @malmaud के tilde पर स्विच करना), आप कर सकते थे

some_obj |> move(~, 4, 5) |> scale(~, 10) |> display

जो बहुत अच्छा लग रहा है।

यह अच्छा है कि यह पहले तर्क को कोई विशेष उपचार नहीं देता है। नकारात्मक पक्ष यह है कि इस तरह से हम एक प्रतीक ले रहे हैं।

शायद यह एक और जगह है जहां आप एक मैक्रो का उपयोग कर सकते हैं, इसलिए प्रतिस्थापन केवल मैक्रो के संदर्भ में होता है।

हम स्पष्ट रूप से ~ साथ ऐसा नहीं कर सकते क्योंकि यह जूलिया में पहले से ही एक मानक कार्य है। Scala _ साथ ऐसा करता है, जो हम भी कर सकते थे, लेकिन यह पता लगाने की एक महत्वपूर्ण समस्या है कि अभिव्यक्ति का कौन सा भाग अनाम फ़ंक्शन है। उदाहरण के लिए:

map(f(_,a), v)

इसका मतलब कौन सा है?

map(f(x->x,a), v)
map(x->f(x,a), v)
x->map(f(x,a), v)

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

ठीक है, मैं आपकी बात देख रहा हूं कि कितनी दूर जाना है इसकी अस्पष्टता पर। क्लॉजुर में पूरी अभिव्यक्ति #(...) में लिपटी है इसलिए यह असंदिग्ध है।

जूलिया में _ का उपयोग न करना मुहावरेदार है? जैसे x, _ = somfunc() अगर somefunc दो मान लौटाते हैं और आप केवल पहला ही चाहते हैं?

हल करने के लिए कि मुझे लगता है कि हमें एक प्रक्षेप जैसे उपयोग के साथ मैक्रो की आवश्यकता होगी:

some_obj |> @$(move($, 4, 5)) |> @$(scale($, 10)) |> display

लेकिन फिर से, मुझे लगता है कि यह उस बिंदु पर बहुत अधिक शोर हो रहा है, और मुझे नहीं लगता कि @$(move($, 4, 5)) हमें मौजूदा सिंटैक्स x -> move(x, 4, 5) से अधिक कुछ भी देता है, जो IMO प्रीटियर और अधिक स्पष्ट दोनों है।

मुझे लगता है कि यह एक इन्फिक्स मैक्रो का एक अच्छा अनुप्रयोग होगा। # ४४ ९ rule के रूप में, यदि कोई भी नियम मैक्रों पर लागू होने वाले इनफ़िक्स के रूप में कार्य को परिभाषित करता है, तो हम @-> या @|> मैक्रो जो कि थ्रेडिंग व्यवहार हो सकता है।

हां, मुझे इनफिक्स मैक्रो का विचार पसंद है, हालांकि एक नए ऑपरेटर को इस उपयोग के लिए शुरू किया जा सकता है, क्योंकि यह इनक्लोजर मैक्रोज़ के लिए एक संपूर्ण प्रणाली है। उदाहरण के लिए,
some_obj ||> move($,4,5) ||> scale($, 10) |> disp
या शायद |> लेकिन एक नियम है कि
x |> f निहितार्थ x |> f($) में रूपांतरित होता है:
some_obj |> scale($,10) |> disp

दोस्तों, यह सब वास्तव में बदसूरत दिखता है: |>>>>
अब तक मुझे पता चला है कि जूलिया का वाक्य-विन्यास इतना स्पष्ट है कि ऊपर जिन चीजों की चर्चा की गई है, वे किसी भी चीज़ की तुलना में इतनी सुंदर नहीं लगती हैं।

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

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

क्षमा करें, मैं निर्दयी होने की कोशिश नहीं कर रहा हूं। और हाँ - प्रस्ताव के बिना आलोचक
बेकार हैं।

दुर्भाग्य से मैं भाषाओं का निर्माण करने वाला वैज्ञानिक नहीं हूं इसलिए मैं अभी नहीं हूं
पता है कि क्या प्रस्तावित करना है ... ठीक है, वैकल्पिक रूप से स्वामित्व वाले तरीकों को छोड़कर
वस्तुओं जैसा कि कुछ भाषाओं में है।

मुझे वाक्यांश "वैज्ञानिक भाषाओं का निर्माण" पसंद है - यह मतलाब के बीमार संख्यात्मक कार्यक्रमों की तुलना में बहुत अधिक भव्य लगता है।

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

मैं स्पेंसर के प्रस्ताव के लिए समर्थन दोहराऊंगा - x |> f(a) f(x, a) में अनुवादित किया जा सकता है, बहुत ही do ब्लॉक कैसे काम करता है (और यह एक सामान्य विषय को पुष्ट करता है कि पहला तर्क फ़ंक्शन को जूलिया में सिंटैक्टिक शुगर उद्देश्यों के लिए विशेषाधिकार प्राप्त है)। x |> f को तब x |> f() लिए शॉर्ट-हैंड के रूप में देखा जाता है। यह सरल है, किसी भी नए ऑपरेटर को पेश नहीं करता है, उन बहुसंख्य मामलों को संभालता है, जिनके लिए हम कार्य करना चाहते हैं, पीछे की ओर संगत है, और मौजूदा जूलिया डिजाइन सिद्धांतों के साथ फिट बैठता है।

मुझे यह भी लगता है कि यहां सबसे अच्छा प्रस्ताव है, मुख्य समस्या यह है कि यह I / O पुनर्निर्देशन या अन्य कस्टम उद्देश्यों जैसी चीजों के लिए |> को परिभाषित करने के लिए लगता है।

बस ध्यान दें, . सिंटैक्स का पीछा करते हुए एक विशेष कार्य नहीं है, लेकिन यह उस तरह से काम करने के लिए होता है यदि बाईं ओर फ़ंक्शन केवल संशोधित वस्तु को वापस करता है, जो कुछ ऐसा है जो पुस्तकालय डेवलपर को जानबूझकर करना है।

समान रूप से, जूलिया में एक पुस्तकालय डेवलपर पहले से ही |> साथ पीछा करने का समर्थन कर सकता है, एन के तर्क के अपने कार्यों को परिभाषित करके 1 तर्क के एक समारोह को वापस करने के लिए जब एन -1 तर्क दिए गए हैं, जैसा कि यहां बताया गया है

यदि आप _want_ अपने फ़ंक्शन को चर की संख्या का समर्थन करने के लिए समस्याएँ पैदा करते हैं, तो ऐसा प्रतीत होता है, हालाँकि, ऐसा ऑपरेटर होना जो तर्क भराई का प्रदर्शन कर सके, अच्छा होगा।

@JeffBezanson , ऐसा लगता है कि इस ऑपरेटर को लागू किया जा सकता है अगर वहाँ infix मैक्रोज़ करने का एक तरीका था। क्या आपको पता है कि इसके साथ कोई वैचारिक मुद्दा है, या इसे लागू नहीं किया गया है?

हाल ही में, ~ को विशेष-आवरण दिया गया था ताकि वह अपने तर्कों और कॉल्स का हवाला दे
डिफ़ॉल्ट रूप से मैक्रो @~ । |> एक ही काम करने के लिए बनाया जा सकता है।

बेशक, कुछ महीनों में, कोई ऐसा करने के लिए <| मांगेगा ...

गुरुवार, 6 फरवरी 2014 को, स्पेंसर रसेल नोटिफिकेशन @github.com
लिखा था:

बस ध्यान दें, सिंटैक्स का पीछा करते हुए एक विशेष कार्य नहीं है, लेकिन ऐसा होता है
इस तरह से काम करने के लिए यदि बाईं ओर स्थित फंक्शन इसे वापस करता है
संशोधित, जो कुछ ऐसा है जो लाइब्रेरी डेवलपर को करना है
जानबूझ कर।

आमतौर पर, जूलिया में एक पुस्तकालय डेवलपर पहले से ही चाइनिंग का समर्थन कर सकता है
समारोह वापस करने के लिए एन तर्कों के उनके कार्यों को परिभाषित करके |
N-1 तर्क दिए जाने पर 1 तर्क में से, जैसा कि यहां बताया गया है

यदि आपको _want_ आपके फ़ंक्शन का समर्थन करने में समस्याएँ उत्पन्न होती हैं
हालांकि, अर्ग की चर संख्या, इसलिए एक ऑपरेटर जो प्रदर्शन कर सकता है
तर्क भराई अच्छी होगी।

@JeffBezanson https://github.com/JeffBezanson , ऐसा लगता है कि यह
ऑपरेटर को लागू किया जा सकता है अगर वहाँ infix मैक्रोज़ करने का एक तरीका था। क्या आप
पता है कि वहाँ के साथ एक वैचारिक मुद्दा है, या अभी लागू नहीं है?

-
इस ईमेल का उत्तर सीधे दें या Gi tHubhttps: //github.com/JuliaLang/julia/issues/5571#issuecomment -34374347 पर देखें
।

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

function move(obj::MyType, x, y, args...)
    # do stuff
    obj
end

move(args...) = obj::MyType -> move(obj, args...)

मुझे लगता है कि यह व्यवहार @composable मैक्रो द्वारा संभाला जा सकता है जो 2 डी घोषणा को संभाल लेगा।

इनफ़िक्स मैक्रो का विचार मेरे लिए उस स्थिति में आकर्षक है जहाँ यह इन्फिक्स फ़ंक्शंस की घोषणा के साथ एकीकृत होगा, जिसकी चर्चा # 4498 में की गई है।

जूलिया रचनाकारों को वस्तुओं को अपने तरीके से अनुमति देने के खिलाफ क्यों हैं? मैं उस निर्णय के बारे में और कहां पढ़ सकता हूं? उस निर्णय के पीछे कौन से विचार और सिद्धांत हैं?

सामान्य प्रश्नों के लिए @meglio एक अधिक उपयोगी स्थान है मेलिंग सूची या StackOverflow julia-lang टैग। स्टीफन की बातचीत और उपयोगकर्ताओं के अभिलेखागार और इस विषय पर पिछली चर्चाओं के लिए देव सूची देखें।

बस मेरे लिए, सबसे सहज बात यह है कि कुछ प्लेसहोल्डर द्वारा प्रतिस्थापित किया जाना है
क्लोजर के as-> मैक्रो के समान, आप जो रचना करने की कोशिश कर रहे हैं, उसके क्रम में पिछली अभिव्यक्ति का मूल्य। तो यह:

<strong i="8">@as</strong> _ begin
    3+3
    f(_,y)
    g(_) * h(_,z)
end

इसका विस्तार किया जाएगा:

g(f(3+3,y)) * h(f(3+3,y),z)

आप अगली पंक्ति पर अंडरस्कोर छेद को भरने के लिए पिछली पंक्ति "ड्रॉप डाउन" पर अभिव्यक्ति के बारे में सोच सकते हैं।

मैंने फाइनल वीक शिथिलता के एक बाउट में पिछली तिमाही की तरह एक छोटे से स्केचिंग शुरू की।

हम |> का उपयोग करके एक ऑन्लाइनर संस्करण का भी समर्थन कर सकते हैं:

<strong i="19">@as</strong> _ 3+3 |> f(_,y) |> g(_) * h(_,z)

@porterjamesj , मुझे यह विचार पसंद है!

मैं सहमत हूँ; यह बहुत अच्छा है, और एक आकर्षक सामान्यता है।
फरवरी 7, 2014 3:19 PM पर, "केविन स्क्वॉयर" नोटिफिकेशन @github.com ने लिखा:

@porterjamesj https://github.com/porterjamesj , मुझे वह विचार पसंद है!

इस ईमेल का उत्तर सीधे दें या Gi tHubhttps: //github.com/JuliaLang/julia/issues/5571#issuecomment -34497703 पर देखें
।

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

ध्यान दें कि जूलिया में, क्योंकि हम obj.method(args...) पैटर्न के बहुत कुछ नहीं करते हैं, और इसके बजाय method(obj, args...) पैटर्न करते हैं, हम उन तरीकों को नहीं करते हैं जो एक्सप्रेस के लिए संचालित वस्तुओं को वापस करते हैं। विधि का उद्देश्य। (जो jQuery करता है, और जावास्क्रिप्ट में शानदार है)। इसलिए हम यहां बहुत टाइपिंग नहीं बचाते हैं, लेकिन फ़ंक्शंस के बीच "पाइप" सेटअप होने के उद्देश्य से, मुझे लगता है कि यह वास्तव में अच्छा है।

यह देखते हुए कि क्लोजर के -> और ->> उपरोक्त के विशेष मामले हैं, और काफी आम हैं, हम शायद उन सुंदर को भी आसानी से लागू कर सकते हैं। हालांकि उन्हें क्या कहा जाए यह सवाल थोड़ा पेचीदा है। शायद @threadfirst और @threadlast ?

मुझे यह एक मैक्रो होने का विचार भी पसंद है।

क्या यह बेहतर नहीं है अगर विस्तार, उदाहरण के बाद, कुछ ऐसा है

tmp = 3+3; tmp = f(tmp); return h(tmp, z)

एक ही ऑपरेशन के लिए कई कॉल से बचने के लिए? (शायद यह पहले से ही @porterjamesj के विचार में निहित था)

एक और सुझाव: क्या यह संभव होगा कि मैक्रो शॉर्टकट f से f(_) और f(y) f(_,y) ? शायद यह बहुत अधिक होगा, लेकिन मुझे लगता है कि तब हमारे पास जरूरत पड़ने पर ही प्लेसहोल्डर का उपयोग करने का विकल्प होता है ... (हालांकि, शॉर्टकट्स को केवल अकेले फ़ंक्शन कॉल पर अनुमति दी जानी चाहिए, न कि g(_) * h(_,z) जैसे अभिव्यक्तियों पर।

कई कॉल से बचने के बारे में @cdsousa एक अच्छी बात है। क्लोजर कार्यान्वयन इसे प्राप्त करने के लिए अनुक्रमिक चलो बाइंडिंग का उपयोग करता है; मुझे यकीन नहीं है कि हम इससे दूर हो सकते हैं, क्योंकि मुझे अपने let के प्रदर्शन के बारे में पर्याप्त जानकारी नहीं है।

तो क्या लाइन ब्रेक्स का उपयोग करके @as मैक्रो और स्प्लिट पॉइंट के रूप में => है, यह तय करने के लिए कि प्रतिस्थापन अभिव्यक्ति क्या है और क्या प्रतिस्थापित किया जा रहा है?

let प्रदर्शन अच्छा है; अब यह जब संभव हो एक चर असाइनमेंट के रूप में तेजी से हो सकता है, और बहुत तेजी से अन्यथा भी।

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

@ कडसोरा :

एक और सुझाव: क्या यह संभव होगा कि मैक्रो शॉर्टकट f से f(_) और f(y) f(_,y)

f से f(_) मेरे लिए समझ में आता है। दूसरे के लिए, मेरी राय है कि स्थान को स्पष्ट रूप से निर्दिष्ट करना बेहतर है, क्योंकि उचित लोग यह तर्क दे सकते हैं कि f(_,y) या f(y,_) अधिक स्वाभाविक है।

यह देखते हुए कि क्लोजर के -> और ->> उपरोक्त के विशेष मामले हैं, और काफी आम हैं, हम शायद उन सुंदर को भी आसानी से लागू कर सकते हैं। हालांकि उन्हें क्या कहा जाए यह सवाल थोड़ा पेचीदा है। शायद @threadfirst और @threadlast ?

मुझे लगता है कि f(_,y...) या f(y..., _) साथ स्थान की खोज को निर्दिष्ट करने से कोड को काफी समझा जा सकता है। जबकि अतिरिक्त वाक्य रचना (और ऑपरेटरों) क्लोजर में समझ में आता है, हमारे पास वास्तव में अतिरिक्त ऑपरेटर उपलब्ध नहीं हैं, और मुझे लगता है कि अतिरिक्त मैक्रो आमतौर पर कोड को कम स्पष्ट कर देगा।

तो क्या लाइन ब्रेक्स का उपयोग करके @as मैक्रो है और स्प्लिट पॉइंट्स के रूप में => है, यह तय करने के लिए कि प्रतिस्थापन अभिव्यक्ति क्या है और क्या प्रतिस्थापित किया जा रहा है?

मुझे लगता है कि विभाजन बिंदु के रूप में |> का उपयोग करना अधिक स्वाभाविक है, क्योंकि यह पहले से ही पाइपलाइनिंग के लिए उपयोग किया जाता है

बस इतना पता है कि, Lazy.jl में थ्रेडिंग मैक्रो का

@>> range() map(x->x^2) filter(iseven)

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

मैं भी Lazy.jl में @as> लागू कर सकता हूं, अगर इसमें रुचि हो। Lazy.jl के पास अब @as मैक्रो भी है।

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

Lazy.jl एक बहुत अच्छा पैकेज की तरह दिखता है, और सक्रिय रूप से बनाए रखा जाता है। क्या यह आधार में होने के लिए एक सम्मोहक कारण है?

कई मानों को लौटाने वाले कार्यों के साथ कार्य की रूपरेखा कैसे काम करेगी?
पीछा करने का परिणाम क्या होगा जैसे:

function foo(a,b)
    a+b, a*b   # x,y respectively
end

और bar(x,z,y) = x * z - y हो?

क्या इसे bar(_1,z,_2) जैसे सिंटैक्स की आवश्यकता नहीं होगी?

दूसरे उदाहरण में फेंकना:

data = [2.255, 3.755, 6.888, 7.999, 9.001]

लिखने का साफ तरीका: log(sum(round(data))) data|>round|>sum|>log
लेकिन अगर हम आधार 2 लॉग करना चाहते थे, और 3 दशमलव तक गोल करना चाहते थे,
तब: हम केवल पहले फॉर्म का उपयोग कर सकते हैं:
log(2,sum(round(data,3)))

लेकिन आदर्श रूप से हम ऐसा करने में सक्षम होना चाहेंगे:
data|>round(_,3)|>sum|>log(2,_)
(या इसी के समान)

मैंने इसके लिए एक प्रोटोटाइप बनाया है कि मैं सुझाव दूं कि यह कैसे काम करना चाहिए।
https://github.com/oxinabox/Pipe.jl

यह @ समूह की बात को हल नहीं करता है, लेकिन मैं उस पर काम कर रहा हूं।
यह तर्कों का विस्तार करने की आवश्यकता को भी नहीं संभालता है

यह @ वन-मिनट्स के आलसी .jl थ्रेडिंग मैक्रोज़ जैसा ही है, लेकिन पठनीयता (व्यक्तिगत पसंद) के लिए |> प्रतीक रखता है।

मैं इसे धीरे-धीरे एक पैकेज में बनाऊंगा, शायद, किसी बिंदु पर

एक और विकल्प है:

data |>   x -> round(x,2)  |> sum |>  x -> log(2,x)

हालांकि log(2,sum(round(data,2))) यह नोटेशन कभी-कभी पठनीयता में मदद करता है।

@ शशि जो बुरा नहीं है, उसके बारे में नहीं सोचा,
मुझे लगता है कि आमतौर पर बहुत आसानी से पठनीय होने की क्रिया होती है

https://github.com/oxinabox/Pipe.jl अब @gregid की समस्या का समाधान करता है।
यद्यपि यदि आप दोनों _[1] और _[2] माँगते हैं, तो यह सबसट्रेशन में कई कॉल करके ऐसा करता है
जो मैं निश्चित नहीं हूं वह सबसे वांछनीय व्यवहार है।

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

यह होगा [1:10] |> map(e -> e^2) में परिणाम [1, 4, 9, 16, 25, 36, 49, 64, 81, 100] ।

पीछे देखते हुए, @ssfrr ने इसे स्वीकार किया , लेकिन उनके उदाहरण में obj तर्क स्वचालित रूप से मेरे उदाहरण में दूसरे तर्क के रूप में map को दिया जाएगा, इस प्रकार प्रोग्रामर को अपने कार्यों को परिभाषित करने से बचाना होगा। इसका समर्थन करें।

आप क्या प्रस्ताव करते हैं कि इसका मतलब है?

5 जून 2015 को, 5:22 बजे, H-225 सूचनाएँ @ithub.com ने लिखा:

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

इससे [१:१०] |> नक्शा (e -> e ^ २) परिणाम [१, ४, ९, १६, २५, ३६, ४ ९, ६४, 10१, १००] होगा।

व्यक्तिगत रूप से, मुझे लगता है कि यह बहुत अच्छा है और स्पष्ट भी बिना क्रिया के है।

जाहिर है, कोई भी परिणाम = नक्शा (sqr, [1:10]) लिख सकता है, लेकिन उनके पास पाइपलाइन ऑपरेटर क्यों है?
शायद मुझे याद आ रही है?

-
इस ईमेल का उत्तर सीधे दें या इसे GitHub पर देखें।

@StefanKarpinski
मूल रूप से, ऑपरेटर काम की तरह है:

• x |> y(f) = y(x, f)
• x |> y(f) = y(f, x)

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

क्या यह कोई स्पष्ट है?

Lazy.jl एक बहुत अच्छा पैकेज की तरह दिखता है, और सक्रिय रूप से बनाए रखा जाता है। क्या यह आधार में होने के लिए एक सम्मोहक कारण है?

मुझे लगता है कि यह यहाँ महत्वपूर्ण प्रश्न है।

आधार में यह वांछनीय हो सकता है कारण 2 गुना है:

1.) हम जूलियन वे होने के रूप में पाइपलाइनिंग को प्रोत्साहित करना चाहते हैं - तर्क दिया जा सकता है कि यह अधिक पठनीय है
2.) Lazy.jl, FunctionalData.jl, और मेरे अपने पाइप.jl जैसी चीजों के लिए एक मैक्रो की आवश्यकता होती है जो उस अभिव्यक्ति को लपेटने के लिए है जिस पर उसे कार्य करना है - जो इसे कम पठनीय बनाता है।

मुझे लगता है कि इसका जवाब इन्फिक्स मैक्रोज़ के पास हो सकता है।
और परिभाषित करना |> इस तरह।

मैं कुछ नहीं कर रहा हूँ |>, (या उनके चचेरे भाई को ब्लॉक) सभी कोर में हैं।
लेकिन उपकरण उन्हें पार्सर के बाहर परिभाषित करने के लिए मौजूद नहीं हैं।

उस प्रकार के पाइपलाइनिंग सिंटैक्स की क्षमता बहुत अच्छी लगती है। क्या बस आधार को जोड़ा जा सकता है, यानी x |> y(f) = y(f, x) हिस्सा, जो Lazy.j, FunctionalData.jl, और पाइप.jl उपयोग कर सकता है? : +1:

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

@tkelman
व्यक्तिगत रूप से, मैं इसे कुछ हद तक उपयोगितावादी दृष्टिकोण से देखता हूं।
दी, शायद अगर आप कुछ सरल कर रहे हैं तो यह आवश्यक नहीं है, लेकिन यदि आप एक फ़ंक्शन लिख रहे हैं, तो यह काफी जटिल है, या लंबे समय से घुमावदार है, (मेरे सिर के ऊपर: डेटा हेरफेर जैसे)। तब मुझे लगता है कि जहां पाइपलाइन सिंटैक्स चमकता है।

मैं समझता हूं कि आपका क्या मतलब है; यदि आपके पास एक फ़ंक्शन कॉल सिंटैक्स है, तो यह _would_ अधिक समान होगा। व्यक्तिगत रूप से, हालांकि, मुझे लगता है कि [जटिल] कोड लिखना आसान हो जाता है जिसे आसानी से समझा जा सकता है। दी, आपको सिंटैक्स सीखना होगा और इसका क्या अर्थ है, लेकिन, IMHO, |> किसी फ़ंक्शन को कॉल करने की तुलना में समझ से अधिक कठिन नहीं है।

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

हमारे पास फ़ंक्शन पाइपिंग ऑपरेटर के रूप में |> , लेकिन वर्तमान में यह कैसे किया जाता है, इस समय इसे बहुत धीमा बनाने के लिए कार्यान्वयन सीमाएं हैं।

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

ठीक है, धन्यवाद, मैं @oxinabox की टिप्पणी से जा रहा था:

लेकिन उपकरण उन्हें पार्सर के बाहर परिभाषित करने के लिए मौजूद नहीं हैं।

क्या यह समझा जाता है कि आपके द्वारा संदर्भित कार्यान्वयन सीमाओं को हटाने के लिए क्या किया जाएगा?

पहले के कुछ सुझावों को संभवतः |> पार्स के रूप में लागू किया जा सकता है, एक फ़ंक्शन के रूप में एक मैक्रो के रूप में अपने तर्क। |> पूर्व कमांड-ऑब्जेक्ट पाइपिंग को हटा दिया गया है, इसलिए इसे वास्तव में कुछ अलग करने के लिए मुक्त किया जा सकता है, 0.5-देव आएं।

हालाँकि यह चुनाव मुझे ~ के विशेष पार्सिंग की काफी याद दिलाता है जो मुझे लगता है कि उन कारणों के लिए एक गलती है जो मैंने कहीं और बताई है।

पार्सिंग ~ केवल पागल है, यह आधार में एक फ़ंक्शन है। _ , _1 , _2 , _more और उचित लगता है (यदि आप उठाते हैं कि क्या ये चर दायरे में कहीं और परिभाषित किए गए हैं)। फिर भी जब तक हमारे पास अधिक कुशल अनाम कार्य नहीं हैं, ऐसा लगता है कि यह काम नहीं कर रहा है ...

लागू करके |>> फ़ंक्शन के बजाय मैक्रो के रूप में इसके तर्कों को पार्स करें

जब तक आप ऐसा नहीं करते!

पार्सिंग ~ केवल पागल है, यह आधार में एक फ़ंक्शन है

यह बिटवाइज़ वर्जन के लिए एक अपर ऑपरेटर है। Infix बाइनरी ~ पारस एक मैक्रो के रूप में, रेफरी https://github.com/JuliaLang/julia/issues/4882 , जो मुझे लगता है कि अस्सी ऑपरेटर का एक अजीब उपयोग है (https://github.com/) JuliaLang / जूलिया / पुल / 11102 # issuecomment-98,477,891)।

@tkelman

इसलिए हमारे पास दो वाक्यविन्यास हैं, लेकिन एक MIMO मामले में बहुत कम समझ में आता है।

3 सिंटेक्स। एक प्रकार का।
में पाइप, सामान्य फ़ंक्शन कॉल और Do-block।
मैक्रो के साथ-साथ एक अलग सम्मेलन का उपयोग करने के बाद से भी 4, बहस योग्य।

मेरे लिए,
रीडऑर्डर (यानी बाएं से दाएं) == SISO फ़ंक्शन चेन के लिए एप्लिकेशन ऑर्डर, बनाता है, बहुत स्पष्ट है।

मैं बहुत सारे कोड करता हूँ जैसे (iterators.jl, और pip.jl का उपयोग करके):

• loaddata(filename) |> filter(s-> 2<=length(s)<=15, _) |> take!(150,_) |> map(eval_embedding, _)
• results |> get_error_rate(desired_results, _) |> round(_,2)

SISO के लिए, यह बेहतर है (मेरी व्यक्तिगत पसंद के लिए), MIMO के लिए यह नहीं है।

लगता है कि जूलिया पहले से ही चीजों को करने के कई सही तरीके तय कर रही हैं।
जो मैं 100% सुनिश्चित नहीं हूं वह अच्छी बात है।

जैसा कि मैंने कहा कि मैं मुख्य भाषा से हटकर पाइप और डू ब्लॉक पसंद करूंगा।

Do-block में कुछ बहुत ही उपयोगी उपयोग के मामले हैं, लेकिन इसने मुझे थोड़ा परेशान किया है कि उन्हें पहले इनपुट को फ़ंक्शन के रूप में उपयोग करना होगा, हमेशा कई प्रेषण दर्शन (और न ही पंडों / के साथ काफी सही होगा) D शैली UFCS data.map(f).sum() , मुझे पता है कि यह लोकप्रिय है, लेकिन मुझे नहीं लगता कि इसे कई प्रेषण के साथ प्रभावी ढंग से जोड़ा जा सकता है)।

पाइपिंग को संभवतः बहुत जल्द ही हटा दिया जा सकता है, और अपने पाइप की तरह DSL में उपयोग करने के लिए पैकेज पर छोड़ दिया जाता है।

लगता है कि जूलिया पहले से ही चीजों को करने के कई सही तरीके तय कर रही हैं।
जो मैं 100% सुनिश्चित नहीं हूं वह अच्छी बात है।

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

@tkelman @oxinabox
मुझे अभी तक एक स्पष्ट कारण नहीं मिल पाया है कि इसे भाषा में शामिल क्यों नहीं किया जाना चाहिए, या वास्तव में "कोर" पैकेज में। [उदा: आधार]
व्यक्तिगत रूप से, मुझे लगता है कि |> एक मैक्रो का जवाब हो सकता है।
कुछ _लो_ यह शायद? (मैं एक मास्टर जूलिया प्रोग्रामर नहीं हूँ!)

macro (|>) (x, y::Union(Symbol, Expr))
    if isa(y, Symbol)
        y = Expr(:call, y) # assumes y is callable
    end
    push!(y.args, x)
    return eval(y)
end

जूलिया v0.3.9 के तहत, मैं इसे दो बार परिभाषित करने में असमर्थ था - एक बार प्रतीक के साथ, और एक बार अभिव्यक्ति के साथ; मेरी [सीमित] Union की समझ यह है कि इसके उपयोग से प्रदर्शन हिट है, इसलिए मैं अनुमान लगा रहा हूं कि मेरे खिलौना उदाहरण कोड में सुधार करने के लिए कुछ होगा।

बेशक, इसके लिए उपयोग सिंटैक्स के साथ एक समस्या है।
उदाहरण के लिए, log(2, 10) के बराबर चलने के लिए, आपको @|> 10 log(2) लिखना होगा, जो कि यहाँ स्वीकार्य नहीं है।
मेरी समझ यह है कि आपको किसी भी तरह फ़ंक्शन / मैक्रोज़ को "अचूक" के रूप में चिह्नित करने में सक्षम होना होगा, जैसा कि यह था, जैसे कि आप इसे इस प्रकार लिख सकते हैं: 10 |> log(2) । (सही है तो गलत!)
उदाहरण दिया, मुझे पता है। मैं अभी एक अच्छे के बारे में सोच भी नहीं सकता! =)

यह एक ऐसा क्षेत्र है जो मैंने अपने उदाहरण में शामिल नहीं किया है ...
इसलिए जैसे:

julia> for e in ([1:10], [11:20] |> zip) println(e) end
(1,11)
(2,12)
(3,13)
(4,14)
(5,15)
(6,16)
(7,17)
(8,18)
(9,19)
(10,20)

फिर से - उदाहरण से वंचित है, लेकिन उम्मीद है कि आपको बात मिल जाएगी!
मैंने कुछ फ़िदलिंग किया, लेकिन यह लिखने के रूप में मैं थाह नहीं पा रहा था कि इसे कैसे लागू किया जाए, मैं खुद।

कृपया https://github.com/JuliaLang/julia/issues/554#issuecomment -110091527 और # 11608 देखें।

9 जून 2015 को रात 9:37 बजे, H-225 नोटिफिकेशन @github.com ने लिखा:

मुझे अभी तक एक स्पष्ट कारण नहीं मिला है कि इसे भाषा में शामिल क्यों नहीं किया जाना चाहिए

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

सवाल "क्यों?" बजाय "क्यों नहीं?"

+ 1_000_000

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

FWIW, Pyret (http://www.pyret.org/) कुछ महीनों पहले इस सटीक चर्चा से गुजरा। भाषा एक "कैन्यनबॉल" संकेतन का समर्थन करती है, जो मूल रूप से बहुत अधिक कार्य करता है जो लोग |> साथ प्रस्तावित कर रहे हैं। Pyret में,

[list: 1, 2, 3, 5] ^ map(add-one) ^ filter(is-prime) ^ sum() ^ ...

इसलिए, तोप के गोले को कार्यों में तर्क जोड़ने के लिए उतारा गया।

इससे पहले कि वे तय करते कि यह वाक्यविन्यास बहुत भ्रामक था, इसमें बहुत समय नहीं लगा। sum() को बिना किसी तर्क के क्यों कहा जा रहा है? अंत में, उन्होंने एक सुंदर करी विकल्प चुना:

[list: 1, 2, 3, 5] ^ map(_, add-one) ^ filter(_, is-prime) ^ sum() ^ ...

यह अधिक स्पष्ट होने का लाभ है और एक सरल कार्य के लिए ^ ऑपरेटर को सरल करता है।

हां, यह मुझे अधिक उचित लगता है। यह करीने से भी अधिक लचीला होता है।

@StefanKarpinski मैं थोड़ा भ्रमित हूँ। क्या आपके कहने का मतलब और अधिक लचीला है तो जंजीर (करीने से नहीं)? सब के बाद Pyret का समाधान केवल करी का उपयोग करना था, जो कि जंजीरों से अधिक सामान्य है।

हो सकता है, अगर हम |> सिंटैक्स को थोड़ा संशोधित करते हैं (मुझे वास्तव में पता नहीं है कि इसे लागू करना कितना कठिन है, शायद यह | और > साथ संघर्ष करता है), हम कुछ लचीला और पठनीय सेट कर सकता है।

कुछ इस तरह परिभाषित करना

foo(x,y) = (y,x)
bar(x,y) = x*y

हम होंगे:

randint(10) |_> log(_,2) |> sum 

(1,2) |_,x>  foo(_,x)   |x,_>   bar(_,2) |_> round(_, 2) |> sum |_> log(_, 2)

दूसरे शब्दों में, हमारे पास एक ऑपरेटर होगा जैसे |a,b,c,d> जहां a , b , c और d का लौटा हुआ मान मिले। अंतिम अभिव्यक्ति (क्रम में) और इसे अगले एक के अंदर प्लेसहोल्डर्स में उपयोग करें।

यदि |> अंदर कोई चर नहीं हैं तो यह काम करेगा क्योंकि यह अब काम करता है। हम एक नया स्टारडार्ड भी सेट कर सकते हैं: f(x) |> g(_, 1) सभी मूल्यों को f(x) और _ प्लेसहोल्डर के साथ जुड़ेंगे।

@samuela , मेरा मतलब यह था कि करीने से आप केवल पीछे चल रहे तर्कों को छोड़ सकते हैं, जबकि _ दृष्टिकोण के साथ, आप किसी भी तर्क को छोड़ सकते हैं और एक अनाम फ़ंक्शन प्राप्त कर सकते हैं। Ie ने f(x,y) को करीने से दिया, आप f(x) एक ऐसा फंक्शन पाने के लिए कर सकते हैं जो y -> f(x,y) , लेकिन अंडरस्कोर के साथ आप f(x,_) एक ही चीज़ के लिए भी कर सकते हैं f(_,y) पाने के लिए x -> f(x,y) ।

हालांकि मुझे अंडरस्कोर सिंटैक्स पसंद है, फिर भी मैं इस सवाल के किसी प्रस्तावित उत्तर से संतुष्ट नहीं हूं कि यह "कैद" आसपास की अभिव्यक्ति का कितना हिस्सा है।

यदि कोई फ़ंक्शन कई परिणाम देता है तो आप क्या करते हैं? यह एक tuple पारित करना होगा _ स्थिति? या इसे मक्खी पर विभाजित करने के लिए एक वाक्यविन्यास हो सकता है? मूर्खतापूर्ण प्रश्न हो सकता है, यदि ऐसा है, तो क्षमा करें!

@StefanKarpinski आह, मैं देख रहा हूं कि आपका क्या मतलब है। माना।

@ ScottPJones का स्पष्ट उत्तर ASCII कला तीरों को देना है:
http://scrambledeggsontoast.github.io/2014/09/28/needle-announce/

@simonbyrne जो छिद्रित कार्डों पर फोरट्रान IV में प्रोग्रामिंग से भी बदतर लगता है, जैसे मैंने अपने मिस्सिप यूथ में किया था! बस अगर सिंटैक्स जैसे _1, _2, आदि कई रिटर्न के अलावा खींचने की अनुमति दे सकता है, या क्या यह मेरी ओर से सिर्फ एक बेवकूफ विचार है?

@simonbyrne यह शानदार है। यह सुनिश्चित करना कि एक स्ट्रिंग मैक्रो एक अद्भुत GSoC परियोजना होगी।

समन () को बिना किसी तर्क के क्यों कहा जा रहा है?

मुझे लगता है कि निहित तर्क भी do संकेतन के बारे में अधिक भ्रमित करने वाली चीजों में से एक है, इसलिए यह अच्छा होगा यदि हम उसी के लिए उसी सम्मेलन का उपयोग कर सकते हैं (हालांकि मुझे पता है कि यह बहुत अधिक कठिन है, जैसा कि यह पहले से ही भाषा में पके हुए है)।

@simonbyrne आपको नहीं लगता कि यह एक अस्पष्ट तरीके से किया जा सकता है? यदि ऐसा है, तो मुझे लगता है कि कुछ ऐसा है जो तोड़ने के लायक है (वर्तमान do संकेतन), अगर इसे अधिक तार्किक, अधिक सामान्य और जंजीर के अनुरूप बनाया जा सकता है।

@simonbyrne हाँ, मैं पूरी तरह से सहमत हूँ। मैं वर्तमान do संकेतन के लिए प्रेरणा को समझता हूं लेकिन मुझे दृढ़ता से लगता है कि यह वाक्य रचना संबंधी जिमनास्टिक को सही नहीं ठहराता।

@samuela नक्शे के बारे में (f, _) बनाम सिर्फ नक्शा (f)। मैं मानता हूं कि कुछ जादू उतरना भ्रामक होगा, लेकिन मुझे लगता है कि नक्शा (एफ) कुछ ऐसा है जो मौजूद होना चाहिए। इसके लिए आवश्यकता नहीं होगी और चीनी केवल नक्शे में एक सरल विधि जोड़ें।
जैसे

map(f::Base.Callable) = function(x::Any...) map(f,x...) end

यानी मैप एक फंक्शन लेता है और फिर एक फंक्शन देता है जो उन चीजों पर काम करता है जो चलने योग्य हैं (अधिक या कम)।

आम तौर पर मुझे लगता है कि हमें उन कार्यों की ओर झुकना चाहिए जिनके पास अतिरिक्त "सुविधा" विधियां हैं, बजाय किसी प्रकार के सम्मेलन के जो |> हमेशा डेटा को पहले तर्क (या समान) के लिए मैप करते हैं।

एक ही नस में एक हो सकता है

type Underscore end
_ = Underscore()

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

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

@patrickthebold
मुझे लगता है कि x |> map(f, _) => x |> map(f, Underscore()) => x |> map(f, x) , जैसा कि आप प्रस्ताव करते हैं, map(f, _) , सही को लागू करने का सबसे सरल तरीका होगा? - बस _ एक विशेष इकाई हो, जिसके लिए आप प्रोग्राम करेंगे?

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

इसके अलावा, map लिए आपके प्रस्ताव के बारे में - मुझे यह पसंद आया। दरअसल, मौजूदा |> जो काफी उपयोगी होगा। हालांकि, मैं कल्पना यह बेहतर सरल होगा बस का स्वत: inferencing लागू करने के लिए x |> map(f, _) => x |> map(f, x) बजाय?

@StefanKarpinski समझ में आता है। यह काफी की तरह नहीं सोचा था।

कुछ भी नहीं मैंने कहा कि किसी भी तरह से |> से बंधा होगा। _ बारे में मेरा क्या मतलब है उदाहरण के लिए < तरीकों को जोड़ना होगा:

<(_::Underscore, x) = function(z) z < x end
<(x, _::Underscore) = function(z) x < z end

लेकिन फिर से मुझे लगता है कि यह एक दर्द होगा जब तक कि उचित तरीकों को स्वचालित रूप से जोड़ने का एक तरीका नहीं था।

फिर, अंडरस्कोर के साथ बात अलग है कि ऊपर बताए अनुसार मैप करने के लिए सुविधा पद्धति को जोड़ना। मुझे लगता है कि दोनों का अस्तित्व किसी न किसी रूप में होना चाहिए।

@patrickthebold अंडरस्कोर, आदि के लिए उपयोगकर्ता-परिभाषित प्रकार के साथ इस तरह का दृष्टिकोण फ़ंक्शन को लागू करते समय प्रोग्रामर पर एक महत्वपूर्ण और अनावश्यक बोझ डाल देगा। सभी 2 ^ n की सूची बनाना

f(_, x, y) = ...
f(x, _, y) = ...
f(_, _, y) = ...
...

बहुत कष्टप्रद होगा, अयोग्य का उल्लेख करने के लिए नहीं।

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

func_that_has_a_lot_of_args(a, b, c, d, e) = ...
func_that_has_a_lot_of_args(b, c, d, e) = ...
func_that_has_a_lot_of_args(a, b, e) = ...
func_that_has_a_lot_of_args(b, d, e) = ...
func_that_has_a_lot_of_args(a, d) = ...
...

और यहां तक ​​कि अगर आपने किया था, तब भी आपको फ़ंक्शन को कॉल करते समय अस्पष्टता की एक बेतुकी राशि का सामना करना पड़ेगा: क्या func_that_has_a_lot_of_args(x, y, z) उस परिभाषा को संदर्भित करता है जहां x=a,y=b,z=c या x=b,y=d,z=e , आदि। ? जूलिया रनटाइम प्रकार की जानकारी के साथ उनके बीच विचार-विमर्श करेंगे लेकिन स्रोत कोड पढ़ने वाले प्रोग्रामर के लिए यह पूरी तरह से अस्पष्ट होगा।

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

@samuela
क्या आप इसका मतलब स्पष्ट कर सकते हैं कि "लैम्बडा बनाने के लिए इसे बाहर निकालें"? - मैं उत्सुक हूँ। मैंने भी सोचा है कि इसे कैसे लागू किया जा सकता है।

@patrickthebold
ओह समझा। संभवतः आप इस तरह की चीज़ का उपयोग कर सकते हैं: filter(_ < 5, [1:10]) => [1:4] ?
व्यक्तिगत रूप से, मुझे पढ़ने के लिए filter(e -> e < 5, [1:10]) आसान मिलेगा; अधिक सुसंगत - कम छिपा हुआ अर्थ, हालांकि मैं आपको अनुदान देता हूं, यह अधिक संक्षिप्त है।

जब तक आपके पास एक उदाहरण नहीं है जहां यह वास्तव में चमकता है?

@samuela

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

मैं सुझाव नहीं दे रहा था कि यह सामान्य रूप से किया जाता है, केवल map और filter , और संभवतः कुछ अन्य स्थानों पर जहाँ यह स्पष्ट लगता है। मेरे लिए, यह है कि map को काम करना चाहिए: एक फ़ंक्शन में ले जाएं और एक फ़ंक्शन वापस करें। (पूरा यकीन है कि हास्केल क्या करता है।)

बहुत कष्टप्रद होगा, अयोग्य का उल्लेख करने के लिए नहीं।

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

@ H-225 हाँ अंडरस्कोर चीज़ केवल एक सिंटैक्टिक सुविधा है। यह निश्चित नहीं है कि यह कितना सामान्य है, लेकिन स्काला के पास यह निश्चित रूप से है। व्यक्तिगत रूप से मुझे यह पसंद है, लेकिन मुझे लगता है कि यह सिर्फ उन स्टाइल चीजों में से एक है।

@ H-225 खैर, इस मामले में मुझे लगता है कि एक सम्मोहक और प्रासंगिक उदाहरण फंक्शन चेनिंग होगा। लिखने के बजाय

[1, 2, 3, 5]
  |> x -> map(addone, x)
  |> x -> filter(isprime, x)
  |> sum
  |> x -> 3 * x
  |> ...

कोई बस लिख सकता है

[1, 2, 3, 5]
  |> map(addone, _)
  |> filter(isprime, _)
  |> sum
  |> 3 * _
  |> ...

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

जहां तक ​​मुझे पता है, वर्तमान में जूलिया में इस समस्या को दूर करने के लिए कम से कम 3.5 लाइब्रेरी / एप्रोच हैं जो जूलिया के बिलिन |> फंक्शन, पाइप.ज्ल, Lazy.jl और 0.5 जूलिया के बिलियन do अंकन जो आत्मा में समान है। इन पुस्तकालयों या दृष्टिकोणों में से किसी को भी कोसने के लिए नहीं, लेकिन जूलिया को अंडरस्कोर करी का समर्थन करने पर उनमें से कई को बहुत सरल बनाया जा सकता है।

@samuela यदि आप इस विचार के कार्यान्वयन के साथ खेलना चाहते हैं, तो आप FunctionalData.jl को आज़मा सकते हैं, जहाँ आपका उदाहरण इस तरह दिखेगा:

<strong i="7">@p</strong> map [1,2,3,4] addone | filter isprime | sum | times 3 _

पिछले भाग से पता चलता है कि इनपुट को दूसरे पैरामीटर में कैसे पाइप किया जाए (डिफ़ॉल्ट तर्क है, जिस स्थिति में _ छोड़ा जा सकता है)। प्रतिक्रिया बहुत सराहना की!

संपादित करें: ऊपर बस फिर से लिखा गया है:

times(3, sum(filter(map([1,2,3,4],addone), isprime)))

जो Base.map और फ़िल्टर के बजाय FunctionalData.map और फ़िल्टर का उपयोग करता है। मुख्य अंतर तर्क क्रम है, दूसरा अंतर अनुक्रमण सम्मेलन (डॉक्स देखें) है। किसी भी स्थिति में, बेस.मैप का उपयोग केवल तर्क क्रम को उलट कर किया जा सकता है। @p एक सरल पुनर्लेखन नियम है (बाएं से दाएं आंतरिक-बाहरी हो जाता है, साथ ही सरल करी के लिए समर्थन: <strong i="17">@p</strong> map data add 10 | showall बन जाता है

showall(map(data, x->add(x,10)))

हैक कुछ इस तरह शुरू हो सकता है: https://github.com/facebook/hhvm/issues/6455। वे $$ का उपयोग कर रहे हैं, जो जूलिया के लिए तालिका से दूर है ( $ पहले से ही अतिभारित है)।

एफडब्ल्यूआईडब्ल्यू, मुझे वास्तव में हैक का समाधान पसंद है।

मुझे यह भी पसंद है, मेरा मुख्य आरक्षण यह है कि मैं अभी भी एक तरह के एक लंबर नोटेशन की तरह होगा जो चर / स्लॉट के लिए _ उपयोग कर सकता है और यह सुनिश्चित करना अच्छा होगा कि ये संघर्ष न करें।

क्या कोई __ उपयोग नहीं कर सकता है? आप जिस लैम्बडा सिंटेक्स के बारे में सोच रहे हैं, वह क्या है? _ -> sqrt(_) ?

ज़रूर, हम कर सकते थे। यह सिंटैक्स पहले से ही काम करता है, यह एक सिंटैक्स के बारे में अधिक है जिसे तीर की आवश्यकता नहीं है, ताकि आप map(_ + 2, v) की पंक्तियों के साथ कुछ लिख सकें, वास्तविक मुद्दा आसपास के अभिव्यक्ति का कितना _ है।

क्या अनाम तर्क के लिए Mathematica के समान प्रणाली नहीं है? कैसे करें
वे उन तर्कों की सीमा के दायरे को संभालते हैं?
Tue, Nov 3, 2015 को 9:09 AM स्टीफन करपिंस्की नोटिफिकेशन @github.com पर
लिखा था:

ज़रूर, हम कर सकते थे। यह सिंटैक्स पहले से ही काम करता है, यह एक सिंटैक्स के बारे में अधिक है जो
तीर की आवश्यकता नहीं है, ताकि आप लाइनों के साथ कुछ लिख सकें
नक्शा (_ + 2, v), वास्तविक मुद्दा कितना आसपास का है
अभिव्यक्ति _ का है।

-
इस ईमेल का उत्तर सीधे दें या इसे GitHub पर देखें
https://github.com/JuliaLang/julia/issues/5571#issuecomment -153383422।

https://reference.wolfram.com/language/tutorial/PureFunctions.html , दिखा रहा है
# प्रतीक, वही है जो मैं सोच रहा था।
Tue, Nov 3, 2015 को सुबह 9:34 बजे जोनाथन मालमौद [email protected] ने लिखा:

क्या अनाम तर्क के लिए Mathematica के समान प्रणाली नहीं है? कैसे करें
वे उन तर्कों की सीमा के दायरे को संभालते हैं?
Tue, Nov 3, 2015 को 9:09 AM स्टीफन करपिंस्की नोटिफिकेशन @github.com पर
लिखा था:

ज़रूर, हम कर सकते थे। यह सिंटैक्स पहले से ही काम करता है, यह एक सिंटैक्स के बारे में अधिक है जो
तीर की आवश्यकता नहीं है, ताकि आप लाइनों के साथ कुछ लिख सकें
नक्शा (_ + 2, v), वास्तविक मुद्दा कितना आसपास का है
अभिव्यक्ति _ का है।

-
इस ईमेल का उत्तर सीधे दें या इसे GitHub पर देखें
https://github.com/JuliaLang/julia/issues/5571#issuecomment -153383422।

गणितज्ञ इसे परिसीमन करने के लिए & का उपयोग करता है।

एक छोटे से लंबोदर सिंटैक्स के रूप में सामान्य रूप से कुछ करने के बजाय (जो कि एक मनमाना अभिव्यक्ति ले सकता है और एक अनाम फ़ंक्शन वापस कर सकता है) हम स्वीकार्य अभिव्यक्तियों को फ़ंक्शन कॉल और पूरे पैरामीटर के लिए स्वीकार्य चर / स्लॉट्स को परिभाषित करके सीमांकक समस्या के आसपास प्राप्त कर सकते हैं। यह हमें एक बहुत ही साफ-सुथरा मल्टी-पैरामीटर क्यूरिंग सिंटेक्स आ ला ओपन डायलन देगा । क्योंकि _ पूरे मापदंडों को बदल देता है, वाक्यविन्यास न्यूनतम, सहज और अस्पष्ट हो सकता है। map(_ + 2, _) x -> map(y -> y + 2, x) अनुवाद होगा। अधिकांश गैर-फ़ंक्शन कॉल अभिव्यक्तियाँ जिन्हें आप लंबूफी करना चाहते हैं, वे शायद -> या do वैसे भी अधिक मिलनसार होंगे। मुझे लगता है कि प्रयोज्यता बनाम सामान्यता का व्यापार बंद होगा।

@ डर्कन , जो आशाजनक लगता है - क्या आप नियम पर थोड़ा विस्तार कर सकते हैं? पहले क्यों _ के तर्क के अंदर रहने map , जबकि दूसरा एक पूरे खपत map अभिव्यक्ति? मुझे स्पष्ट नहीं है कि "कॉल करने के लिए स्वीकार्य अभिव्यक्तियों को परिभाषित करने का क्या मतलब है", और न ही "पूरे सिस्टम के लिए स्वीकार्य चर / स्लॉट्स को सीमित करना" ...

ठीक है, मुझे लगता है कि मुझे नियम मिलता है, उस डायलन प्रलेखन में से कुछ को पढ़ते हुए, लेकिन मुझे map(_ + 2, v) काम करने के बारे में आश्चर्य करना होगा लेकिन map(2*_ + 2, v) काम नहीं करना चाहिए।

वहाँ भी बहुत नाईपिक व्यवसाय है कि इसका मतलब है कि _ + 2 + _ का मतलब (x,y) -> x + 2 + y जबकि _ ⊕ 2 ⊕ _ का मतलब y -> (x -> x + 2) + y क्योंकि + और * एकमात्र ऑपरेटर हैं जो वर्तमान में युग्मक सहयोगी कार्यों के बजाय बहु-तर्क फ़ंक्शन कॉल के रूप में पार्स करते हैं। अब, यह तर्क दिया जा सकता है कि इस विसंगति को ठीक किया जाना चाहिए, हालांकि ऐसा लगता है कि _parser_ को एक राय होगी कि कौन से ऑपरेटर सहयोगी हैं और जो नहीं हैं, जो बुरा लगता है। लेकिन मैं तर्क दूंगा कि किसी भी योजना के लिए यह जानना आवश्यक है कि क्या पार्सर a + b + c एकल फ़ंक्शन कॉल या नेस्टेड कॉल कुछ संदिग्ध हो सकता है। शायद infix संकेतन विशेष रूप से नियंत्रित किया जाना चाहिए? लेकिन नहीं, वह भी गड़बड़ लगता है।

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

2*_ |> 2+_ |> map(_, v)

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

_ ⊕ 2 ⊕ _    # y -> (x -> x + 2) + y
_ ⊕ 2 ⊕ _ &  # (y , x) -> x + 2 + y

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

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

हाँ, मुझे यह पसंद है सिवाय infix चीज़ के। वह हिस्सा निश्चित हो सकता है।

खैर, इनफ़िक्स पोज़िशन में करीने से वाक्य रचना त्रुटि हो सकती है:

map(+(*(2, _), 2), v)      # curry is OK syntax, but obviously not what you wanted
map(2*_ + 2, v)            # ERROR: syntax: infix curry requires delimitation
map(2*_ + 2 &, v)          # this means what we want
map(*(2,_) |> +(_,2), v)   # as would this

यह एक चेतावनी भी हो सकती है जिसका मुझे अनुमान है।

इस करीने को बुलाते हुए, मुझे भ्रमित और गलत के रूप में मारता है।

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

मैं कुछ इस तरह से सोच रहा हूँ:

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

उदाहरण:

• f(_, b) → x -> f(x, b)
• f(a, _) → x -> f(a, x)
• f(_, _) → (x, y) -> f(x, y)
• 2_^2 → x -> 2x^2
• 2_^_ → (x, y) -> 2x^y
• map(_ + 2, v) → map(x -> x + 2, v)
• map(2_ + 2, v) → map(x -> 2x + 2, v)
• map(abs, _) → x -> map(abs, x)
• map(2_ + 2, _) → x -> map(y -> 2y + 2, x)
• map(2_ - _, v, w) → map((x, y) -> 2x - y, v, w)
• map(2_ - _, v, _) → x -> map((y, z) -> 2y - z, v, x)
• map(2_ - _, _, _) → (x, y) -> map((z, w) -> 2z - w, x, y)
• _ → x -> x
• map(_, v) → x -> map(x, v)
• map((_), v) → map(x -> x, v)
• f = _ → f = x -> x
• f = 2_ → f = x -> 2x
• x -> x^_ → x -> y -> x^y
• _ && _ → (x, y) -> x && y
• !_ && _ → (x, y) -> !x && y

केवल यही स्थान पासा शुरू होता है सशर्त - उन उदाहरणों को बस अजीब तरह का मिलता है।

यह अभी भी कुछ हद तक काल्पनिक और अप्रत्याशित है और कोने के मामले हैं, लेकिन मैं कहीं जा रहा हूं।

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

उदाहरण जो मुझे थोड़ा कम खुश करते हैं:

• 2v[_] → x -> 2v[x] (अच्छा)
• 2f(_) → 2*(x -> f(x)) (इतना अच्छा नहीं)
• _ ? "true" : "false" → (x -> x) ? "true" : "false"
• _ ? _ : 0 → (x -> x) ? (y -> y) : 0

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

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

मुझे लगता है कि आप ऐसा मामला भी बना सकते हैं जो _unfamiliar_ की पसंद का हो
अनिवार्य रूप से एकल-प्रेषण डॉट ऑपरेटर के बजाय कई प्रेषण
को मजबूर करने के लिए निर्णय सुनाई तर्क के लिए संक्षिप्त वाक्यविन्यास है
SVO ऑर्डर को पुनर्प्राप्त करना जिसे लोग _are_ से परिचित करते हैं।

टीयू पर, 17 नवंबर, 2015 को 12:09 बजे स्टीफन करपिंस्की सूचनाएं @github.com
लिखा था:

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

-
इस ईमेल का उत्तर सीधे दें या इसे GitHub पर देखें
https://github.com/JuliaLang/julia/issues/5571#issuecomment -157437223।

यह विशेष रूप से बूस्ट में कई पुस्तकालय समाधानों के साथ C ++ में मौजूद है, जो _1, _2, _3 उपयोग तर्कों के रूप में करते हैं (जैसे _1(x, y...) = x , _2(x, y, z...) = y आदि), वह सीमा जो होने में सक्षम हो कॉल जैसे fun(_1) x -> fun(x) , fun को लाइब्रेरी के साथ स्पष्ट रूप से संगत बनाया जाना चाहिए (आमतौर पर मैक्रो कॉल के माध्यम से, fun एक "लैम्ब्डा प्रकार" स्वीकार करना "एक पैरामीटर के रूप में)।

मैं वास्तव में जूलिया में उपलब्ध इस कविता लैंबडा नोटेशन को पसंद करूंगा।
की समस्या के संबंध में 2f(_) करने के लिए desugaring 2*(x -> f(x)) : यह मतलब होगा "पहला नियम लागू होता है अगर, के लिए उदाहरण के लिए, की तर्ज पर नियम संशोधित करने के लिए f(_) , तो फिर से साथ रिकर्सिवली नियमों का मूल्यांकन f(_) की भूमिका निभा _ । यह अनुमति होगी भी जैसे f(g(_)) → x -> f(g(x)) , "कोष्ठकों नियम" के साथ करने के लिए आसानी से की अनुमति देता है वांछित स्तर पर रुकें, जैसे f((g(_))) → f(x->g(x)) ।

मुझे इसके लिए "terse lambda अंकन" नाम बहुत पसंद है। (करी से बहुत बेहतर)।

मैं वास्तव में _1 , _2 , _3 अन्वेषण करना पसंद करूंगा यदि आपके पास बहु-तर्क लंबोदा हैं। सामान्य तौर पर मैं अक्सर एक ही दायरे में चर नामों का पुन: उपयोग करता हुआ भ्रमित हो सकता हूं ... और _ होना x और y में समान अभिव्यक्ति_ सिर्फ पागल भ्रामक लगता है।

मैंने पाया है यह एक ही ट्रिक स्केला _ -syntax ने थोड़ा भ्रम पैदा कर दिया है ( स्कैला में _ के सभी उपयोग देखें)।

इसके अलावा, अक्सर आप करना चाहते हैं:

x -> f(x) + g(x)

या इसी तरह, और मुझे लगता है कि अगर निम्नलिखित काम नहीं किया तो मुझे आश्चर्य होगा:

f(_) + g(_)

इसके अलावा आप तर्कों के क्रम को बदलना चाह सकते हैं:

x, y -> f(y, x)
f(_2, _1)  # can't do with other suggested _ syntax

मुझे लगता है कि स्पष्ट रूप से अनाम तर्क संख्या ( _1 , _2 , _3 ... आदि) के लिए अनुमति देना वाक्यविन्यास के लिए ठीक होगा, लेकिन मुख्य समस्या अभी भी खड़ी है। : जब आप आंशिक रूप से लागू फ़ंक्शन को एक लंब मेमने में बढ़ावा देते हैं? और वास्तव में लैम्ब्डा शरीर क्या है? मैं संभवतः किसी प्रकार के जटिल पदोन्नति नियमों का उपयोग करने के बजाय स्पष्ट (एक सीमांकक के साथ) होने के पक्ष में त्रुटि करूंगा। क्या चाहिए

foo(_1, _1 + _2  + f(_1, v1) + g(_2, v3), _3 * _2, v2) + g(_4, v4) +
 f(_2, v2) + g(_3, v5) + bar(_1, v6)

वास्तव में मतलब है? एक सीमांकक का उपयोग करना (मैं λ उपयोग करूंगा) चीजें कुछ अधिक स्पष्ट हैं:

λ(foo(_1, λ(_1 + _2)  + λ(f(_1, v1) + g(_2, v3)), _3 * _2, v2) + g(_4, v4)) + 
λ(f(_2, v2) + g(_3, v5) + bar(_1, v6))

यह स्पष्ट रूप से एक MethodError: + has no method matching +(::Function, ::Function) , लेकिन कम से कम मैं यह बता सकता हूं कि जिस तरह से यह लिखा गया है।

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

यह निश्चित रूप से terseness बनाम सामान्यता और सुगम्यता के बीच एक व्यापार है। बेशक ऐसा कुछ पेश करने का कोई मतलब नहीं है जो मौजूदा -> नोटेशन से कम है। लेकिन मुझे यह भी लगता है कि एक परिसीमन सार्थक लगता है।

शायद यह पर्याप्त नहीं है, लेकिन -> उपसर्ग संस्करण के बारे में कैसे _ तर्क है? उदाहरण के लिए

(-> 2f(_) + 1)

मुझे लगता है कि उपसर्ग फॉर्म में बहुत कम पूर्वता होनी चाहिए। यह वास्तव में किसी मामले में कोष्ठकों को छोड़ने की अनुमति दे सकता है, जैसे

map(->_ + 1, x)

अभी मैं https://github.com/JuliaLang/julia/issues/5571#issuecomment -157424665 को लागू करने के साथ खिलवाड़ कर रहा हूँ

मैक्रो के रूप में, जो इस तरह की सभी घटनाओं को लाइन में बदल देता है।
मुश्किल हिस्सा पूर्वता को लागू कर रहा है।

मैं शायद इसे अगले 12 घंटों में समाप्त नहीं करूँगा क्योंकि यह यहाँ lhome समय है
(शायद अगले 24 में, लेकिन मुझे दूर जाना पड़ सकता है)
वैसे भी, एक बार जो किया जाता है हम उसके साथ खेल सकते हैं।

एक अजीब सा जो https://github.com/JuliaLang/julia/issues/5571#issuecomment -157424665 से निकलता है

• f(_,_) → x,y -> f(x,y) (यह उचित है)
• f(_,2_) → ??
  
  
  
  • f(_,2_) → x,y -> f(x,2y) (उचित)
  
  
  • f(_,2_) → x-> f(x,y->2y) (मुझे क्या लगता है कि शासन सुझाव दे रहा है, और मेरा प्रोटोटाइप क्या है)
  
  

लेकिन मुझे यकीन नहीं है कि मेरे पास यह सही है।

तो यहाँ मेरा प्रोटोटाइप है।
http://nbviewer.ipython.org/gist/oxinabox/50a1e17cfb232a7d1908

वास्तव में यह निश्चित रूप से कुछ परीक्षणों में विफल रहता है।

वर्तमान एएसटी परत में ब्रैकेटिंग पर विचार करना संभव नहीं है - वे अक्सर (हमेशा?) पहले से ही हल हो जाते हैं।

फिर भी मेरे विचार से खेलना पर्याप्त है

R में magrittr के कुछ नियम जो उपयोगी हो सकते हैं:

यदि एक श्रृंखला के साथ शुरू होता है। , यह एक अनाम फ़ंक्शन है:

. %>% `+`(1)

फ़ंक्शन (x) x + 1 के समान है

पीछा करने के दो तरीके हैं:
1) पहले तर्क, साथ ही दिखाई देने वाले किसी भी बिंदु के रूप में सम्मिलित करके जंजीर।
2) केवल दिखाई देने वाले डॉट्स तक जंजीर।

डिफ़ॉल्ट मोड 1 मोड है। हालाँकि, यदि फ़ंक्शन जंजीर होने के लिए एक तर्क के रूप में डॉट अपने आप प्रकट होता है, तो मैग्रिट्रर श्रृंखला में उस चरण के लिए मोड 2 पर स्विच करता है।

इसलिए

2 %>% `-`(1) 

2 है - 1,

तथा

1 %>% `-`(2, . )

यह भी 2 - 1 है

मोड 2 को कोष्ठक में लपेटकर भी निर्दिष्ट किया जा सकता है:

2 %>% { `-`(2, . - 1) }

2 - (2 - 1) के समान होगा।

इसके अलावा सिर्फ एक नोट जो चालाकी से मोड 1 और मोड 2 के बीच स्विच करने में सक्षम है, लगभग पूरी तरह से इस समस्या को हल करता है कि जूलिया तर्क के बारे में बहुत सुसंगत नहीं है जो संभवतः पहली स्थिति में जंजीर हो जाएगी। मैं यह भी भूल गया कि कोष्ठक कोड के मूल्यांकन के लिए अनुमति दे सकता है। यहाँ मैग्रिट्र मैनुअल से एक उदाहरण दिया गया है:

आईरिस%>%
{
एन <- नमूना (1:10, आकार = 1)
एच <- सिर (?, एन)
टी <- पूंछ (?, एन)
rbind (H, T)
}%>%
सारांश

यह इस समय केवल एक आधा-निर्मित विचार है, लेकिन मुझे आश्चर्य है कि अगर कोई ऐसा तरीका है जिससे हम एक ही समय में "ट्रू लैंबडा" और "डमी वैरिएबल" मुद्दों को हल कर सकते हैं, तो टपल निर्माता को संशोधित करके ऐसा किया जाता है कि एक लापता मान वापस आ जाता है लैम्ब्डा जो एक ट्यूपल के बजाय एक ट्यूपल लौटाता है? तो, (_, 'b', _, 4) (x, y) -> (x, 'b', y, 4) वापस हो जाएंगे।

फिर, यदि हम फ़ंक्शन कॉलिंग के शब्दार्थ को सूक्ष्मता से बदलते हैं, तो foo(a, b) अर्थ है " foo को Tuple (a, b) या यदि तर्क एक फ़ंक्शन है, तो foo लागू करें foo(_, b, c)(1) apply(foo, ((x) -> (x, b, c))(1)) बराबर होगा।

मुझे लगता है कि यह अभी भी infix संकेतन मुद्दे को हल नहीं करता है, लेकिन व्यक्तिगत रूप से मैं ट्रिब लैंबडस के साथ खुश रहूंगा जो केवल कोष्ठक फ़ंक्शन कॉल के साथ काम करते हैं। सब के बाद, 1 + _ हमेशा +(1, _) फिर से लिखा जा सकता है यदि आवश्यक हो।

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

@samuela से मेरा तात्पर्य यह है कि foo(a, b) foo((a, b)...) बराबर है। यही है, एक फ़ंक्शन के तर्कों को वैचारिक रूप से टुपल के रूप में सोचा जा सकता है, भले ही टुपल का अभ्यास में कभी निर्माण न किया गया हो।

@ मैं इस चर्चा के माध्यम से पढ़ने की कोशिश की है, लेकिन मेरे लिए यह बहुत लंबा है कि जो कुछ भी कहा गया है, उस पर नज़र रखें - अगर मैं यहाँ ज़रूरत से ज़्यादा दोहरा रहा हूँ तो क्षमा करें।

मैं |> को do "जादू" का पूरक बनाने के लिए एक वोट डालना चाहूंगा। जहां तक ​​मैं देख सकता हूं, ऐसा करने का सबसे आसान तरीका यह होगा कि इसका मतलब यह हो

3 |> foo == foo(3) # or foo() instead of just foo, but it would be nice if the parentheses were optional
3 |> foo(1) == foo(1, 3)
3 |> foo(1,2) == foo(1,2,3)

दूसरे शब्दों में, a |> f(x) _last_ से तर्क करता है कि f(x) do; a; end _reirst_ से क्या करता है। यह तुरंत map , filter , all , any et के साथ संगत कर देगा। अल।, _ पैरामीटर को स्कोपिंग की जटिलता को जोड़ने के बिना, और पहले से ही मौजूद do सिंटैक्स दिया गया मुझे नहीं लगता कि यह कोड के पाठकों पर एक अनुचित वैचारिक बोझ डालता है।

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

वह @>> मैक्रो https://github.com/MikeInnes/Lazy.jl से है।

@ लालमुद नाइस! मुझे यह पसंद है कि यह पहले से ही संभव है: डी

हालांकि, इन दो वेरिएंट के बीच पठनीयता में अंतर वास्तव में बड़ा है:

# from Lazy.jl
@> x g f(y, z)

# if this became a first-class feature of |>
x |> g |> f(y, z)

मुझे लगता है कि मुख्य पठनीयता समस्या यह है कि यह बताने के लिए कोई दृश्य सुराग नहीं हैं कि अभिव्यक्तियों के बीच की सीमाएँ कहाँ हैं - x g और g f(x, में रिक्त स्थान कोड के व्यवहार को महत्वपूर्ण रूप से प्रभावित करेंगे, लेकिन स्थान f(x, y) में नहीं होगा।

चूँकि @>> पहले से मौजूद है, |> इस व्यवहार को 0.5 में

(मैं ऑपरेटर की संकेतन पर बहुत अधिक ऊर्जा खर्च नहीं करना चाहता, इसलिए इस प्रस्ताव को केवल संकेतन के मामले पर खारिज नहीं करता। हालांकि, हम ध्यान दें कि "पाइपिंग" इस के लिए एक प्राकृतिक धारणा की तरह लगता है (सीएफ) शब्द "संग्रह पाइपलाइन"), और जैसे कि F # पहले से ही इसके लिए |> का उपयोग करता है, हालांकि निश्चित रूप से इसमें F # कार्य थोड़े अलग हैं क्योंकि जूलिया फ़ंक्शन भिन्न हैं।)

हां, यकीन है कि मैं पठनीयता के मोर्चे पर सहमत हूं। यह तकनीकी रूप से चुनौतीपूर्ण नहीं होगा कि आप |> 0.5 का

इसी तरह, Lazy.jl के @>> मैक्रो पार्स फ़ंक्शंस को |> जंजीर बनाना संभव होगा।

हम्म। मैं तो Lazy.jl के लिए एक पीआर पर काम करना शुरू कर दूंगा, लेकिन इसका मतलब यह नहीं है कि मैं यह 0.5 में नहीं होना चाहूंगा :) मुझे नहीं लगता कि मैं जूलिया पार्सर के बारे में पर्याप्त जानता हूं और हालांकि, जब तक मुझे कुछ बहुत व्यापक सलाह नहीं मिलती, तब तक |> के व्यवहार को कैसे बदला जाए।

मुझे नहीं लगता कि मैंने इस धागे में उल्लेख किया है, लेकिन मेरे पास एक और चेनिंग पैकेज है, ChainMap.jl। यह हमेशा _ में प्रतिस्थापित करता है, और सशर्त रूप से पहले तर्क में सम्मिलित होता है। यह मैपिंग को एकीकृत करने की भी कोशिश करता है। Https://github.com/bramtayl/ChainMap.jl देखें

तो विभिन्न प्रयासों आदि की हमारी वर्तमान सूची
मुझे लगता है कि यह लोगों की जाँच करने के लायक है, (आदर्श रूप से राय से पहले, लेकिन w / e)
वे सभी थोड़े अलग हैं।
(मैं कालानुक्रम में आदेश देने का प्रयास कर रहा हूं)।

संकुल

• माइकइन्स का लेज़ी.ज्ल ।
• rened's FunctionalData.jl
• oxinabox's पाइप .jl
• Bramtayl's ChainMap.jl (पदावनत)
• Bramtayl की ChainRecursive.jl (पदावनत)
• FNj की नली ।jl
• c42f की मैजिकयून्डर्सकोर्स.ज्ल
• c42f का अंडरस्कोर .jl
• Bramtayl का लाइटव्यू

नॉनपैकेज प्रोटोटाइप

• kmsquires की रचना मार्को
• पोर्टरजम्सज के थ्रेडिंग मैक्रो
• ऑक्सिनाबॉक्स की कविता लम्बदा - @StefanKarpinski के https://github.com/JuliaLang/julia/issues/5571#issuecomment -157424665 से
• fcard के GeneratedPartials - उदाहरण

सम्बंधित:

• एंडीफ्रिस के फंक्शन कंपोजिशन ऑपरेटर, पीआर
• माइकइन्स का फ्लो .jl

शायद इसे शीर्ष पदों में से एक में संपादित किया जाना चाहिए।

अपडेट किया गया: 2020-04-20

यह आंशिक अनुप्रयोग को लागू करने के लिए वास्तविक प्रयास की तुलना में एक प्रकार का प्रणाली प्रयोग है, लेकिन यहां एक अजीब है: https://gist.github.com/fcard/b48513108a32c13a49a387a3c530f7de

उपयोग:

include("partial_underscore_generated.jl")
using GeneratedPartial

const sub = partialize(-)
sub(_,2)(1) == 1-2
sub(_,_)(1,2) == 1-2
sub(_,__)(1)(2) == 1-2
sub(__,_)(2)(1) == 1-2 #hehehe

# or
<strong i="8">@partialize</strong> 2 Base.:+ # evily inserts methods in + and allows partializations for 2 arguments
(_+2)(1) == 1+2

# fun:
sub(1+_,_)(2,3) == sub(1+2,3)
sub(1+_,__)(2)(3) == sub(1+2,3)
(_(1)+_)(-,1) == -1+1

# lotsafun:
appf(x::Int,y::Int) = x*y
appf(f,x) = f(x)
<strong i="9">@partialize</strong> 2 appf

appf(1+_,3)(2) == appf(1+2,3)
appf(?(1+_),3) == appf(x->(1+x), 3)
appf(?sub(_,2),3) == appf(x->x-2,3) # I made a method *(::typeof(?),::PartialCall), what of it!!?

# wooooooooooooooooooooooooooooooooo
const f = sub
f(_,f(_,f(_,f(_,f(_,f(_,f(_,f(_,f(_,_)))))))))(1,2,3,4,5,6,7,8,9,10) == f(1,f(2,f(3,f(4,f(5,f(6,f(7,f(8,f(9,10)))))))))
f(_,f(__,f(___,f(____,f(_____,f(______,f(_______,f(________,f(_________,__________)))))))))(1)(2)(3)(4)(5)(6)(7)(8)(9)(10) == f(1,f(2,f(3,f(4,f(5,f(6,f(7,f(8,f(9,10)))))))))

# this answers Stefan's concern (which inspired me to make this hack in the first place)
#
#    const pmap = partialize(map)
#    map(f(_,a),   v) == map(x->f(x,a), v)
#    pmap(?f(_,a), v) == map(x->f(x,a), v)
#    pmap(f(_,a),  v) == x->map(f(x,a), v)
#
# it adds a few other issues, of course...

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

PS यह उल्लेख करना भूल गया कि @partialize पूर्णांक सरणी के साथ भी काम करता है:

<strong i="15">@partialize</strong> 2:3 Base.:- # partialized for 2 and 3 arguments!

(_-_-_)(1,2,3) == -4
(_-_+_)(1,2,3) == +2

ठीक है, मैं फंक्शन कंपोजिशन के बारे में सोच रहा हूं, और हालांकि IMO SISO मामले में स्पष्ट है, मुझे लगता है कि मैं सोच रहा था कि मैं छोटे जंजीर कोड ब्लॉक में जूलिया के MISO (अर्ध-एमआईएमओ?) का उपयोग कैसे करूं।

मुझे आरईपीएल पसंद है। बहुत। यह प्यारा है, यह अच्छा है, यह आपको MATLAB या अजगर या शेल की तरह प्रयोग करने देता है। मुझे एक पैकेज या फ़ाइल से कोड लेना और उसे REPL में कॉपी-पेस्ट करना, यहां तक ​​कि कोड की कई लाइनें भी पसंद हैं। आरईपीएल हर लाइन पर मूल्यांकन करता है और मुझे दिखाता है कि क्या चल रहा है।

यह हर एक्सप्रेशन के बाद ans भी रिटर्न / डिफाइन करता है। प्रत्येक MATLAB उपयोगकर्ता इसे जानता है (हालांकि इस स्तर पर, यह एक बुरा तर्क है!)। संभवतः अधिकांश जूलिया उपयोगकर्ताओं ने इसे पहले देखा / उपयोग किया है। मैं उन विषम परिस्थितियों में ans का उपयोग करता हूं, जो मैं कुछ टुकड़ा-वार के साथ खेल रहा हूं, यह महसूस करते हुए कि मैं ऊपर लिखे एक और कदम को जोड़ना चाहता हूं। मुझे यह नापसंद है कि इसका उपयोग करना विनाशकारी है, इसलिए मैं जब संभव हो तो इसे टाल देता हूं, लेकिन _every_ प्रस्ताव यहां रचना के केवल एक चरण की वापसी के साथ काम कर रहा है।

मेरे लिए, _ जादुई होना सिर्फ _odd_ है, लेकिन मैं समझता हूं कि बहुत से लोग असहमत हो सकते हैं। इसलिए, यदि मैं REPL में पैकेज से कोड कॉपी-पेस्ट करने के लिए _want_ करता हूं और इसे देखता हूं, और अगर मुझे ऐसा सिंटैक्स चाहिए जो जादुई नहीं लगता है, तो मैं प्रस्ताव कर सकता हूं:

<strong i="12">@repl_compose</strong> begin
   sin(x)
   ans + 1
   sqrt(ans)
end

यदि फ़ंक्शन कई आउटपुट देता है, तो मैं अगली पंक्ति में ans[1] , ans[2] , आदि सम्मिलित कर सकता हूं। यह पहले से ही जूलिया के MISO मॉडल के कंपोज़िशन मॉडल के सिंगल-लेवल को बहुत अच्छी तरह से फिट करता है, और यह पहले से ही बहुत मानक जूलिया सिंटैक्स_, फाइलों में नहीं।

मैक्रो को लागू करना आसान है - बस Expr(:block, exprs...) को Expr(:block, map(expr -> :(ans = $expr), exprs) ( let ans एक

वैसे भी, बस मेरा दृष्टिकोण! यह एक लंबा धागा था, जिसे मैंने लंबे समय में नहीं देखा था!

यह हर एक्सप्रेशन के बाद ans भी लौटाता है / परिभाषित करता है। प्रत्येक MATLAB उपयोगकर्ता इसे जानता है (हालांकि इस स्तर पर, यह एक बुरा तर्क है!)।

असल में, दूसरा तर्क यह है कि यदि _ का उपयोग फंक्शन चेंजिंग में किया जाता है, तो REPL को _ बजाय ans (मेरे लिए) लौटाना चाहिए, यह निकालने के लिए पर्याप्त होगा जादू")।

भाषाओं में "मूल्य" के रूप में _ का उपयोग करने के लिए उचित मात्रा है। बेशक, यह एक नाम के रूप में _ का उपयोग करने के प्रस्तावित विचार के साथ संघर्ष करता है जो असाइनमेंट और terser lambdas के लिए।

मुझे पूरा यकीन है कि यह Lazy.jl में कहीं न कहीं <strong i="5">@as</strong> and begin ... रूप में मौजूद है

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

type Track
  hit::Array{Hit}
end
type Event
  track::Array{Track}
end

event.track[12].hit[43]

मुझे एक घटना के 12 वें ट्रैक की 43 वीं हिट देता है जब track और hit सरल सरणियाँ होती हैं, इसलिए

event.getTrack(12).getHit(43)

अगर वे गतिशील रूप से परोसा जाना है तो मुझे वही देना चाहिए। मैं कहना नहीं चाहता

getHit(getTrack(event, 12), 43)

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

मैं अब यह लिख रहा हूं क्योंकि मैंने सिर्फ रस्ट के लक्षणों के बारे में सीखा structs (Julia type ) है, लेकिन तब उनके पास impl को struct के नाम पर बाइंडिंग फ़ंक्शंस के लिए भी है। जहाँ तक मैं बता सकता हूँ, यह शुद्ध संश्लिष्ट चीनी है, लेकिन यह ऊपर वर्णित डॉट नोटेशन की अनुमति देता है:

impl Event {
  fn getTrack(&self, num: i32) -> Track {
    self.track[num]
  }
}

impl Track {
  fn getHit(&self, num: i32) -> Track {
    self.track[num]
  }
}

जो जूलिया में हो सकता है

impl Event
  function getTrack(self::Event, num::Int)
    self.track[num]
  end
end

impl Track
  function getHit(self::Track, num::Int)
    self.hit[num]
  end
end

ऊपर प्रस्तावित वाक्यविन्यास self की कोई व्याख्या नहीं करता है: यह सिर्फ एक फ़ंक्शन तर्क है, इसलिए कई प्रेषण के साथ कोई विवाद नहीं होना चाहिए। यदि आप self की न्यूनतम व्याख्या करना चाहते हैं, तो आप पहले तर्क के प्रकार को निहित कर सकते हैं, ताकि उपयोगकर्ता को ::Event और ::Track लिखना न पड़े प्रत्येक फ़ंक्शन में, लेकिन कोई व्याख्या नहीं करने के बारे में एक अच्छी बात यह है कि "स्थिर तरीके" impl में केवल कार्य हैं, जिनमें self । (जंग new कारखानों के लिए उनका उपयोग करता है।)

रस्ट के विपरीत, जूलिया के पास types पर पदानुक्रम है। यह कोड डुप्लीकेशन से बचने के लिए impls पर समान पदानुक्रम भी हो सकता है। एक मानक OOP डेटा type और विधि impl पदानुक्रम बनाकर बनाया जा सकता है, लेकिन यह सख्त मिररिंग आवश्यक नहीं है और कुछ मामलों में अवांछनीय है।

इसके साथ एक चिपचिपा बिंदु है: मान लीजिए मैंने अपने कार्यों का नाम track और hit impl , बजाय getTrack और getHit । इसलिए कि उन्होंने track और hit type बकाया track साथ संघर्ष किया। फिर event.track सरणी या फ़ंक्शन लौटाएगा? यदि आप इसे तुरंत एक फ़ंक्शन के रूप में उपयोग करते हैं, तो यह स्पष्ट करने में मदद कर सकता है, लेकिन types Function ऑब्जेक्ट भी पकड़ सकता है। शायद बस एक कंबल नियम लागू करें: डॉट के बाद, पहले इसी impl जाँच करें, फिर इसी type ?

दूसरे विचार पर, वैचारिक रूप से एक ही वस्तु ( type और impl ) के लिए दो "पैकेज" होने से कैसे बचें, इस बारे में:

function Event.getTrack(self, num::Int)
  self.track[num]
end

फ़ंक्शन को बांधने के लिए getTrack प्रकार के उदाहरणों के लिए Event ऐसे

myEvent.getTrack(12)

(myEvent, 12) लिए लागू फ़ंक्शन के रूप में समान बाइटकोड देता है?

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

@jpivarski क्या कोई कारण है जो आपको लगता है कि डॉट सिंटैक्स (जो, इस धागे को पढ़कर, बहुत सारे नुकसान हैं) कुछ अन्य निर्माणों की तुलना में बेहतर है जो चैनिंग की अनुमति देता है? मैं अभी भी do तरह कुछ बनाने के बारे में सोचता हूं, |> ) आगे का सबसे अच्छा तरीका होगा:

event |> getTrack(12) |> getHit(43)

मुख्य कारण मैं देख सकता हूं कि रस्ट के दृष्टिकोण की तरह कुछ बेहतर हो सकता है कि यह प्रभावी ढंग से कार्यों के लिए नाम स्थान के रूप में बाएं हाथ का उपयोग करता है, इसलिए आप मौजूदा के साथ संघर्ष किए बिना parser.parse जैसे काम करने में सक्षम हो सकते हैं। जूलिया Base.parse फ़ंक्शन। मैं जंग प्रस्ताव और हैक शैली पाइपिंग दोनों प्रदान करने के पक्ष में होगा।

@tlycken यह अस्पष्ट सिंटैक्स है, हालांकि पूर्वता पर निर्भर करता है।
के बारे में याद रखना।
(न ही सुझाए गए अन्य विकल्पों में से कई करें।)

विचार करें

foo(a,b) = a+b
foo(a) = b -> a-b

2 |> foo(10) == 12   #Pipe Precedence > Call Precedence 
2 |> foo(10) == 8     #Pipe Precedence < Call Precedence   

@oxinabox मैं वास्तव में इसे "सिर्फ" एक नियमित ऑपरेटर होने का सुझाव नहीं दे रहा हूं, बल्कि भाषा का एक सिंटैक्स तत्व है; 2 |> foo(10) desugars से foo(10, 2) उसी तरह foo(10) do x; bar(x); end desugars से foo(x -> bar(x), 10) । इसका मतलब है कि कॉल मिसाल (जो मुझे लगता है, वह है जो कि वैसे भी सबसे अधिक समझ में आता है) पर पाइप की मिसाल है।

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

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

दोनों नेमस्पेस डॉट्स (मेरा दूसरा सुझाव) और |> जोड़ना मेरे द्वारा ठीक रहेगा; वे उद्देश्य और प्रभाव में अलग-अलग हैं, इस तथ्य के बावजूद कि वे दोनों धाराप्रवाह के लिए इस्तेमाल किए जा सकते हैं। हालांकि, |> जैसा कि ऊपर वर्णित है, do साथ पूरी तरह से सममित नहीं है, क्योंकि do को एक फ़ंक्शन होने के लिए तर्क की आवश्यकता होती है। यदि आप event |> getTrack(12) |> getHit(43) कह रहे हैं, तो |> गैर-फ़ंक्शंस ( Events और Tracks ) पर लागू होता है।

यदि आप event |> getTrack(12) |> getHit(43) कह रहे हैं, तो |> गैर-फ़ंक्शंस ( Events और Tracks ) पर लागू होता है।

वास्तव में, नहीं - यह फ़ंक्शन में लागू होता है _ अपने दाएं_ को फ़ंक्शन कॉल के अंतिम तर्क के रूप में अपने बाएं ऑपरेंड को सम्मिलित करके। event |> getTrack(12) getTrack(12, event) है जो दाईं ओर था, इसलिए नहीं कि बाईं तरफ क्या था।

इसका मतलब है कि ए) फ़ंक्शन कॉल पर पूर्ववर्तीता (क्योंकि यह कॉल का पुनर्लेखन है), और बी) लेफ्ट-टू-राइट एप्लिकेशन ऑर्डर ( getHit(43, getTrack(12, event)) बजाय getHit(43, getTrack(12), event) ) ।

लेकिन getTrack's हस्ताक्षर है

function getTrack(num::Int, event::Event)

इसलिए यदि event |> getTrack(12) event getTrack's अंतिम तर्क में है, तो यह Event को दूसरे तर्क में डाल रहा है, न कि Function । मैंने सिर्फ do और पहले तर्क के साथ समकक्ष की कोशिश की, और जूलिया 0.4 ने शिकायत की कि तर्क को एक फ़ंक्शन होने की आवश्यकता है। (संभवतः क्योंकि do event end एक समारोह लौटने के रूप में व्याख्या की है event , बजाय event ही।)

फंक्शन चिनिंग मुझे लगता है, जो डॉट ( . सिंटैक्स) के आसपास चर्चा की जा रही है, उससे बहुत अलग मुद्दा है। उदाहरण के लिए, @jpivarski , आप पहले से ही जूलिया में रस्ट से जो कुछ भी उल्लेख करते हैं, उसे बिना किसी नई सुविधाओं के पूरा कर सकते हैं:

type TownCrier
  name::AbstractString
  shout::Function

  function TownCrier(name::AbstractString)
    self = new(name)
    self.shout = () -> "HELLO, $(self.name)!"
    self
  end
end

tc = TownCrier("Josh")
tc.shout()                                #=> "HELLO, Josh!"
tc.name = "Bob"
tc.shout()                                #=> "HELLO, Bob!"

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

@andyferris मैं पायथन का उपयोग कर रहा हूं और मुझे वास्तव में _ पिछले अभिव्यक्ति के परिणाम का उल्लेख करना पसंद है। यह हालांकि कार्यों के अंदर काम नहीं करता है। यह बहुत अच्छा होगा यदि हम इसे कहीं भी काम करने के लिए प्राप्त कर सकते हैं: अंदर ब्लॉक, फ़ंक्शन आदि शुरू करें।

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

begin
    1
    vcat(_, 2)
    vcat(3, _)
end

# [3, 1, 2]

जैसा कि @MikeInnes ने उल्लेख किया है, यह पहले से ही @_ में उपलब्ध है (और यद्यपि यह मूल रूप से काम नहीं करता था, ChainMap.jl भी अब इस तरह की चैनिंग का उपयोग करता है)।

उम्मीद है, यह कम से कम ब्लॉक के अंदर डॉट फ्यूजन के साथ मिलकर काम करने में सक्षम हो सकता है

begin
    [1, 2, 3]
    .+(_, 2)
    .*(_, 2)
    .-(10, _)
end

या, @chain_map सिंटैक्स का उपयोग करते हुए,

begin
    ~[1, 2, 3]
    +(_, 2)
    *(_, 2)
    -(10, _)
end

वर्तमान में ऑब्जेक्ट के साथ फंक्शन चेनिंग का एक तरीका है यदि फ़ंक्शन को कंस्ट्रक्टर के अंदर परिभाषित किया गया है। उदाहरण के लिए, फ़ंक्शन Obj.times:

type Obj
    x
    times::Function
    function Obj(x)
       this = new(x)
       this.times =  (n) -> (this.x *= n; this)
       this
    end
end

>>>Obj(2).times(3)
Obj(6,#3)

प्रकार परिभाषा के बाहर परिभाषित सदस्य कार्यों (विशिष्ट कार्यों) के कार्यान्वयन के बारे में क्या। उदाहरण के लिए, फ़ंक्शन Obj.times के रूप में लिखा जाएगा:

member function times(this::Obj, n)
     this.x *= n
     return this
end

>>>Obj(2).times(3)
Obj(6,#3)

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

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

मैंने इसे और कुछ संबंधित मुद्दों को पढ़ा है, यहाँ मेरा प्रस्ताव है:

मूल जंजीर :
in1 |> function1
समान: in1 |> function1(|>)

in2 |> function2(10)
समान: in2 |> function2(|>,10)

और भी जंजीर:
in1 |> function1 |> function2(10,|>)

चेन ब्रांचिंग और विलय:
दो बार शाखाओं के साथ शाखा out1 , out2 :
function1(a) |out1>
function2(a,b) |out2>

शाखा out1 और out2 :
function3(|out1>,|out2>)

आलस्य के बारे में क्या?
क्या हमें function!(mutating_var) सम्मेलन की तरह कुछ चाहिए?
आलसी कार्यों के लिए हम function?() उपयोग कर सकते हैं ...

और इंडेंटेशन का ठीक से उपयोग करके संबंधित कॉल ग्राफ पर डेटा निर्भरता को नेत्रहीन रूप से ट्रैक करना आसान है।

मैं सिर्फ मौजूदा |> ऑपरेटर के साथ फ़ंक्शन करने के लिए एक पैटर्न के साथ खेलता हूं। उदाहरण के लिए, ये परिभाषाएँ:
`` `` जूलिया

फ़िल्टर

अपरिवर्तनीय MyFilter {F}
फ्लाइट :: एफ
समाप्त

फ़ंक्शन (mf :: MyFilter) (स्रोत)
फ़िल्टर (mf.flt, स्रोत)
समाप्त

फ़ंक्शन Base.filter (flt)
MyFilter (फ्लाइट)
समाप्त

लेना

अपरिवर्तनीय MyTake
n :: Int64
समाप्त

फ़ंक्शन (mt :: MyTake) (स्रोत)
ले (स्रोत, mt.n)
समाप्त

फंक्शन बेस.टेक (n)
MyTake (एन)
समाप्त

नक्शा

अपरिवर्तनीय MyMap {F}
च :: एफ
समाप्त

समारोह (मिमी :: MyMap) (स्रोत)
नक्शा (mm.f, स्रोत)
समाप्त

फ़ंक्शन Base.map (f)
MyMap (च)
समाप्त
enable this to work: जूलिया
1:10 |> फ़िल्टर (i-> i% 2 == 0) |> ले (2) | मानचित्र> (i-> i ^ 2) |> एकत्रित करें
`` Essentially the idea is that functions like फ़िल्टर return a functor if they are called without a source argument, and then these functors all take one argument, namely whatever is "coming" from the left side of the |> . The >> `` तो बस इन सभी फंक्शंस को एक साथ जंजीर।

filter आदि भी केवल एक अनाम फ़ंक्शन वापस कर सकते हैं जो एक तर्क लेता है, यह सुनिश्चित नहीं करता है कि इनमें से कौन सा विकल्प अधिक प्रदर्शनकारी होगा।

मेरे उदाहरण में, मैं बेस में map(f::Any) लिख रहा हूं, मुझे वास्तव में समझ नहीं आया कि map की मौजूदा परिभाषा क्या करती है ...

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

यह मनमाने कार्यों के लिए व्यावहारिक नहीं लगता है, केवल उन लोगों के लिए जिनके लिए MyF को परिभाषित किया गया है?

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

अनिवार्य रूप से यह विचार है कि फ़िल्टर जैसे फ़ंक्शंस फ़ंक्शनल लौटाते हैं यदि उन्हें स्रोत तर्क के बिना कहा जाता है, और फिर ये फ़ंक्शंस सभी एक तर्क लेते हैं, अर्थात् जो कुछ भी बाईं ओर से "आ रहा है" |> |

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

इसके लिए इतना जटिल होने की आवश्यकता नहीं है। कार्य ऑप्ट-इन को करीने से बंद कर सकते हैं:

Base.map(f)    = (xs...) -> map(f, xs...)
Base.filter(f) = x -> filter(f, x)
Base.take(n)   = x -> take(x, n)

बेशक, यह ऐसा कुछ नहीं है जो एक पैकेज को करना चाहिए क्योंकि यह सभी पैकेजों के लिए इन तरीकों का अर्थ बदल देता है। और यह इस तरह से टुकड़ा करना बहुत सहज नहीं है - किन तर्कों को प्राथमिकता मिलनी चाहिए?

मैं एक कॉल-साइट सिंथैटिक समाधान पसंद करूंगा, जैसा कि ऊपर चर्चा की गई है, f(a, _, b) से x -> f(a, x, b) । हालांकि, यह मुश्किल है, जैसा कि ऊपर लंबी चर्चा में उल्लेख किया गया है।

इसके लिए इतना जटिल होने की आवश्यकता नहीं है। कार्य बंद करने के साथ करी करने के लिए ऑप्ट-इन कर सकते हैं

हां, मैंने सुझाव दिया कि पहले से ही, मुझे यकीन नहीं था कि इन दोनों के बीच प्रदर्शन अंतर है या नहीं।

किन तर्कों को प्राथमिकता मिलनी चाहिए?

हाँ, और फिर हमारे पास वास्तव में filter और take जैसी चीजें हैं, जहां एक मामले में हमारे पास पहले और दूसरे में आखिरी तर्क के रूप में संग्रह है ... मुझे लगता है कि कम से कम पुनरावृत्ति जैसे ऑपरेशन के लिए आमतौर पर उस प्रश्न का स्पष्ट उत्तर हो सकता है।

एक बार _ एक उपलब्ध विशेष प्रतीक है

हां, मैं इस बात से पूरी तरह सहमत हूं कि वहां एक और सामान्य समाधान है, और @malmaud यह हो सकता है।

अनिवार्य रूप से बंद होने के रूप में कोई पूर्ण अंतर नहीं है, वैसे भी आपके द्वारा लिखे गए कोड को केवल वैसे ही उत्पन्न करें। लेकिन जब से आप सिर्फ करी कर रहे हैं, आप ऐसा करने के लिए एक फ़ंक्शन लिख सकते हैं ( curry(f, as...) = (bs...) -> f(as..., bs...) )। मानचित्र और फ़िल्टर का ध्यान रखता है; curry लागू करने के लिए अतीत में भी प्रस्ताव आए हैं जो curry(take, _, 2) जैसे एक प्रहरी मूल्य को लागू करता है।

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

मैंने अब तक केवल जूलिया के सिंटैक्स के बारे में एक संक्षिप्त ट्यूटोरियल देखा है, लेकिन मैंने तुरंत इस सुविधा को शुरू कर दिया है, क्योंकि मुझे उम्मीद है कि जूलिया भी कुछ ऐसा होगा। तो मुझे लगता है कि यह मेरी तरफ से इस सुविधा अनुरोध के लिए एक +1 है।

हैलो यारो,

कृपया मुझे इस सुविधा अनुरोध को +1 करने की अनुमति दें। इसकी बहुत बुरी जरूरत है। निम्नलिखित स्काला सिंटैक्स पर विचार करें।

Array(1,2,3,4,5)
  .map(x => x+1)
  .filter(x => x > 5)
  .reduce(_ + _)

जिन लोगों ने स्पार्क या अन्य MapReduce- आधारित बड़े डेटा टूल का उपयोग किया है, वे इस वाक्य रचना से बहुत परिचित होंगे और इस तरह से बड़ी और जटिल नौकरियां लिखेंगे। यहां तक ​​कि आर, तुलनात्मक रूप से प्राचीन, निम्नलिखित की अनुमति देता है।

c(1,2,3,4,5) %>%
  {. + 1} %>%
  {.[which(. > 5)]} %>%
  sum

उचित कार्यात्मक प्रोग्रामिंग के विकल्प के रूप में कोड ब्लॉक के चतुर उपयोग पर ध्यान दें - सबसे सुंदर नहीं, बल्कि शक्तिशाली। जूलिया में, मैं निम्नलिखित कर सकता हूं।

[1,2,3,4,5] |> 
  _ -> map(__ -> __ + 1, _) |>
  _ -> filter(__ -> __ < 5, _) |>
  _ -> reduce(+, _)

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

अत्यधिक _ -> _ + 1 और समान सिंटैक्स से बचने के लिए Scala के Array(1,2,3).map(_ + 1) कुछ बराबर भी होने चाहिए। मुझे उपरोक्त विचार पसंद है जहाँ [1,2,3] |> map(~ + 1, _) अनुवाद map(~ -> ~ + 1, [1,2,3]) । तलाश के लिए धन्यवाद।

बाद के लिए, हमने कॉम्पैक्ट सिंटैक्स [1, 2, 3] .+ 1 साथ प्रसारण किया है यह काफी व्यसनी है। कमी (और शायद छानने) के लिए कुछ ऐसा करना पागलपन की तरह होगा, लेकिन यह एक बड़ा सवाल है।

यह ध्यान देने योग्य बात है कि पहले कार्य तर्क के लिए पाइपिंग और do लड़ाई दोनों।

मैं याद दिलाता हूं कि नया धागा आता है, जो हमारे पास है,
एक नहीं, दो नहीं बल्कि जूलिया के बेस SISO पाइपिंग फंक्शनलिटी को एक्सटेंशन देने वाले FIVE पैकेज, सिंटैक्स की ओर सुझाव दिए गए हैं।
सूची देखें: https://github.com/JuliaLang/julia/issues/5571#issuecomment -205754539

यह ध्यान देने योग्य बात है कि दोनों पाइपिंग करते हैं और पहले फ़ंक्शन तर्क के लिए लड़ते हैं।

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

ऊपर दिए गए मेरे पोस्ट का मतलब एक सरल उदाहरण है जिसे प्रश्न में वाक्यविन्यास मुद्दों को चित्रित करने के लिए डिज़ाइन किया गया है।

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

ये ऐसी परिस्थितियां हैं जिन पर मैं विचार कर रहा हूं। विधि कॉल या पाइप का उपयोग किए बिना ऐसे ऑपरेशन करना सरासर आकार के कारण एक गैर-स्टार्टर है।

मुझे नहीं पता कि सबसे अच्छा डिज़ाइन क्या है, मैं बस हर किसी को उपयोग के मामलों पर विचार करने के लिए प्रोत्साहित करता हूं और जो वर्तमान में है, उससे अधिक विस्तृत वाक्यविन्यास।

यह जूनो और जूलिया 0.6 में काम करना चाहिए

`` `{} जूलिया
LazyCall का उपयोग करना
@lazy_call_module_methods बेस जेनरेटर
@lazy_call_module_methods Iterator फ़िल्टर

ChainRecursive का उपयोग करना
start_chaining ()

```{julia}
[1, 2, 3, 4, 5]
<strong i="14">@unweave</strong> ~it + 1
Base.Generator(it)
<strong i="15">@unweave</strong> ~it < 5
Iterators.filter(it)
reduce(+, it)

मेरे पास इस मुद्दे पर टिप्पणियों में देखे गए कुछ वाक्यविन्यास के बारे में एक प्रश्न है:
https://stackoverflow.com/questions/44520097/method-chaining-in-julia

@somedadaism , मुद्दे मुद्दों के लिए होते हैं न कि स्टैक-ओवरफ्लो प्रश्नों का "विज्ञापन" करने के लिए। इसके अलावा, जूलिया-लोग SO पर बहुत सक्रिय हैं और (इससे भी ज्यादा) https://discourse.julialang.org/ पर

जी, अविश्वसनीय है कि यह ओओ कितना जटिल हो सकता है। कुछ सभ्य वाक्य रचना के लिए +1। मेरे लिए पाइपिंग का प्राथमिक उपयोग डेटा (फ्रेम) के साथ भी काम कर रहा है। विचार करो। व्यक्तिगत रूप से मैं वास्तव में पहले / अंतिम रूप से डिफ़ॉल्ट रूप से गुजरने के बारे में परवाह नहीं करता हूं, लेकिन मुझे लगता है कि अधिकांश पैकेज डेवलपर्स के पास उनके कार्य पहले तर्क के रूप में डेटा स्वीकार करेंगे - और वैकल्पिक तर्कों के बारे में क्या? कुछ के लिए +1

1 |> sin |> sum(2, _)

जैसा कि पहले उल्लेख किया गया है पठनीयता और सरलता सुपर महत्वपूर्ण है। मैं डेटा विश्लेषण के लिए काम करने की पूरी dplyr / साफ शैली को याद नहीं करना चाहता ...

मैं जोड़ना चाहूंगा कि मुझे पाइप ऑपरेटर के लिए भी एलिक्सिर के मल्टीलाइन सिंटैक्स बहुत उपयोगी लगते हैं।

1
|> sin
|> sum(2)
|> println

println(sum(sin(1),2)) के बराबर है

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

इस प्रकार यह प्रस्ताव दिखता है (यह जावास्क्रिप्ट में है, लेकिन जूलिया में भी मान्य है :)

const addOne = add(1, ?); // apply from the left
addOne(2); // 3

const addTen = add(?, 10); // apply from the right
addTen(2); // 12

// with pipeline
let newScore = player.score
  |> add(7, ?)
  |> clamp(0, 100, ?); // shallow stack, the pipe to `clamp` is the same frame as the pipe to `add`.

const maxGreaterThanZero = Math.max(0, ...);
maxGreaterThanZero(1, 2); // 2
maxGreaterThanZero(-1, -2); // 0

एक सारांश क्योंकि मैंने अन्य कारणों से एक लिखना शुरू कर दिया है।
संबंधित पैकेज टिप्पणी सूची भी देखें।

_ साथ कोई भी गड़बड़ 1.x में की जा सकती है, क्योंकि https://github.com/JuliaLang/julia/pull/20328

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

Anon फ़ंक्शंस बनाने के लिए _ साथ मेसिंग करें

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

• यह लगभग एक मैक्रो देखने के द्वारा नियंत्रित किया जा सकता है ।
  
  
  
  • केवल एक चीज जो नहीं की जा सकती है वह है (_) _ के समान नहीं होना। जो सिर्फ पहचान समारोह है इसलिए वास्तव में कोई फर्क नहीं पड़ता
  
  
  • यह हर जगह लागू होगा, इसलिए न केवल |> साथ उपयोगी होगा, बल्कि map(log(7,_), xs) या log(7, _).(xs) जैसी चीजों को कॉम्पैक्ट रूप से लिखने के साथ प्रत्येक तत्व के आधार 7 के साथ लॉग लेने के लिए। xs ।
  
  
  • मैं व्यक्तिगत रूप से इसका समर्थन करता हूं, अगर हम कुछ भी कर रहे थे।
  
  

|> साथ मेसिंग करके इसे प्रतिस्थापन बनाते हैं

विकल्पों में शामिल हैं:

• इसे अपने आरएचएस अधिनियम की तरह बनाएं जैसे वे करी करते हैं
  
  
  
  • वास्तव में मुझे लगता है कि यह टूट रहा है, (हालांकि हो सकता है कि एक गैर-ब्रेकिंग संस्करण हो जो विधि तालिका की जांच करता है। मुझे लगता है कि इसके बजाय इसका उपयोग करने से इनकार कर रहा है)
  
  
• इसे _ विशेष बनाएं (ऊपर दिए गए विकल्पों को देखें, और / या फिर इसे फिर से लिखने के लिए इसे नकली बनाने के विभिन्न तरीके)
  
  
  
  • ऐसा करने का एक तरीका इन्फिक्स मैक्रोज़ के निर्माण की अनुमति होगी तब कोई @|>@ लिख सकता है और इसे परिभाषित कर सकता है कि आप पैकेज में कैसे चाहते हैं (यह पहले ही बंद हो गया है एक बार https://github.com/JuliaLang/julia/ मुद्दों / 11,608)
  
  
  • या इसे उन विशेष गुणों को आंतरिक रूप से दें
  
  
• हमारे पास ऐसा करने के लिए मैक्रो कार्यान्वयन के टन हैं, जैसा कि मैंने कहा कि संबंधित पैकेजों की मेरी
• कुछ लोग इसे समाप्त करने के लिए इसे बदलने का प्रस्ताव देते हैं (अन्य सभी ऑपरेटरों के विपरीत) यह समाप्त नहीं होने से पहले लाइन पर एक अभिव्यक्ति का कारण बनता है। तो आप लिख सकते हैं

a
|> f
|>g

वर्तमान के बजाय:

a |>
f |>
g

(ब्लॉक को ब्रैकेट किए बिना एक मैक्रो के साथ इसे लागू करना संभव नहीं है। और ब्लॉक को पहले से ही ब्रैकेट में डालना वैसे भी काम करता है)

• मुझे व्यक्तिगत रूप से ये प्रस्ताव पसंद नहीं हैं क्योंकि वे |> (पहले से ही नापसंद ऑपरेटर) सुपर जादू करते हैं।

संपादित करें : जैसा कि @StefanKarpinski नीचे इंगित करता है , यह वास्तव में परिवर्तन को तोड़ रहा है।
क्योंकि कोई व्यक्ति typeof(|>) <: Function आधार पर हो सकता है।
और ये बदलाव इसे भाषा के सिंटैक्स के एक तत्व में बदल देंगे।

बोनस विकल्प: यह कभी भी होने वाला विकल्प नहीं है: # 554 हर जगह करी जोड़ना

यह भाषा में बहुत देर हो जाती है ताकि करी को जोड़ा जा सके।
यह हर जगह अस्पष्टता के विशाल ढेर को जोड़ते हुए पागल हो जाएगा।
और बस बहुत भ्रम हो।

मुझे लगता है कि इन दो विकल्पों के साथ यह मूल रूप से विचार करने लायक सब कुछ शामिल करता है।
मुझे नहीं लगता कि कुछ और भी कहा गया है (यानी "+1 यह चाहते हैं" गिनती नहीं है; या उपरोक्त पर माइक्रोवेस्टर्स की पुनरावृत्ति)।

मुझे 0.7 में |> निकालने के लिए काफी लुभाया जाता है ताकि हम बाद में इसे अधिक उपयोगी और संभवतः गैर-फ़ंक्शन-जैसे शब्दार्थ के साथ पेश कर सकें, जो मुझे संदेह है कि पाइपिंग का काम अच्छी तरह से करने के लिए आवश्यक है।

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

उस सूची पर एकमात्र ब्रेकिंग केस तब है जब |> अपने दाहिने हाथ की तरफ करीने का नाटक करता है।
या तो अपनी दलीलें पहले में डालें, या आखिरी आखिरी तर्क की स्थिति (/) में, या कुछ अन्य निश्चित स्थिति में (2 का अर्थ हो सकता है)।
एक मार्कर के रूप में _ का उपयोग किए बिना , जिसमें तर्क डालने के लिए।

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

वैसे भी यह बहुत भयानक नहीं होगा।
इसका उपयोग करने वाले पैकेज अभी भी मैक्रो पैकेज में से एक के माध्यम से हो सकते हैं।

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

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

एक एकल वर्ण | भी अच्छा हो सकता है।

अंतःक्रियात्मक रूप से हाँ, लेकिन फिर इसे .juliarc.jl में रखना पर्याप्त है (जो कि मुझे लंबे समय से पड़ा है; -)

कि शिफ्ट कुंजी के उपयोग की आवश्यकता नहीं है

ध्यान दें कि यह एक अत्यधिक स्थानीय निर्भर संपत्ति है। जैसे मेरे स्वीडिश कीबोर्ड ने शिफ्ट करने के लिए कई पात्रों को भेज दिया है और (बल्कि भयानक) AltGr संयोजनों को एक और तीन अक्षरों के लिए जगह बनाने के लिए।

क्या इस उद्देश्य के लिए |> का उपयोग करने की कोई परंपरा है? [मेथेमेटिका] (http://reference.wolfram.com/language/guide/Syntax.html) है // पोस्टफ़िक्स समारोह आवेदन के लिए, सबसे कीबोर्ड में टाइप करने के लिए आसान होना चाहिए और, उपलब्ध हो सकता है जो अगर यह पहले से ही टिप्पणियों (सी ++ में) या पूर्णांक विभाजन (पायथन के रूप में) के लिए उपयोग नहीं किया जाता है।

| साथ कुछ का इसमें शेल स्क्रिप्टिंग के साथ अच्छा संबंध है, हालांकि यदि पाठ्यक्रम में एक | बिट बिट या होने की उम्मीद होगी। क्या || तार्किक या के लिए लिया गया है? ||| बारे में क्या? किसी हार्ड-टू-पहुंच वर्ण को तीन बार टाइप करना एक बार टाइप करने से अधिक कठिन नहीं है।

क्या इस उद्देश्य के लिए उपयोग करने की कोई परंपरा है।>>

मेरा मानना ​​है कि भाषाओं के एमएल परिवार से |> की परंपरा है। जब ऑपरेटरों की बात आती है, तो कुछ प्रोग्रामिंग भाषा समुदायों ने इस स्थान की खोज की है जैसे एमएल / हास्केल समुदाय के पास है। उदाहरणों का एक छोटा चयन:

• http://www.mlton.org/InfixingOperators - एमएल में इन्फिक्स ऑपरेटरों की एक सूची। विशेष रूप से, मुझे /> , \> , </ , <\ ऑपरेटरों को बाएँ / दाएँ अनुभाग / अनुप्रयोग के लिए संग्रह पसंद है।

• http://lambda.jstolarek.com/2012/03/function-composition-and-dollar-operator-in-haskell/ - . साथ फ़ंक्शन रचना का त्वरित अवलोकन और $ साथ अनुप्रयोग हास्केल में |> टिप्पणियों में से एक में एक उपस्थिति बनाता है।)

• https://haskell-lang.org/tutorial/operators - हास्केल संचालक शब्दकोष, जिसमें >>= , =<< , >> के मोनाद-परिवार सहित मज़ेदार ऑपरेटरों का एक पूरा संग्रह है। >=> , और <=< ।

उपरोक्त सूची में जोड़ने के लिए, R%>% का उपयोग करता है - और यद्यपि वह भाषा दिनांकित है, मुझे लगता है कि इसकी पाइप कार्यक्षमता बहुत अच्छी तरह से डिज़ाइन की गई है। चीजों में से एक है जो इसे प्रभावी बनाता है घुंघराले ब्रेस सिंटैक्स, जो किसी को चीजों को लिखने की अनुमति देता है

x %>% { if(. < 5) { a(.) } else { b(.) } }

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

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

भले ही प्रस्तावित |> के वर्तमान ठेठ उपयोग के साथ संगत नहीं हैं, वे _are_ |> ऑपरेटर के साथ असंगत हैं - क्योंकि उनमें से ज्यादातर में |> अधिक शामिल हैं। एक मात्र infix फ़ंक्शन की शक्ति। यहां तक ​​कि अगर हमें यकीन है कि हम x |> f |> g का मतलब g(f(x)) बनाए रखना चाहते हैं, तो इसे एक सामान्य ऑपरेटर के रूप में छोड़ना शायद आगे किसी भी वृद्धि को पीछे छोड़ देगा। |> को एक गैर-ऑपरेटर में बदलने के दौरान, जो कि पोस्टफिक्स फ़ंक्शन एप्लिकेशन को पोस्ट किए गए फ़ंक्शन एप्लिकेशन के लिए इसके _typical_ उपयोग को नहीं तोड़ सकता है, यह अभी भी स्वीकार्य नहीं होगा क्योंकि यह |> _atypical_ के उपयोग को तोड़ देगा - कुछ भी यह एक ऑपरेटर होने पर निर्भर करता है। असामान्य उपयोग को तोड़ना अभी भी टूट रहा है और इसलिए 1.x रिलीज में इसकी अनुमति नहीं है। यदि हम उपरोक्त प्रस्तावों में से कोई भी |> साथ जहाँ तक मैं बता सकता हूं, हमें 1.0 में एक फ़ंक्शन के बजाय |> सिंटैक्स बनाने की आवश्यकता है।

@StefanKarpinski इस समय टेबल पर भी फंक्शन के बजाय |> सिंटैक्स बना रही है? क्या यह 1.0 के लिए जगह में होने के लिए इसे समय पर टेबल पर रखना संभव है?

@StefanKarpinski बना रही है।> इस समय मेज पर भी एक समारोह के बजाय वाक्य रचना? क्या यह 1.0 के लिए जगह में होने के लिए इसे समय पर टेबल पर रखना संभव है?

इसे 0.7 में दर्शाया गया है और इसे 1.0 से एकमुश्त हटा दिया गया है।
फिर इसे सिंटैक्स तत्व के रूप में 1.x के दौरान कुछ समय बाद वापस लाएं।
जो उस बिंदु पर एक गैर-परिवर्तनकारी बदलाव होगा।

किसी को इसे करने की आवश्यकता होगी, लेकिन मुझे नहीं लगता कि यह बहुत कठिन परिवर्तन है, इसलिए हां, यह मेज पर है।

|> को किस पद पर प्रतिनियुक्त किया जाएगा? Lazy.jl में एक कार्यान्वयन?

x |> f को पदावनत किया जा सकता है f(x) ।

l> बारे में कैसे, लेकिन एक ही समय में ll> परिचय देते हुए वर्तमान l> के समान व्यवहार है?

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

यह क्वेरी और दोस्तों के पारिस्थितिकी तंत्र को बड़े पैमाने पर प्रभावित करता है: मैंने एक प्रणाली बनाई है जो आर tidyverse में पाइप सिंटैक्स के समान है। पूरी बात बहुत व्यापक है: यह वर्तमान में सात सारणीबद्ध फ़ाइल स्वरूपों के लिए फ़ाइल io को शामिल करता है (दो और बहुत करीब के साथ), क्वेरी संचालन (जैसे dplyr) और साजिश रचने के सभी (बहुत दूर नहीं, लेकिन मैं आशावादी हूं कि हमारे पास हो सकता है कुछ ऐसा है जो जल्द ही ggplot महसूस करता है)। यह सभी l> के वर्तमान कार्यान्वयन पर बनाता है ...

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

अन्य विकल्प सिर्फ x |> f को वैकल्पिक रूप से f(x) । यह उस कोड को तोड़ देगा जो |> अधिभारित करता है, लेकिन जब तक वे उस चीज के साथ संगत होते हैं तब तक अतिरिक्त संवर्द्धन के लिए चीजों को छोड़ने के लिए काम करते रहने के लिए फ़ंक्शन चाइनिंग के लिए |> का उपयोग करने वाले कोड को अनुमति देते हैं।

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

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

क्या मेरा प्रस्ताव ऊपर से अनुमति नहीं देगा? |> जूलिया 1.0 में ||> आज के |> बराबर करें। जूलिया 1.0 के लिए यह कोड के लिए एक छोटी सी झुंझलाहट होगी जो वर्तमान में |> क्योंकि किसी को ||> से अधिक स्विच करना होगा। लेकिन मुझे लगता है कि यह इतना बुरा नहीं होगा, और यह पूरी तरह से स्वचालित हो सकता है। फिर, किसी को |> लिए एक अच्छा विचार है, इसे भाषा में फिर से प्रस्तुत किया जा सकता है। उस समय दोनों ||> और |> आसपास होंगे, और मुझे लगता है कि ||> धीरे-धीरे पृष्ठभूमि में फीका हो जाएगा अगर हर कोई |> को अपनाना शुरू कर दे। और फिर, कुछ वर्षों में, जूलिया 2.0 सिर्फ ||> निकाल सकता है। मेरे दिमाग में) क) जूलिया 1.0 टाइमफ्रेम में किसी को भी कोई वास्तविक परेशानी नहीं होगी, और ख) अंततः |> लिए वास्तव में अच्छे समाधान के लिए मेज पर सभी विकल्प छोड़ दें।

|>(x, f) = f(x)
|>(x, tuple::Tuple) = tuple[1](x, tuple[2:endof(tuple)]...) # tuple
|>(x, f, args...) = f(x, args...) # args

x = 1 |> (+, 1, 1) |> (-, 1) |> (*, 2) |> (/, 2) |> (+, 1) |> (*, 2) # tuple
y = 1 |> (+, 1, 1)... |> (-, 1)... |> (*, 2)... |> (/, 2)... |> (+, 1)... |> (*, 2)... # args

कई बार लिखना आसान नहीं है लेकिन बाएं से दाएं और मैक्रो का उपयोग नहीं करता है।

function fibb_tuple(n)
    if n < 3
        return n
    end
    fibb_tuple(n-3) |> (+, fibb_tuple(n-2), fibb_tuple(n-1))
end

function fibb_args(n)
    if n < 3
        return n
    end
    fibb_args(n-3) |> (+, fibb_args(n-2), fibb_args(n-1))...
end

function fibb(n)
    if n < 3
        return n
    end
    fibb(n-3) + fibb(n-2) + fibb(n-1)
end

n = 25

println("fibb_tuple")
<strong i="8">@time</strong> fibb_tuple(1)
println("fibb_args")
<strong i="9">@time</strong> fibb_args(1)
println("fibb")
<strong i="10">@time</strong> fibb(1)

println("tuple")
<strong i="11">@time</strong> fibb_tuple(n)
println("args")
<strong i="12">@time</strong> fibb_args(n)
println("fibb")
<strong i="13">@time</strong> fibb(n)

fibb_tuple
  0.005693 seconds (2.40 k allocations: 135.065 KiB)
fibb_args
  0.003483 seconds (1.06 k allocations: 60.540 KiB)
fibb
  0.002716 seconds (641 allocations: 36.021 KiB)
tuple
  1.331350 seconds (5.41 M allocations: 151.247 MiB, 20.93% gc time)
args
  0.006768 seconds (5 allocations: 176 bytes)
fibb
  0.006165 seconds (5 allocations: 176 bytes)

|>(x, tuple::Tuple) = tuple[1](x, tuple[2:endof(tuple)]...) भयानक है।
|>(x, f, args...) = f(x, args...) अधिक अक्षरों की जरूरत है लेकिन तेजी से।

मुझे लगता है कि subject |> verb(_, objects) सिंटैक्स की तरह verb(subject, objects) देना SVO का समर्थन करने का मतलब है (लेकिन जूलिया का डिफ़ॉल्ट VSO या VOS है)। हालाँकि, जूलिया mutltidipatch का समर्थन करता है इसलिए विषय विषय हो सकता है। मुझे लगता है कि अगर हमें SVO सिंटैक्स की शुरुआत करनी चाहिए तो हमें (subject1, subject2) |> verb(_, _, object1, object2) सिंटैक्स की तरह verb(subject1, subject2, object1, object2) अनुमति देनी चाहिए।
यह MIMO है अगर इसे पाइपलाइन के रूप में समझा जाता है, जैसा कि @oxinabox ने उल्लेख किया है।

(x)f रूप में f(x) (x)f उपयोग कैसे करें?
(x)f(y) दोनों को f(x)(y) और f(y)(x) रूप में पढ़ा जा सकता है, इसलिए पहले सही चुनें:

(x)f # f(x)
(x)f(y) # f(y)(x)
(x)f(y)(z) # f(y)(z)(x)
(x)(y)f(z) # f(z)(y)(x)
(a)(b)f(c)(d) # f(c)(d)(b)(a)
1(2(3, 4), 5(6, 7), 8(9, 10)) # 1(2(3, 4), 5(6, 7), 8(9, 10))
1 <| (2 <| (3, 4), 5 <| (6, 7), 8 <| (9, 10)) # 1(2(3, 4), 5(6, 7), 8(9, 10)), but 2 <| (3, 4) == 2((3, 4)) so currently emit error
3 |> 2(_, 4) |> 1(_, 5(6, 7), 8(9, 10)) # 1(2(3, 4), 5(6, 7), 8(9, 10))
((3)2(_, 4))1(_, 5(6, 7), 8(9, 10)) # 1(2(3, 4), 5(6, 7), 8(9, 10))
(3, 4) |> 2(_, _) |> 1(_, 5(6, 7), 8(9, 10)) # 1(2(3, 4), 5(6, 7), 8(9, 10))
((3, 4)2)1(_, 5(6, 7), 8(9, 10)) # 1(2(3, 4), 5(6, 7), 8(9, 10))

यह स्पष्ट रूप से vararg में हेरफेर कर सकता है।
लेकिन यह बिना रिक्त स्थान के बाइनरी ऑपरेटरों को तोड़ देगा:

(a + b)+(c + d) # +(c + d)(a + b) == (c + d)(a + b): Error

वैकल्पिक विकल्प: विभाजन सिंटैक्स के लिए एक और मामला जोड़ें। F ... (x) desugar to (args ...) -> f (x, args ...)

यह सिंटैक्टिकली लाइटवेट (मैनुअल) क्यूरिंग को सक्षम करेगा:

#Basic example:
f(a,b,c,d) = #some definition
f...(a)(b,c,d) == f(a,b,c,d)
f...(a,b)(c,d) == f(a,b,c,d)
f...(a,b,c)(d) == f(a,b,c,d)
f...(a)...(b)(c,d) == f(a,b,c,d) # etc etc

# Use in pipelining:
x |> map...(f) |> g  |> filter...(h) |> sum

आप कब से करना बंद कर देते हैं? जूलिया फ़ंक्शन में निश्चितता नहीं है।

जूलिया के पास पहले से ही एक शानदार ऑपरेटर है। मैं जो प्रस्ताव कर रहा हूं, वह वर्तमान स्पैट ऑपरेटर के समान व्यवहार होगा।

I, e: f ... (x) == (args ...) -> f (x, args ...) छींटे के साथ एक मेमना बनाने के लिए चीनी है।

वह परिभाषा हमेशा आपको एक फ़ंक्शन ऑब्जेक्ट देती है। संभवतः आप कभी-कभी एक उत्तर चाहते हैं।

आप उस वस्तु को स्पष्ट रूप से अंत में कहते हैं। उदाहरण के लिए, मेरे अंतिम उदाहरण f ... (a) ... (b) (c, d) == f (a, b, c, d) में कोष्ठक के अंतिम सेट से पहले ... की कमी पर ध्यान दें। ।

आप लौटे हुए फंक्शन ऑब्जेक्ट को |> के साथ भी कॉल कर सकते हैं, जो पाइपिंग के लिए अच्छा है।

@saolof

मूल उदाहरण:

f (ए, बी, सी, डी) = #some परिभाषा
च ... (ए) (बी, सी, डी) == एफ (ए, बी, सी, डी)
च ... (ए, बी) (सी, डी) == एफ (ए, बी, सी, डी)
च ... (ए, बी, सी) (डी) == एफ (ए, बी, सी, डी)
f ... (a) ... (b) (c, d) == f (a, b, c, d) # आदि

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

और @StefanKarpinski सही है, आप नहीं जानते कि कब उनके लिए कार्य करना बंद करना है और अंत में उन्हें एक अधिक स्केलर आइटम पर लागू करना है।

- (काटा) -

क्षमा करें, यह व्यर्थ और अपठनीय है।
स्पष्ट स्पष्टीकरण प्राप्त करने के लिए नीचे मेरा दूसरा संदेश देखें (मुझे आशा है)।

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

आप इसे अपने स्वयं के उत्तर के आराम से भी प्रोटोटाइप कर सकते हैं:

ctranspose(f) = (a...) -> (b...) -> f(a..., b...)

map'(+)(1:10)

map'(+)'(1:10, 11:20)(21:30)

(+)'(1,2,3)(4,5)

1:10 |> map'(x->x^2) |> filter'(iseven)

मुझे लगता है कि यह एक अच्छा लग रहा है।

संपादित करें: ऐसा लगता है कि यह अधिक सामान्य बनाने का मार्ग भी हो सकता है। यदि हम map∘(+, 1:10) लिख सकते हैं तो हम पहले किए गए तर्क को रखने के लिए map∘(_, 1:10) लिख सकते हैं, और करी ओपरेटर लैम्ब्डा के दायरे को निर्धारित करता है, इस तरह के सामान्य करी के लिए सबसे बड़ी समस्या को हल करता है।

एह, वह चतुर है, @ मायकेनेस।

मुझे अच्छा लगता है कि जूलिया की अतिशयता यहां भी दिखाई देती है। फ़ंक्शन चेनिंग के लिए आवश्यकताओं की एक बहुत विस्तृत श्रृंखला के लिए एकीकृत समाधान ctranspose दुर्व्यवहार करता है ...

(स्पष्टीकरण: मुझे इस प्रस्ताव के साथ 1:10 |> map'(x->x^2) |> filter'(iseven) मिल रहा है, इसलिए मैं इसके लिए getting% हूं!)

स्पष्ट होने के लिए, मुझे नहीं लगता कि हमें वास्तव में इसके लिए adjoint ऑपरेटर का दुरुपयोग करना चाहिए, लेकिन यह अवधारणा का एक अच्छा प्रमाण है कि हम एक संक्षिप्त फ़ंक्शन करी नोटिंग कर सकते हैं।

शायद हमें एक नया यूनिकोड ऑपरेटर शुरू करना चाहिए? http://www.fileformat.info/info/unicode/char/1f35b/index.htm

(माफ़ करना...)

मुझे लगता है कि लैंबडा बनाने के लिए _ अभी भी बहुत अधिक लचीला तरीका है

@bramtayl मुझे लगता है कि उनके पोस्ट में माइकइन्स के संपादन में विचार यह है कि दोनों सह-कलाकार - स्टैंडअलिन अंडरस्कोर को @stevengj के पुल अनुरोध में काम करेंगे, जैसे कि माइक के विचार में स्टैंडअलोन करी काम करेगा, और दोनों को मिलाएगा। यह भी काम करेगा, जिससे आप इसके अंदर _ s के दायरे का परिसीमन करने के लिए करीने के ऑपरेटर का उपयोग कर सकेंगे।

आह मिल गया

कि यह LazyCall.jl से बहुत अलग नहीं है

या यहाँ प्रस्ताव: https://github.com/JuliaLang/julia/pull/24990#issuecomment -350490856

अधिक गंभीर नोट पर:

स्पष्ट होने के लिए, मुझे नहीं लगता कि हमें वास्तव में इसके लिए adjoint ऑपरेटर का दुरुपयोग करना चाहिए

शायद एक ध्वनि पसंद है। हालांकि, मैं अपनी आशाओं को आवाज देना चाहूंगा कि यदि इस तरह का समाधान लागू किया जाता है, तो इसे एक ऑपरेटर दिया जाता है जो टाइप करना आसान है। 1:10 |> map'(x->x^2) कुछ करने की क्षमता काफी कम उपयोगी है यदि कोई भी चरित्र ' की जगह लेता है तो मुझे इसे यूनिकोड तालिका में देखने की आवश्यकता है (या एक संपादक का उपयोग करें जो LaTeX-expansions का समर्थन करता है)।

सहायक ऑपरेटर के साथ दुर्व्यवहार करने के बजाय, हम फाटक का पुन: उपयोग कर सकते हैं।

• एक रेखीय (रैखिक) पाइपिंग संदर्भ में
• अंदर, एक फ़ंक्शन कॉल में
  
  
  
  • बाद के बजाय पहले से अलग करना
  
  

इसलिए

• splat एक लापता itter arg को प्रेरित कर सकता है

एक प्रकार का उच्च क्रम का छज्जा , (
उम्मीद है कि यह बहुत ज्यादा नहीं हिला।

उदाहरण

1:10
    |> map(...x->x^2)
    |> filter(...iseven)

उदाहरण २

genpie = (r, a=2pi, n=12) ->
  (0:n-1) |>
      map(...i -> a*i/n) |>
      map(...t -> [r*cos(t), r*sin(t)]) 

के लिए खड़ा हो सकता है

elmap = f -> (s -> map(f,s))

genpie = (r, a=2pi, n=12) ->
  (0:n-1) |>
      elmap(i -> a*i/n) |>
      elmap(t -> [r*cos(t), r*sin(t)]) 

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

mutable struct T
    move
    scale
    display
    x
    y
end

function move(x,y)
    t.x=x
    t.y=y
    return t
end
function scale(c)
    t.x*=c
    t.y*=c
    return t
end
function display()
    @printf("(%f,%f)\n",t.x,t.y)
end

function newT(x,y)
    T(move,scale,display,x,y)
end


julia> t=newT(0,0)
T(move, scale, display, 0, 0)

julia> t.move(1,2).scale(3).display()
(3.000000,6.000000)

वाक्यविन्यास पारंपरिक ओओपी के समान लगता है, जिसमें "क्लास मेथड्स" का एक अलग रूप है। निश्चित नहीं है कि प्रदर्शन के निहितार्थ क्या हैं।

@ivanctong आपने जो वर्णन किया है वह धाराप्रवाह इंटरफ़ेस के लिए कुछ अधिक है।

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

जिस तरह से अमृत वह करता है, जहां पाइप ऑपरेटर हमेशा पहले तर्क के रूप में बाईं ओर से गुजरता है और बाद में अतिरिक्त तर्क देता है, बहुत उपयोगी रहा है, मैं प्रथम श्रेणी के नागरिक के रूप में "elixir" |> String.ends_with?("ixir") जैसा कुछ देखना पसंद करूंगा। जूलिया में।

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

तो क्या इस बिंदु पर जूलिया के लिए एक धाराप्रवाह इंटरफ़ेस है?

कृपया जूलिया प्रवचन चर्चा मंच पर प्रश्न पोस्ट करें।

हैकिंग के एक फिट में (और संदिग्ध निर्णय!?) मैंने फ़ंक्शन प्लेसहोल्डर्स के बंधन की जकड़न का एक और संभावित समाधान बनाया है:

https://github.com/c42f/MagicUnderscores.jl

जैसा कि https://github.com/JuliaLang/julia/pull/24990 पर दिया गया है, यह इस अवलोकन पर आधारित है कि व्यक्ति अक्सर किसी दिए गए फ़ंक्शन के कुछ स्लॉट्स को _ प्लेसहोल्डर को कसकर बाँधना चाहता है, और दूसरों को शिथिल। MagicUnderscores यह किसी भी उपयोगकर्ता परिभाषित फ़ंक्शन (प्रसारण मशीनरी की भावना में बहुत अधिक) के लिए एक्स्टेंसिबल बनाता है। इस प्रकार हमारे पास ऐसी चीजें हो सकती हैं

julia> <strong i="12">@_</strong> [1,2,3,4] |> filter(_>2, _)
2-element Array{Int64,1}:
 3
 4

julia> <strong i="13">@_</strong> [1,2,3,4] |> filter(_>2, _) |> length
2

"सिर्फ काम"। ( @_ स्पष्ट रूप से दूर जा रहा है अगर यह एक सामान्य समाधान बनाना संभव है।)

कुछ बदलाव @MikeInnes सुझाव मेरी ज़रूरतों के लिए पर्याप्त होंगे (आमतौर पर do सिंटैक्स का उपयोग करके फ़िल्टर, मैप, कम, गणना, ज़िप आदि की लंबी श्रृंखलाएं)।

c(f) = (a...) -> (b...) -> f(a..., b...)

1:10 |> c(map)() do x
    x^2
end |> c(filter)() do x
    x > 50
end

यह काम करता है, हालांकि मुझे अब काम करने के लिए ' नहीं मिल सकते हैं। यह इससे थोड़ा छोटा है:

1:10 |> x -> map(x) do x
    x^2
end |> x -> filter(x) do x
    x > 50
end

इसके अलावा, मुझे लगता है कि एक बस कर सकता है

cmap = c(map)
cfilter = c(filter)
cetc = c(etc)
...

1:10 |> cmap() do x
    x^2
end |> cfilter() do x
    x > 50
end |> cetc() do ...

1.0 के रूप में आप को ओवरलोड करने की आवश्यकता होगी adjoint के बजाय ctranspose । आप भी कर सकते हैं:

julia> Base.getindex(f::Function, x...) = (y...) -> f(x..., y...)

julia> 1:10 |> map[x -> x^2] |> filter[x -> x>50]
3-element Array{Int64,1}:
  64
  81
 100

अगर हम apply_type को अधिभारित कर सकते हैं तो हम map{x -> x^2} प्राप्त कर सकते हैं :)

@ मायकेनेस ने मैं बस यही चुराया था

एक देर और थोड़ा तुच्छ योगदान - तर्क और सूची में किसी भी स्थान पर डेटा को पाइप करने के बारे में बाएं और दाएं तलछट के संयोजन का उपयोग कैसे करें:

VERSION==v"0.6.2"
import Base: ctranspose, transpose  
ctranspose(f::Function) = (a...) -> ((b...) -> f(a..., b...))  
 transpose(f::Function) = (a...) -> ((b...) -> f(b..., a...))

"little" |> (*)'''("Mary ")("had ")("a ") |> (*).'(" lamb")

क्लोजर में कुछ अच्छे थ्रेडिंग मैक्रोज़ होते हैं । क्या हमारे पास कहीं जूलिया इकोसिस्टम है?

क्लोजर में कुछ अच्छे थ्रेडिंग मैक्रोज़ होते हैं । क्या हमारे पास कहीं जूलिया इकोसिस्टम है?

https://github.com/MikeInnes/Lazy.jl

क्लोजर में कुछ अच्छे थ्रेडिंग मैक्रोज़ होते हैं । क्या हमारे पास कहीं जूलिया इकोसिस्टम है?

हमारे पास उनमें से कम से कम 10 हैं।
मैंने एक सूची थ्रेड में पोस्ट की।
https://github.com/JuliaLang/julia/issues/5571#issuecomment -205754539

क्या आप अन्य दो पैकेजों के बजाय लाइटविकै के लिए सूची संपादित कर सकते हैं?

चूंकि |> ऑपरेटर अमृत से आते हैं, इसलिए उन्हें गुमनाम कार्यों को बनाने के तरीकों में से एक से प्रेरणा क्यों नहीं लेनी चाहिए?
अमृत ​​में आप एक नए बेनामी फ़ंक्शन को परिभाषित करने के लिए &expr उपयोग कर सकते हैं और स्थितीय तर्कों को कैप्चर करने के लिए &n ( &1 पहली दलीलें हैं, &2 दूसरी है, आदि।)
अमृत ​​में लिखने के लिए अतिरिक्त सामान हैं, (उदाहरण के लिए आपको एक अनाम फ़ंक्शन &(&1 + 1).(10) कॉल करने के लिए कोष्ठक से पहले एक डॉट की आवश्यकता है)

लेकिन यहाँ क्या यह जूलिया में लग सकता है

&(&1 * 10)        # same as: v -> v * 10
&(&2 + 2*&5)      # same as: (_, x, _, _, y) -> x + 2*y
&map(sqrt, &1)    # same as: v -> map(sqtr, v)

इसलिए हम |> ऑपरेटर का अधिक अच्छी तरह से उपयोग कर सकते हैं

1:9 |> &map(&1) do x
  x^2
end |> &filter(&1) do x
  x in 25:50
end

के बजाय

1:9 |> v -> map(v) do x
  x^2
end |> v -> filter(v) do x
  x in 25:50
end

ध्यान दें कि आप पंक्ति 2 और 3 को .|> &(&1^2) या .|> (v -> v^2)

_ प्लेसहोल्डर के साथ प्रस्ताव के साथ मुख्य अंतर यह है कि यहां स्थितिगत तर्कों का उपयोग करना संभव है, और भावों के सामने & प्लेसहोल्डर्स के दायरे को स्पष्ट करता है (पाठक के लिए और संकलक)।

ध्यान दें कि मैंने अपने उदाहरणों में & लिया है, लेकिन ? , _ , $ या कुछ और के बदले, कुछ भी नहीं बदलेगा मामला।

स्केल पहले तर्क के लिए _ का उपयोग करता है, दूसरे तर्क के लिए _ , जो संक्षिप्त है, लेकिन आप जल्दी से उन परिस्थितियों से बाहर निकल जाते हैं जहां आप इसे लागू कर सकते हैं (दोहरा या उलट नहीं सकते हैं) तर्कों का क्रम)। इसमें एक उपसर्ग भी नहीं है (ऊपर दिए गए सुझाव में & ) जो भावों से कार्यों की अवहेलना करता है, और व्यवहार में, एक और मुद्दा है जो इसके उपयोग को रोकता है। एक प्रैक्टिशनर के रूप में, आप अतिरिक्त कोष्ठक और घुंघराले कोष्ठकों में इच्छित इनलाइन फ़ंक्शंस को समाप्त करते हैं, उम्मीद करते हैं कि इसे मान्यता दी जाएगी।

तो मैं कहूंगा कि इस तरह से एक वाक्यविन्यास को पेश करते समय सर्वोच्च प्राथमिकता यह है कि यह अस्पष्ट हो।

लेकिन तर्कों के लिए उपसर्गों के रूप में, $ की शेल स्क्रिप्टिंग दुनिया में एक परंपरा है। परिचित पात्रों का उपयोग करना हमेशा अच्छा होता है। यदि |> अमृत ​​से है, तो यह एक तर्क हो सकता है कि अमृत से & भी लिया जा सकता है, इस विचार के साथ कि उपयोगकर्ता पहले से ही उस मोड में सोच रहे हैं। (यह मानते हुए कि वहाँ पूर्व अमृत के बहुत से उपयोगकर्ता हैं ...)

एक चीज जो इस तरह से एक वाक्यविन्यास है, वह शायद कभी भी एक फ़ंक्शन नहीं बना सकती है जो N तर्क लेती है, लेकिन N से कम का उपयोग करती है। $1 , $2 , $3 शरीर में निहित है 3 तर्कों का अस्तित्व है, लेकिन यदि आप इसे ऐसी स्थिति में रखना चाहते हैं, जहां इसे 4 तर्कों (अंतिम रूप से अनदेखा किया जाए) के साथ बुलाया जाएगा, तो इसे व्यक्त करने का कोई स्वाभाविक तरीका नहीं है। (प्रत्येक एन के लिए पहचान कार्यों को पूर्वनिर्धारित करने और उनमें से किसी एक के साथ अभिव्यक्ति को लपेटने के अलावा।) यह |> बाद लगाने के प्रेरक मामले के लिए प्रासंगिक नहीं है, जिसमें केवल एक तर्क है, हालांकि।

मैंने Colon का उपयोग करके @MikeInnes ट्रिक को ओवरलोडिंग के लिए बढ़ाया, जैसे कि फ़ंक्शन गिरफ्तार थे:

struct LazyCall{F} <: Function
    func::F
    args::Tuple
    kw::Dict
end

Base.getindex(f::Function,args...;kw...) = LazyCall{typeof(f)}(f,args,kw)

function (lf::LazyCall)(vals...; kwvals...)

    # keywords are free
    kw = merge(lf.kw, kwvals)

    # indices of free variables
    x_ = findall(x->isa(x,Colon),lf.args)
    # indices of fixed variables
    x! = setdiff(1:length(lf.args),x_)

    # the calling order is aligned with the empty spots
    xs = vcat(zip(x_,vals)...,zip(x!,lf.args[x!])...)
    args = map(x->x[2],sort(xs;by=x->x[1]))

    # unused vals go to the end
    callit = lf.func(args...,vals[length(x_)+1:end]...; kw...)

    return callit
end

[1,2,3,4,1,1,5]|> replace![ : , 1=>10, 3=>300, count=2]|> filter[>(50)]  # == [300]

log[2](2) == log[:,2](2) == log[2][2]() == log[2,2]()  # == true

यह लैम्ब्डा या थ्रेडिंग मैक्रोज़ की तुलना में बहुत धीमा है, लेकिन मुझे लगता है कि इसका सुपर कूल: पी

यहां टिप्पणी करने वाले लोगों को याद दिलाने के लिए, https://github.com/JuliaLang/julia/pull/24990 पर प्रासंगिक चर्चा पर एक नज़र है

इसके अलावा, मैं आपको https://github.com/c42f/Underscores.jl को आज़माने के लिए प्रोत्साहित करूंगा, जो प्लेसहोल्डर्स के लिए _ सिंटैक्स का फ़ंक्शन-चेनिंग-फ्रेंडली कार्यान्वयन देता है। @jpivarski आपके उदाहरणों के आधार पर, आप इसे काफी परिचित और आरामदायक पा सकते हैं।