Julia: मिनी जूलप: यदि x तो y

पर्ल/रूबी-शैली अगर/संशोधक वाक्यविन्यास के लिए ऐसा लगता है कि यह इसके साथ बेहतर मिश्रण करेगा। दूसरे शब्दों में:

println("positive") if x > 0         # conditional execution
x^2 for x=1:100                      # generator
[ x^2 for x=1:100 ]                  # comprehension
x^2 if x % 3 == 0 for x = 1:100      # filtered generator
[ x^2 if x % 3 == 0 for x = 1:100 ]  # filtered comprehension

इसका अन्य भाषाओं में उदाहरण होने का भी लाभ है, जो if - then बिना end सिंटैक्स के नहीं लगता है।

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

हाँ, अच्छा बिंदु। दरअसल #6823 चर्चा के बीच में लगता है और शायद इसे बंद नहीं किया जाना चाहिए था।

हो सकता है कि मैं अल्पमत में हूं क्योंकि अन्य भाषाओं ने इस दृष्टिकोण को अपनाया है, लेकिन मैंने हमेशा स्थिति से पहले आने वाली कार्रवाई को वास्तव में अजीब पाया है, उदाहरण के लिए println("positive") if x > 0 । मुझे लगता है कि यह if x > 0 println("positive") end से अधिक संक्षिप्त है लेकिन कम से कम मेरे लिए यह पठनीयता की कीमत पर आता है।

मैं इसे बातचीत की तरह सोचता हूं:

जूलिया: "मैं एक स्ट्रिंग प्रिंट करूँगा ..."
हेरोल्ड: "बहुत बढ़िया!"
जूलिया: "... लेकिन केवल तभी जब कुछ शर्त पूरी हो।"
हेरोल्ड: "ओह। :("

बनाम

जूलिया: "अगर कुछ शर्त पूरी होती है, तो मैं एक स्ट्रिंग प्रिंट करूंगी।"
हेरोल्ड: "ठीक है, अच्छा।"

@ararslan : मैं असहमत नहीं हूं, जो रूबी और पर्ल में पूर्व कला के बावजूद जूलिया में यह सुविधा नहीं है, इसका एक कारण है। हालांकि, यह जनरेटर और समझ के लिए for संशोधक सिंटैक्स के साथ बहुत बेहतर मिश्रण करता है, यही वजह है कि मैंने इसे यहां लाया।

@StefanKarpinski हाँ सहमत हुए, यह उन लोगों के साथ बेहतर जाल करता है। हालांकि मैं अभी भी निराशाजनक रूप से पिछली कार्रवाइयों से जुड़ा हुआ हूं। : मुस्कान: (लेकिन जैसा कि मैंने हाल ही में खुद को अक्सर कहते हुए पाया है, मेरी राय वास्तव में मायने नहीं रखती है; मैं सिर्फ कुछ आदमी हूं।)

मुझे लगता है कि अगर आपके पास कुछ ऐसा होता

if x % 3 == 0 then x^2 for x = 1:100

तो यह तुरंत स्पष्ट नहीं होता है कि आप एक समझ/जनरेटर/चीज़माजिग शुरू कर रहे हैं, क्योंकि यह भी पढ़ता है जैसे इसे समूहीकृत किया जा सकता है

if x % 3 == 0 then (x^2 for x = 1:100)

यानी अगर कुछ कंडीशन है तो जेनरेटर. मुझे कोई आपत्ति नहीं होगी

if x % 3 == 0 x^2 end for x = 1:100            # More obvious what's happening, IMO
filter(x -> x % 3 == 0, [x^2 for x = 1:100])   # Verbose, but... ¯\_(ツ)_/¯

मुझे लगता है कि अगर जनरेटर में कार्रवाई का पालन करने की शर्त थी, तो मुझे लगता है कि मैं if से भिन्न कीवर्ड पसंद करूंगा, उदाहरण के लिए where । फिर यह लगभग एक SQL क्वेरी की तरह पढ़ता है, उदाहरण के लिए

x^2 for x = 1:100 where x % 3 == 0

मुझे लगता है कि where यह थोड़ा स्पष्ट करता है कि आप if की तुलना में if for द्वारा उत्पादित x के मानों को फ़िल्टर कर रहे हैं।

डेटा प्रवाह को एक दिशा में रखना मेरे लिए अच्छा लगता है, हालांकि इस मामले में बाएं से दाएं के बजाय दाएं से बाएं।

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

for 1:n मान "उत्पन्न" करता है, if x % 3 == 0 उन्हें फ़िल्टर करता है और x^2 उन्हें बदल देता है - जनरेटर पहले से ही दाएं से बाएं प्रवाहित होते हैं और उस प्रवाह को बनाए रखने के लिए फ़िल्टर को अंदर जाने की आवश्यकता होती है मध्यम। यदि if क्लॉज for क्लॉज के दायीं ओर जाता है तो डेटा बीच से बहुत दूर दाईं ओर और फिर दूर बाईं ओर "प्रवाह" होता है, जो अजीब है। यदि if क्लॉज बाईं ओर है तो डेटा "प्रवाह" दूर दाईं ओर से दूर बाईं ओर मध्य की ओर होता है। मुझे पता है कि SQL where क्लॉज को टेबल नामों के दाईं ओर और एक्सप्रेशन को बाईं ओर रखता है - क्योंकि यह अंग्रेजी की तरह अधिक पढ़ता है - लेकिन मुझे हमेशा पढ़ने में यह कष्टप्रद लगता है और मुझे लगता है कि अंग्रेजी की तरह पढ़ना एक अनुमानी नहीं है जिसे प्रोग्रामिंग भाषा डिजाइन में बहुत दूर ले जाना चाहिए।

चीजें जो मुझे if x then y के बारे में पसंद नहीं हैं:

1. यह नया then कीवर्ड पेश करता है।
2. यह लिखने के लिए छोटा है if x y end से if x then y ; x && y और भी छोटा है।
3. then कीवर्ड का व्यापक रूप से विपरीत प्रकार के सिंटैक्स के लिए भाषाओं में उपयोग किया जाता है: एक मल्टीलाइन if सिंटैक्स जिसके लिए end कीवर्ड (या fi बैश में) की आवश्यकता होती है , यक)।

ओह हाँ, मैं देख रहा हूँ कि अब प्रवाह के बारे में आपका क्या मतलब है। यह समझ आता है। स्पष्टीकरण के लिए धन्यवाद!

क्या ऐसा करने में सक्षम होना अजीब होगा

x^2 if x % 3 == 0 for x = 1:100

और _नहीं_ करने में सक्षम हो

println("positive") if x > 0

?

सभी अच्छे अंक।

मुझे वास्तव में सिंटैक्स पसंद है @StefanKarpinski ने पहली बार अपनी पहली टिप्पणी में प्रस्तावित किया था। मुझे मुख्य रूप से सशर्त जेनरेटर रखने में दिलचस्पी है, एक बोनस के रूप में अधिक सामान्य शॉर्ट-फॉर्म _if_-form के साथ।

जेनरेटर के संबंध में, मैं श्रेणी का हिस्सा बनने के लिए if (या where - उस पर मेरी कोई राय नहीं है) पढ़ रहा था ... यह एक पुनरावर्तक x = 1:10 if/where x % 2 == 0 बना रहा है, जो फिर एक ऐरे (या जनरेटर) बनाने के लिए बाईं ओर की अभिव्यक्ति के साथ जोड़ा जाता है।

एक मायने में, x = 1:10 where x % 2 == 0 अपने आप में किसी प्रकार के चलने योग्य जनरेटर है। यह स्टैंड-अलोन सिंटैक्स हो सकता है, नहीं?

मुझे लगता है कि सशर्त if a then b कथन के लिए फ़िल्टरिंग किसी भी तरह से एक अलग ऑपरेशन है। फ़िल्टरिंग पुनरावृत्ति सीमा पर कार्य करता है। जब if a then b को जनरेटर के बाईं ओर अभिव्यक्ति के साथ जोड़ा जाता है, तो मैं उम्मीद करता हूं कि यह nothing के मामलों में उत्सर्जित होगा a false था। तुलना करें कि यदि मैं कोष्ठक जोड़ता हूँ तो तार्किक रूप से क्या होता है:

[(x^2 if i % 2 == 1) for i = 1:10] # [nothing, 4, nothing, 16, nothing, 36, nothing, 64, nothing, 100]
[x^2 (for i = 1:10 where i % 2 == 0)] # [4, 16, 36, 64, 100]

अगर हम अनुमति दें तो @ararslan के उदाहरण लेते हुए

println("positive") if x > 0

तो IMHO यह इस प्रकार है कि

x^2 if x % 3 == 0 for x = 1:100

शायद nothing, nothing, 9, nothing, nothing, 36, ... उत्सर्जित करना चाहिए

अंत में, अगर हम एक शॉर्टहैंड if सशर्त अपनाने वाले थे, तो मेरा वोट स्टेटमेंट से पहले की शर्त के लिए है, @ararslan की पहली पोस्ट द्वारा उल्लिखित कारणों के लिए - कोड को पढ़ने में कम से कम आश्चर्य का प्रमुख होना। (याद रखें, यदि वे कहते हैं कि कोड लिखित से अधिक पढ़ा जाता है, तो if a then b बेहतर सिंटैक्स है तो a && b भले ही बाद वाला छोटा हो)। इसका मतलब यह भी है कि जनरेटर के अंदर if के दो संभावित प्रकार अलग-अलग होंगे - सबसे बाईं ओर - अभिव्यक्ति के साथ - या सबसे दाईं ओर - सीमा के साथ।

रुबी/पर्ल में परंपरा के लिए, मुझे परंपरा से फंसने के बजाय सर्वोत्तम समाधान के साथ प्रयास करने और आने के लिए बेहतर लगता है। अगर यह काम करता है और स्वाभाविक लगता है तो लोग इसे पसंद करेंगे।

इसके अलावा, यदि हमारे पास श्रेणियों में if/where है, तो क्या हमें यह सुनिश्चित करने के लिए सावधान रहने की आवश्यकता है कि श्रेणी बहुआयामी जनरेटर के लिए कार्टेशियन बनी रहे?

# Make a circular array (filled with distance to center)
r = 5
[sqrt(x^2 + y^2) for x = -5:5, y = -5:5 where x^2 + y^2 <= r^2]

यह एक प्रकार का शांत और एक प्रकार का भयानक है!

मुझे लगता है कि फ़िल्टरिंग किसी भी तरह से सशर्त के लिए एक अलग ऑपरेशन है यदि a तो b कथन।

हां! मैं वही टिप्पणी पोस्ट करने वाला था। फ़िल्टरिंग संपूर्ण रूप से इटरेटर पर काम करता है, और अंदर की गणना की गई अभिव्यक्ति का हिस्सा नहीं है।

मैं भी @andyferris जैसा ही महसूस करता हूं कि अभिव्यक्ति और पुनरावृत्ति के बीच if पुनरावृत्ति के आकार के बजाय अभिव्यक्ति के मूल्य को "रूपांतरित" करता है, और nogthing का उत्पादन करना चाहिए जब शर्त पूरी नहीं हुई है (लेकिन मैं अजगर/हास्केल समझ से खराब हो सकता हूं)।

स्पष्ट रूप से x if false का मूल्यांकन nothing होगा जब जनरेटर अभिव्यक्ति के संदर्भ में नहीं। [x^2 if x % 3 == 0 for x=1:100] का समर्थन करना पूरी तरह से उचित होगा लेकिन x if y नहीं।

व्यक्तिगत रूप से, यदि केवल एक कथन है तो मैं end को छोड़ने में सक्षम हूं।

if length(A) != length(B) throw(ArgumentError("..."))

यदि कोई end नहीं है, तो यह मान सकता है कि केवल एक ही व्यंजक था। मैं अनुमान लगा रहा हूं कि इस पर पहले भी चर्चा की जा चुकी है?
मैं ध्यान देता हूं कि मैं शर्त के बाद अर्धविराम नहीं रखना पसंद करूंगा - अभिव्यक्ति के बाद... _maybe_... हालांकि मुझे यह पसंद नहीं है।

अगर कथन के समान रूप के लिए दो अलग-अलग वाक्यविन्यास हैं, तो मैं बहुत कुछ चाहता हूं;if x; ...; end , और if x then; ... । _(संपादित करें: if condition then action मुझ पर बढ़ गया है।)_

[x^2 if x% 3 == 0 for x=1:100] का समर्थन करना पूरी तरह से उचित होगा, लेकिन x अगर y अपने आप में नहीं।

@StefanKarpinski मैं पूरी तरह से इसके साथ हूं। हालाँकि...

यदि यदि क्लॉज बाईं ओर है तो डेटा "प्रवाह" दूर दाईं ओर से बाईं ओर मध्य की ओर होता है।

मैंने x^2 if x % 2 == 0 for x in 1:10 के रूप में पढ़ा, x^2 where x % 2 == 0 for each x in 1:10 , जो, क्योंकि यह समझ है, मुझे समझ में आता है; आप परिवर्तन में सबसे अधिक रुचि रखते हैं।
SQL प्रश्नों में, वही बिंदु सत्य है, नहीं?

इसलिए मुझे नहीं लगता कि इसे पढ़ने के लिए "जनरेटर" का शुरुआती बिंदु होना बिल्कुल सही है, _एक समझ के लिए_। दूसरी ओर लूप के लिए... यह अधिक समझ में आता है।

व्यक्तिगत रूप से, मैं केवल एक ही कथन होने पर अंत को छोड़ने में सक्षम हूं।

मैंने इसे बहुत समय पहले प्रस्तावित किया था लेकिन इसे कोई कर्षण नहीं मिला: https://github.com/JuliaLang/julia/issues/1657। यह वास्तव में एक अपेक्षाकृत गैर-विघटनकारी परिवर्तन होगा क्योंकि यह अजीब और दुर्लभ होगा कि इस तरह के कुछ लेखन कोड देखें:

if cond body
end

आप $#$1 then #$ के बजाय do ब्लॉक का उपयोग करने के बारे में क्या सोचते हैं? यानी: if x do y end

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

@diegozea वही समस्या, मुझे लगता है। मैं अब भी if x y पसंद करूंगा।

@carlobaldassi कुछ चीजें हैं जो आप मनुष्यों के लिए पार्स करना आसान बनाने के लिए कर सकते हैं।

आप उस सिंगल-स्टेटमेंट को बाध्य कर सकते हैं यदि स्थिति और अभिव्यक्ति के बीच कोई नई रेखा नहीं होगी।
मुझे यकीन नहीं है कि मैं लंबे अभिव्यक्तियों के लिए ऐसा करने के लिए मजबूर होना चाहता हूं, हालांकि।

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

if length(A) != length(B)
    throw(ArgumentError("lengths must match")
if some_condition(A, B)
   N *= 2

लेकिन, यह होगा:

if length(A) != length(B) throw(ArgumentError("lengths must match")
if some_condition(A, B) N *= 2

और यह होगा:

if length(A) != length(B)
    throw(ArgumentError("lengths must match")

if some_condition(A, B)
   N *= 2

यह आपको इस तरह की गलतियाँ करने से भी रोकेगा:

if is_present(x)
    y = 2 * x[]

    return y * 2

मुझे लगता है कि if x then y के लिए सबसे बड़ा तर्क जो अभी भी किसी भी अन्य वाक्यविन्यास पर जीतता है वह पठनीयता है । वह if x y end , if x y या x && y मेरी किताब में अप्रासंगिक है (इस तथ्य से परे कि हम 1-5 वर्ण अंतर के बारे में बात कर रहे हैं) क्योंकि उनमें से कोई भी नहीं लगभग if x then y जितना स्पष्ट है। यह संपादक को समस्याओं को पार्स करने या पिछले कोड के संभावित टूटने से भी बचाता है। यह सिर्फ एक अच्छा, साफ, छोटा वाक्य-विन्यास है, अगर बयानों के लिए।

हालांकि, मैं जनरेटर मामले में if-then के उपयोग के संभावित भ्रम को पहचानता हूं; यह देखते हुए, मैं सहमत हूं कि

x^2 if x % 3 == 0 for x = 1:100      # filtered generator
[ x^2 if x % 3 == 0 for x = 1:100 ]  # filtered comprehension

स्पष्ट है, यह स्वीकार करते हुए कि अभिव्यक्ति संरचना है

generated_value_expr  value_generator_expr  =>  generator_expression

[generator_filter_expr]  for_generator_expr  => value_generator_expr

यानी generator_filter_expr को गैर-फ़िल्टर किए गए मानों को generated_value_expr में पास करने से पहले for_generator_expr से उत्पन्न मानों पर सीधे लागू किया जाता है।

मुझे लगता है कि भेद यहाँ महत्वपूर्ण है, क्योंकि यह वही तर्क नहीं है जो अनुमति देगा

println("positive") if x > 0 

टीएल; डीआर: फ़िल्टर किए गए जेनरेटर के लिए हमारे पास x^2 if x % 3 == 0 for x = 1:100 होना चाहिए, लेकिन वही सिंटैक्स तर्क println("hey") if x > 0 पर लागू नहीं होता है, इसलिए, हमें अभी भी शॉर्ट-फॉर्म के लिए if x then y पर विचार करना चाहिए अगर-वाक्यविन्यास। हालांकि स्पष्ट रूप से यहां दो विचार अब पूरी तरह से असंबंधित हैं।

@ H-225 यह मेरे लिए अजीब और अंततः गैर-जूलियन लगता है, विशेष रूप से बिना end वाली नई लाइन पर कार्रवाई के साथ।

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

निश्चित रूप से:-1: मेरी ओर से if x y के लिए। मैं उस पर if x then y पसंद करूंगा, क्योंकि मेरे छोटे मस्तिष्क के लिए विश्लेषण करना आसान है। :जीभ चिढ़ाना आंख मारना:

क्या केवल इफ-स्टेटमेंट के लिए टर्नरी प्रश्न चिह्न ऑपरेटर का उपयोग न करने का कोई कारण है? आप पहले से ही एक if-statement की नकल कर सकते हैं

condition ? if_condition_true_eval_expr : nothing

क्यों न सिर्फ इसे बनाया जाए ताकि यदि आप एक कोलन शामिल नहीं करते हैं तो यह एक इफ-स्टेटमेंट है, तो आपके पास बस होगा

condition ? if_condition_true_eval_expr

इस तरह आपको कोई नया कीवर्ड पेश करने की ज़रूरत नहीं है, क्या यह काम करेगा?

@esprof मजेदार रूप से पर्याप्त, मैं इसके विपरीत सुझाव देने जा रहा था: इस जुलेप में अगर-तब-विचार को एक पंक्ति में विस्तारित करना यदि-तब-अन्य अभिव्यक्ति

if cond then a else b

जहां अन्य खंड वैकल्पिक है। यह समान रूप से cond ? b : c से भी कम हो सकता है। मेरे लिए, यह सी-स्टाइल टर्नरी से दूर होने और अधिक मानव-पठनीय कोड की ओर जाने के बारे में है। (मैंने निश्चित रूप से पहले condition ? a : nothing उपयोग किया है - यह एक हैक की तरह लगता है ('क्योंकि यह था, nothing कुछ अस्पष्ट कारणों से महत्वपूर्ण था) और यह अन्य लोगों के पढ़ने के लिए भ्रमित है)।

लेकिन निश्चित रूप से, हमारे पास ये सभी विचार एक साथ क्यों नहीं हो सकते?

@andyferris हाँ वह दूसरा है, पाइथोनिक, जाने का रास्ता। मुझे लगता है कि यह इस बात पर निर्भर करता है कि आप कितना संक्षिप्त होना चाहते हैं, गणितज्ञ आम तौर पर तीखापन दिखाते हैं, लेकिन ईमानदारी से कहूं तो मैं दोनों में से किसी के साथ खुश रहूंगा, जब तक कि मुझे क्लंकी का उपयोग करने की आवश्यकता नहीं है

if condition; eval_expr; end

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

if condition; eval_expr; end

वास्तव में!

इसके लायक क्या है, मुझे x && y संकेतन पसंद है और मैं इसे दुरुपयोग के रूप में नहीं देखता।

मैं व्यक्तिगत रूप से एक ऑपरेटर-आधारित समाधान पसंद करता हूं जो पहला कथन गलत होने पर false वापस नहीं करता है। मैं बहुत कुछ के साथ ठीक हो जाऊंगा, हालांकि मुझे a ?: b टर्नरी ऑपरेटर के दो-तर्क संस्करण के रूप में पसंद है।

? विचार पर #6823 में काफी विस्तार से चर्चा की गई थी, उस चर्चा को फिर से पढ़ने लायक हो सकता है।

मैं उस चर्चा से यहां आया, लेकिन लगा कि यह टिप्पणी करने के लिए एक बेहतर जगह है। मुझे लगता है कि if a then b और बिना : के केवल ? का उपयोग करना कुछ हद तक भ्रमित करने वाला होगा, लेकिन जब तक वे समान कार्यक्षमता प्रदान करते हैं तब तक शिकायत नहीं करेंगे।

मैं @EricForgy से सहमत हूं। हो सकता है कि मैं इस बिंदु पर उनका उपयोग कर रहा हूं, लेकिन मेरे लिए, इस तरह से && और || का उपयोग करना जूलिया के लिए मुहावरेदार महसूस करता है, विशेष रूप से त्रुटि जाँच के लिए (जैसे x || throw(y) ) वे बिल्कुल भी अस्पष्ट या अपठनीय नहीं लगते। साथ ही, मैं वास्तव में नहीं देखता कि यह क्यों मायने रखता है कि x && y false $ लौटाता है यदि x गलत है क्योंकि इसे शायद किसी फ़ंक्शन के अंत में उपयोग नहीं किया जाना चाहिए , जहां यह फ़ंक्शन के वापसी मूल्य को प्रभावित करेगा।

सी-स्टाइल टर्नरी बहुत सर्वव्यापी हैं; मैं तर्क दूंगा कि यह सिर्फ गणितज्ञ नहीं हैं जो इस वाक्यविन्यास को महत्व देते हैं। एकमात्र ऐसी भाषा जिसे मैं ऑफहैंड के बारे में सोच सकता हूं जिसमें टर्नरी है लेकिन सी-स्टाइल का समर्थन नहीं करता है, पायथन है, और एफडब्ल्यूआईडब्ल्यू मैं पाइथन टर्नरीज़ को तुच्छ जानता हूं। condition ? action1 : action2 जब तक आप व्हाइटस्पेस और सम्मान रेखा की लंबाई का उपयोग करते हैं, तब तक कॉम्पैक्ट और पठनीय दोनों होते हैं। लंबी स्थितियों और कार्यों के लिए, इसका उपयोग करना चाहिए

if condition
    somelongaction1
else
    somelongaction2
end

वैसे भी पठनीयता के लिए।

then के संबंध में, इस चर्चा का बिंदु, एफडब्ल्यूआईडब्ल्यू मैं शायद इसका उपयोग नहीं करता, भले ही इसे लागू किया गया हो, क्योंकि फिर से, && और || मुझे मुहावरेदार लगता है। हालांकि मैं then को if x y , x ? y , या x ? y : nothing से अधिक दिल की धड़कन में ले जाऊंगा।

व्यक्तिगत रूप से, मुझे y if x बहुत पसंद है। ऐसा लग सकता है कि यह गलत तरीके से चल रहा है, लेकिन रूबी और पर्ल से परे पूर्वता है: गणितीय केस सिंटैक्स में यह इस तरह से है

मैं इसके लिए && या || का उपयोग करने के लिए _like_ नहीं करता, क्योंकि मुझे कभी याद नहीं है कि x && y = z मेरी अपेक्षा के अनुरूप विश्लेषण नहीं करता है। मुझे लगता है कि इसका संज्ञानात्मक भार y if x ; जो if x y भी जाता है।

IMO, x ? y _smells_ एक सिंटैक्स त्रुटि की तरह, चाहे वह वास्तव में मान्य हो या नहीं।

x ?? y शायद? x ?: y एक GNU C एक्सटेंशन है जिसका अर्थ है x ? x : y , इसलिए ?? और ?: && और || निम्न-प्राथमिकता वाले संस्करण हो सकते हैं

मेरी वरीयता का क्रम: y if x == x ?? y < if x then y < x && y < x ? y < if x y ।

एफडब्ल्यूआईडब्ल्यू। मैं ? , && , और || के साथ कोड की संक्षिप्तता और स्पष्ट पृथक्करण पसंद करता हूं, हालांकि cond ? expr सिंटैक्स && से अधिक स्पष्ट हो सकता है

मैं अक्सर goodcondition || return प्रकार का प्रवाह करना पसंद करता हूं, जो कि if-statement के साथ आसान नहीं है। मैं इसे खोना नहीं चाहता (या इसका उपयोग न करने के लिए धमकाया जा सकता हूं)

: के बिना टर्नरी के लिए, else शर्त के बिना संक्षिप्त if / elseif ब्लॉक की अनुमति देना अच्छा हो सकता है:

x==5 ? f1() :
x==6 ? f2()

और कोई इसे स्विच-टाइप स्टेटमेंट में विस्तारित करने की कल्पना कर सकता है:

match x:
    5 ? f1() :
    6 ? f2()

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

जनरेटर के लिए, मैं where या when को if के पुनर्प्रयोजन से अधिक पसंद करूंगा, क्योंकि यह एक फ़िल्टर है, सशर्त नहीं:

x = [i^2 for i in 1:10 when i%2 == 0]

मुझे लगता है कि यह अधिक स्पष्ट है कि इसका अर्थ है x = [i^2 for i in filter(..., 1:10)] ।

मैं इस बात पर ध्यान दूंगा कि इस पर चर्चा करने के बाद से, मुझे अब if condition then action पर कोई आपत्ति नहीं होगी - यह मुझ पर बढ़ गया है।
जूलिया function और end आदि के साथ अधिक "शब्दशः" पक्ष पर झुकाव करती है, इसलिए मुझे लगता है कि यह ठीक से फिट होगा। चारों ओर ब्रैकेट जोड़ने के लिए यह थोड़ा परेशान है भाव यदि आप condition && action सिंटैक्स के बीच आगे और पीछे जाते हैं।

पर्ल/रूबी सिंटैक्स "एक्शन इफ कंडीशन" के बारे में: मुझे वास्तव में यह सिंटैक्स पसंद है, और जब मैं मानता हूं कि गलत तरीके से उपयोग किए जाने पर यह पठनीयता को कम कर सकता है, मेरा यह भी मानना ​​​​है कि यह कभी-कभी _increases_ पठनीयता।

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

throw(DomainError()) if some_condition || some_other_condition && so_on

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

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

(यदि मैं एक के बारे में सोच सकता हूं, तो मैं एक आत्म-संदर्भित उदाहरण वाक्य भी दूंगा।)

एक पुराने पर्ल हाथ के रूप में, मैं इस वाक्यविन्यास से सहानुभूति रखता हूं लेकिन मुझे लगता है कि यह उन लोगों के लिए कठिन बिक्री होगी जो पर्ल पृष्ठभूमि से नहीं आते हैं। पक्ष में एक तर्क यह है कि यह समझ में फ़िल्टर सिंटैक्स से मेल खाता है। इसके खिलाफ एक तर्क यह है कि एक निर्माण करना अजीब है जहां मूल्यांकन आदेश बाएं से दाएं नहीं है। बेशक, समझ ठीक यही है, इसलिए ‍♂️

मेरे लिए एक संबंधित प्रश्न तब है: क्या हम ब्रांचिंग या फ़िल्टरिंग को सामान्य कर रहे हैं? यह ब्रांचिंग if सेमेन्टिक्स (और सिंटैक्स) का एक सामान्यीकरण है, इसलिए शायद इस उद्देश्य के लिए समझ/जनरेटर से सिंटैक्स उधार लेना दुर्भाग्यपूर्ण होगा जहां वह सिंटैक्स पहले से ही फ़िल्टरिंग को इंगित करता है।

(वैसे, मुझे फ़िल्टरिंग के लिए कुछ अच्छा सिंटैक्स पसंद आएगा, जैसे हमारा अच्छा . सिंटैक्स। ऊपर मेरी बात को स्पष्ट करने के लिए शायद map - filter f.(a) if g.(a) दिख सकता है

f(x) for x in a # lazy map
f(x) for x in a if g(x) # lazy map - filter
x for x in a if g(x) # lazy filter where `f` is `identity`

f.(a) # map / broadcast
f.(a) if g.(a) # like a map/broadcast - filter operation
a if g.(a) # like the above where `f` is implicitly `identity`
[1,2,3] if [true, false, true] == [1, 3] # or something... here we simply make `if` an infix operator for filtering

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

अंत में - मैं ऊपर दिए गए @tbreloff की टिप्पणियों से सहमत हूं ... बाइनरी ? सबसे कॉम्पैक्ट सिंटैक्स है (और इस थ्रेड का पूरा बिंदु एक कॉम्पैक्ट सिंटैक्स बनाना है), और मुझे हमेशा if मिला

@StefanKarpinski ने लिखा:

पर्ल/रूबी-शैली अगर/संशोधक वाक्यविन्यास के लिए ऐसा लगता है कि यह इसके साथ बेहतर मिश्रण करेगा। दूसरे शब्दों में:
julia println("positive") if x > 0 # conditional execution x^2 for x=1:100 # generator [ x^2 for x=1:100 ] # comprehension x^2 if x % 3 == 0 for x = 1:100 # filtered generator [ x^2 if x % 3 == 0 for x = 1:100 ] # filtered comprehension
इसका अन्य भाषाओं में उदाहरण होने का भी लाभ है, जो कि अगर-फिर बिना अंत वाक्यविन्यास प्रतीत नहीं होता है।

और यह व्याकरण के लिए भी बेहतर होगा।

मुझे लगता है कि [x^2 if x % 3 == 0 for x = 1:100] होना चाहिए:

[(x^2 if x % 3 == 0) for x = 1:100]
 ```
Then `for` stay's in infix position which is currently an error. Of course we can change its meaning because of leading `[` but it would not work as generator:
```julia
x^2 if x % 3 == 0 for x = 1:100

मुझे लगता है कि [x^2 if x % 3 == 0 for x = 1:100] होना चाहिए:

वह फ़िल्टर्ड जनरेटर नहीं होगा। 2 if x 2 #$ लौटाता है जब x सच होता है, लेकिन जब x गलत होता है तो उसे भी कुछ वापस करना पड़ता है; आम तौर पर वह nothing होगा। तो यह संख्याओं और नोटिंग की एक सरणी देगा। यही कारण है कि फ़िल्टर किए गए जनरेटर सिंटैक्स में if को for के बाद आना पड़ता है।

हाँ आप सही हैं। शायद इसे इस तरह लिखा जाना चाहिए:

[for x = 1:100 x^2 if x % 3 == 0]

Afaics, यह कोष्ठक के उपयोग के बिना मान्य पार्स करने योग्य होगा, अच्छा!

बस सोच...

[ for x = 1:100 if x % 3 == 0 push x^2]
for x = 1:100 if x % 3 == 0 push x^2  # other keyword could be used, e.g. yield

यह अधिक प्राकृतिक निर्माण के समान है

for x=1:100 
    if x%3==0 
          push!(somearray, x^2)
    end
end

मैंने अभी कुछ और देखते हुए इस जूलप को फिर से देखा।

मैं अब भी if a then b सिंगल लाइन फॉर्म जैसा कुछ चाहता हूं; मुझे लगता है कि जूलियन प्रतिस्थापन a && b कई वर्षों तक इसका उपयोग करने के बाद भी काफी अपठनीय है: इसे सीधे अंग्रेजी वाक्य के रूप में पढ़ने का कोई तरीका नहीं है।

मुझे यह भी लगता है कि नवागंतुकों को a && b मुहावरे की व्याख्या करने की आवश्यकता एक तरह से शर्मनाक है जब हमारे पास एक वैकल्पिक वाक्यविन्यास हो सकता है जो स्वयं स्पष्ट है और केवल थोड़ा लंबा है।

इसे सीधे अंग्रेजी वाक्य के रूप में पढ़ने का कोई तरीका नहीं है

a && b को "ए और बी" के रूप में पढ़ता है जैसे "अगर ए तो बी भी करें"
a || b के रूप में "ए या बी" के रूप में पढ़ता है "ए सच होना चाहिए, अन्यथा बी करें"

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

इसके विपरीत मैंने हमेशा "ए या बी" को काफी पठनीय पाया है।

मजे की बात यह है कि इसके अलग-अलग पहलू आज दो बार काम के दौरान सामने आए।

सुबह में, हमारे पास जूलिया पीआर था जिसने if ... end के बजाय if ... end && का उपयोग किया और मैंने बताया कि, एक कोड रीडर (पीआर समीक्षक) के रूप में, इसमें अतिरिक्त प्रयास किया गया था (और याद करना आसान था) ) शाखाएँ जो निष्पादित हो भी सकती हैं और नहीं भी। उदाहरण a() && b!() फॉर्म का था जहां b! अत्यंत उत्परिवर्तित-वाई है। (इस मामले में, b!() फाइल सिस्टम में फाइलों को स्थानांतरित या हटा दिया गया, जो तुरंत खतरनाक लग रहा था, लेकिन मेरा दिमाग यह पता नहीं लगा सका कि यह केवल समस्याग्रस्त था जब !a() और यह मामला वास्तव में सही ढंग से संरक्षित किया गया था)।

दोपहर में, एक अन्य सॉफ्टवेयर इंजीनियर (जो जूलिया को नहीं जानता) ने बताया कि, दोस्तों के साथ अंग्रेजी बोलते समय, कभी-कभी वह "क्या यह a या b के प्रश्न का उत्तर देता है। " प्रतिक्रिया के साथ "हाँ"। उनके सॉफ्टवेयर इंजीनियर दोस्त ही समझेंगे-बाकी सब बिल्कुल नहीं समझेंगे। सामान्य लोग ऐसा नहीं सोचते। यह कुछ हद तक मेरे अगले बिंदु से संबंधित है (संपादित करें: और मुझे कहना चाहिए था, ऊपर स्टीफन की प्रतिक्रिया से संबंधित है, जो कई लोगों के लिए मुझे नहीं लगता कि उनके साथ ऐसा होगा)।

इस मुद्दे पर मेरा रुख यह है कि && (या || ) का उपयोग करना ब्रांचिंग के लिए एक छोटा वाक्यविन्यास है जो केवल एक मजबूत पीएल पृष्ठभूमि वाले लोगों द्वारा पठनीय है, और फिर भी थोड़ा सा जोड़ता है संज्ञानात्मक/दृश्य भार (बस & बनाम && में अंतर करने के लिए)। मुझे लगता है कि बहु-विषयक टीमों (वैज्ञानिकों और सॉफ्टवेयर इंजीनियरों का मिश्रण) में काम करते समय यह सक्रिय रूप से आधी टीम को भ्रमित कर रहा है। एक सॉफ्टवेयर इंजीनियर के रूप में भी, मुझे लगता है कि हमारे पास तार्किक &(::Bool, ::Bool) --> Bool और ब्रांचिंग &&(::Bool, ::Any) --> Any के बीच एक अजीब डिस्कनेक्ट है (हां, बाद वाला वास्तव में एक फ़ंक्शन नहीं है, लेकिन आप उम्मीद करते हैं कि आपको मेरी बात मिल जाएगी) . स्वयं के प्रकारों के अलावा, जूलिया में मैं आमतौर पर पूर्व को "कार्यात्मक" होने की अपेक्षा करता हूं जबकि बाद के रूप में अक्सर संभावित दुष्प्रभाव शामिल होते हैं - विशेष रूप से दूसरी अभिव्यक्ति में।

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

कुछ मामलों में, मुझे लगता है कि "प्राथमिकता" if a then b के साथ स्पष्ट है:

guard && c += 1    # probably an error because it's parsed as (guard && c) += 1
guard && (c += 1)  # parentheses required 

if guard then c += 1  # no ambiguity here

साथ ही संपादकों में सिंटैक्स हाइलाइटिंग अभिव्यक्ति की शुरुआत में if को चिह्नित करने में मदद करेगा।

इसका अन्य भाषाओं में उदाहरण होने का भी लाभ है, जो if - then बिना end सिंटैक्स के नहीं लगता है।

यह ध्यान दिया जाना चाहिए कि if-then-else सिंटैक्स के लिए _बहुत कुछ मिसाल है:

• हास्केल
• ओकैमली
• एफ#
• एल्म

और उस सिंटैक्स का उपयोग उपरोक्त सभी भाषाओं में वन-लाइनर्स के लिए किया जा सकता है।

मैं इस चर्चा के बारे में एक घंटे से अवगत हूं, इसलिए मुझे क्षमा करें यदि यह सुझाव दिया गया है।

यह मुझे '&&' और '||' के शॉर्ट-सर्किट विकल्पों की तरह लगता है उपयोग किया जाता है क्योंकि हम अर्ध-कॉलन के बिना एक पंक्ति में सरल if-statement चाहते हैं। लेकिन शॉर्ट-सर्किटिंग एक फिक्स की तरह लगता है जो एक और समस्या पैदा करता है: एक हमम के रूप में, उस वाक्य रचना को पहले से देखे बिना समझना और पार्स करना मुश्किल है, या यह जानते हुए कि दूसरी अभिव्यक्ति का मूल्यांकन केवल तब किया जाता है जब नेसेकेरी। गैर-सहज ज्ञान युक्त पठन (एक मानव के रूप में) शॉर्ट-सर्किटिंग के साथ दृश्य और तार्किक दोनों खामियों के कारण प्रतीत होता है। ऐसा भी लगता है कि इसका मतलब जानने के बाद, इसे पढ़ना मुश्किल हो सकता है।

अगर मैं गलत नहीं हूं, तो मैक्रो के साथ दोनों समस्याओं को ठीक किया जा सकता है:

@if स्थिति परिणाम

नकारात्मकता को एक के साथ नियंत्रित किया जा सकता है ! शर्त से पहले, या वैकल्पिक रूप से एक @ifnot मैक्रो। यह सिर्फ मैं हूं, या यह कंप्यूटर के लिए अस्पष्टता से मुक्त है, मानव के लिए पढ़ने में आसान है, और सभी एक पंक्ति में हैं?

ऐसा भी लगता है कि इसका मतलब जानने के बाद, इसे पढ़ना मुश्किल हो सकता है।

^ मैं इससे पूरी तरह सहमत हूं।

@if स्थिति परिणाम

आप पहले से ही निम्न कार्य कर सकते हैं, जो लगभग समान दिखता है:

if condition result end

नीचे पूर्ण अगर-तब-और सिंटैक्स के लिए मैक्रो है। हालांकि, चूंकि if और else आरक्षित कीवर्ड हैं, मैक्रो इसके बजाय If , Then , और Else उपयोग करता है।

syntax_error() = error("Valid syntax is either `<strong i="20">@If</strong> cond Then ex` or `<strong i="21">@If</strong> cond Then ex1 Else ex2`")

function If(exprs...)
    n_args = length(exprs)

    if n_args == 3
        if exprs[2] != :Then
            syntax_error()
        end

        ex = quote
            if $(exprs[1])
                $(exprs[3])
            end
        end
    elseif n_args == 5
        if ( exprs[2] != :Then ) || ( exprs[4] != :Else )
            syntax_error()
        end

        ex = quote
            if $(exprs[1])
                $(exprs[3])
            else
                $(exprs[5])
            end
        end
    else
        syntax_error()
    end

    return esc(ex)
end

macro If(exprs...)
    If(exprs...)
end

foo(x) = <strong i="22">@If</strong> x > 0 Then println("greater than zero") Else println("less than zero")

और यहाँ हम foo कार्रवाई में देख सकते हैं:

julia> foo(3)
greater than zero

julia> foo(-3)
less than zero

मैं कुछ पसंद करूंगा

x0 = 1
x1 = 2
x3 = 3 when y>0  # y>0 is evaluated first
x4 = 4

कब = से कम प्राथमिकता होगी और दाएं से बाएं संचालित होगी।

आप पहले से ही निम्न कार्य कर सकते हैं, जो लगभग समान दिखता है:

if condition result end

मैं यह नहीं जानता था! मैं हमेशा हालांकि उस व्यक्ति को अर्धविराम की आवश्यकता होती है जहां सामान्य रूप से एक नई रेखा होती है। तो मेरे मामले में, वाक्य रचना

if condition result end

पूरी तरह से && के उपयोग को निरर्थक बना देता है, और इसलिए कोई समस्या नहीं है! मैं देखता हूं कि कोई निम्न कार्य भी कर सकता है:

if condition result_1 else result_2 end

इस मामले में, end कीवर्ड जोड़ना मैक्रो बनाने की तुलना में शायद आसान है। लेकिन इसे किसी भी तरह से बनाने के लिए समय निकालने के लिए धन्यवाद ^ _ ^ क्या दस्तावेज़ीकरण में एक-पंक्ति इफ़-स्टेटमेंट की संभावना को जोड़ना एक अच्छा विचार है? मैं देख रहा हूं कि अगर कोई ?If<enter> करता है तो परिणाम पहले से ही कुछ पंक्तियों में है ... लेकिन मुझे लगता है कि इस सुविधा का और अधिक विज्ञापन किया जाना चाहिए।

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