हास्केल फ़ंक्शन रचना (।) और फ़ंक्शन एप्लिकेशन ($) मुहावरे: सही उपयोग


129

मैं रियल वर्ल्ड हास्केल पढ़ रहा हूं, और मैं अंत के करीब हूं, लेकिन स्टाइल का मामला मुझ पर (.)और ($)ऑपरेटरों के साथ करने के लिए मुझे परेशान कर रहा है ।

जब आप एक फ़ंक्शन लिखते हैं जो अन्य कार्यों की एक रचना है जिसे आप इसे लिखते हैं:

f = g . h

लेकिन जब आप उन कार्यों के अंत में कुछ लागू करते हैं तो मैं इसे इस तरह से लिखता हूं:

k = a $ b $ c $ value

लेकिन किताब इसे इस तरह से लिखेगी:

k = a . b . c $ value

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

क्या पुस्तकों के तरीके का उपयोग करने का कोई कारण है जो सभी ($)प्रतीकों का उपयोग करने से बहुत बेहतर है ? या यहाँ कुछ सबसे अच्छा अभ्यास है जो मुझे नहीं मिल रहा है? या यह बहुत ही शानदार है और मुझे इसके बारे में चिंता नहीं करनी चाहिए?


4
ध्यान दें कि दूसरा उदाहरण के रूप में किया जा सकता हैk = a $ b $ c value
थॉमस Eding

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

2
एक अन्य सामान्य दृष्टिकोण है a . b $ c value, जो मुझे तीसरे उदाहरण के रूप में बहुत पसंद नहीं है, लेकिन कुछ पात्रों को बचाता है।
जॉन एल

जवाबों:


153

मुझे लगता है कि मैं प्राधिकरण से इसका जवाब दे सकता हूं।

क्या पुस्तकों के तरीके का उपयोग करने का कोई कारण है जो सभी ($) प्रतीकों का उपयोग करने से बेहतर है?

कोई विशेष कारण नहीं है। ब्रायन और मैं दोनों ही लाइन के शोर को कम करना पसंद करते हैं। .से शांत है $। परिणामस्वरूप, पुस्तक f . g . h $ xवाक्य रचना का उपयोग करती है।


3
खैर, मैं इस एक से बेहतर जवाब की उम्मीद नहीं कर सकता; स्वयं लेखकों में से एक से। :) और यह समझ में आता है, यह पृष्ठ पर बहुत शांत दिखता है जैसा कि मैंने पढ़ा है। इसे उत्तर के रूप में चिह्नित करना क्योंकि यह सीधे प्रश्न का उत्तर देता है। जवाब देने के लिए धन्यवाद; और, पुस्तक, infact।
रॉबर्ट मसाइली

38
लेखक से असहमत नहीं है, लेकिन मुझे लगता है कि इसका उपयोग करने के बजाय कुछ बनाने के मानसिक मॉडल में एक और अधिक प्रमुख कारण है। हास्केल उपयोगकर्ता इसके बजाय एक नए चतुर निर्माण के बारे में सोचना चाहते हैं । अब वे एक नए, यद्यपि अज्ञात, फ़ंक्शन को कॉल कर रहे हैं, जो उन्होंने PHP उपयोगकर्ता की तरह पूर्वनिर्मित फ़ंक्शन कॉल के एक बड़े शब्दकोश का पीछा करने के बजाय बनाया है। f.g.hf(g(h()))
इवान कैरोल

1
यह एक दिलचस्प कथन है: 'लाइन का शोर कम करें' और 'से शांत'। मैंने इस शब्दावली में प्रोग्रामिंग भाषाओं के बारे में कभी नहीं सोचा था, लेकिन यह बिल्कुल सही समझ में आता है।
राबार्स्की

53

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

k = a (b (c (value)))

तथा

k = (a . b . c) value

पसंद करते हैं के लिए कारण .से अधिक संस्करण $आकर्षक अपील: संस्करण ऊपर बहुत parenthesized संस्करण पर दोनों पसंद करते हैं के लिए एक ही कारण है।

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


38

मुझे लगता है कि में जोड़ना होगा f . g $ x, f . gएक सार्थक वाक्यात्मक इकाई है।

इस बीच, में f $ g $ x, f $ gएक सार्थक इकाई नहीं है। की एक श्रृंखला $यकीनन अधिक जरूरी है - पहले की परिणाम प्राप्त gकी x, तो कर fइसे करने के लिए, तो कर fooइसे करने के लिए, तो आदि

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


2
मैं हास्केल सीख रहा हूँ (कुछ भी सार्थक नहीं कोडित किया गया है) लेकिन मुझे "पाइप" ऑपरेटर के एक प्रकार के रूप में $ सोचना पसंद है। इसके टर्मिनल की तरह | पाइप (डेटा प्रवाह को छोड़कर दाएं-बाएं), लेकिन टर्मिनल प्रक्रियाओं की तरह प्रत्येक इकाई स्पष्ट रूप से स्वतंत्र है।
लॉस्टसालड

1
$ऑपरेटर के लिए समान व्यवहार करने लगता है <|एफ # में ऑपरेटर। मेरा मानना ​​है कि दोनों को समान रूप से परिभाषित किया गया है, वास्तव में - एफ # में, (<|) a b = a bऔर हास्केल में a $ b = a b, जो अनिवार्य रूप से समतुल्य हैं।
टॉम गैल्विन

@Quackmatic निश्चित रूप से यह (<|) b a = a bF # में है, क्योंकि इसका उपयोग तब किया जाता है [1; 2; 3; 4; 5] <| List.map ((+) 1), यदि स्मृति कार्य करती है।
BalinKingOfMoria CM

@BalinKingOfMoria <|ऑपरेटर फ़ंक्शन को मान देने के बजाय फ़ंक्शन को मान पास करता है - आपका कोड उदाहरण |>ऑपरेटर के साथ काम करेगा , इसके बजाय।
टॉम गैल्विन

@Quackmatic ओह। नहीं पता था कि कई संस्करण थे (मैंने F # का उपयोग नहीं किया है)।
BalinKingOfMoria 15:22

18

मेरे लिए, मुझे लगता है कि जवाब है (क) साफ-सुथरा, जैसा कि डॉन ने कहा ; और (बी) मुझे पता है कि जब मैं कोड संपादित कर रहा हूं, तो मेरा कार्य बिंदु-मुक्त शैली में समाप्त हो सकता है, और फिर मुझे बस इतना करना होगा कि $वापस जाने और सब कुछ बदलने के बजाय अंतिम को हटा दें । एक मामूली बिंदु, निश्चित रूप से, लेकिन एक नोक।


हाँ, यह इस तरह से लिखने का एक अच्छा कारण है, यदि आप एक फ़ंक्शन संरचना में समाप्त करना चाहते हैं तो यह तेज़ है। :) कीस्ट्रोक्स को बचाने के लिए याय, लेकिन अधिक महत्वपूर्ण समय। +1
रॉबर्ट मैसैओली

13

इस हस्केल-कैफे थ्रेड पर इस सवाल की एक दिलचस्प चर्चा है । जाहिर है वहाँ एक अल्पसंख्यक दृष्टिकोण है कि मानती है कि का सही संबद्धता है $है "सिर्फ सादा गलत" , और चुनने f . g . h $ xसे अधिक f $ g $ h $ xमुद्दा पक्ष कदम का एक तरीका है।


अरे, आपने मामले पर पूरी चर्चा की। यह बहुत बढ़िया है, मैं अभी पढ़ रहा हूं। +1
रॉबर्ट मैसैलो

2
यहाँ इसी तरह के तर्क: ghc.haskell.org/trac/haskell-prime/wiki/…
enrique

ध्यान दें कि $!"सादा गलत" सही सहानुभूति भी है - $ क्यों है! ऑपरेटर सही सहयोगी?
इम्ज़ - इवान ज़खरीशेव

3

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

आपका तरीका अभी अजीब लग रहा है, और अंतिम $अनावश्यक है।

हालांकि, यह वास्तव में कोई फर्क नहीं पड़ता। हास्केल में, आमतौर पर एक ही काम करने के कई, कई, सही तरीके होते हैं।


3
मैंने ध्यान नहीं दिया कि अंतिम $ अनावश्यक था लेकिन मेरे पास होना चाहिए था। धन्यवाद और मैं इसे वहां छोड़ दूंगा ताकि लोगों को पता चले कि इस टिप्पणी का क्या मतलब है।
राबर्ट मसायोली

0

मुझे लगता है कि यह एक बहुत पुराना सवाल है, लेकिन मुझे लगता है कि इसका एक और कारण है जिसका उल्लेख नहीं किया गया है।

यदि आप एक नया बिंदु-मुक्त फ़ंक्शन घोषित कर रहे हैं f . g . h, तो आपके द्वारा पास किया जाने वाला मान स्वचालित रूप से लागू हो जाएगा। हालांकि, अगर आप लिखते हैं f $ g $ h, तो यह काम नहीं करेगा।

मुझे लगता है कि लेखक रचना पद्धति को पसंद करने का कारण यह है कि इससे कार्यों के निर्माण का अच्छा अभ्यास होता है।

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.