कुछ कार्यात्मक प्रोग्रामिंग भाषाएं फ़ंक्शन एप्लिकेशन के लिए स्थान का उपयोग क्यों करती हैं?

34

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

इसलिए अगर हमारे पास एक फंक्शन (x) = x are है तो इसे कॉल करने के दो विकल्प हैं:

एफपी: f x

उदाहरण:
- ML, Ocaml, F #
- हास्केल
- LISP, स्कीम (किसी तरह)
गैर एफपी: f(x)

उदाहरण:
- लगभग सभी अनिवार्य भाषाएँ (मुझे पता है, टिप्पणियाँ / उत्तर देखें)
- Erlang
- स्काला (एकल तर्कों के लिए "ऑपरेटर संकेतन" की भी अनुमति देता है)

कोष्ठकों को "छोड़ने" के क्या कारण हैं?

programming-languages functional-programming

— pvorb
स्रोत

9

इसे और अधिक भ्रामक बनाने के लिए, erm, मेरा मतलब था रसीला ।

— डेन

11

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

— साइमन बर्गोट

5

आपको यह कहने की विडंबना का एहसास है कि लघुकोष्ठक का उपयोग करना अधिक गणितीय होगा और फिर x²एक उदाहरण के रूप में घातांक फ़ंक्शन का उपयोग करना होगा ?

— जोर्ग डब्ल्यू मित्तग

12

@ जब आप किसी भाषा को उसके सिंटैक्स के कारण अस्वीकार करके खुद को नुकसान पहुंचा रहे हों। निश्चित रूप से आपको xml या sql सीखने में कोई परेशानी नहीं हुई (वे सामान्य प्रयोजन की भाषा नहीं हैं, लेकिन वे अपने स्वयं के वाक्यविन्यास को परिभाषित करते हैं)।

— सिमोन बर्थगोट

7

मैं यह बताना चाहूंगा कि शेल स्क्रिप्ट (जैसे bash) आम तौर पर कमांड को कॉल करने के लिए मापदंडों का उपयोग नहीं करते हैं। PowerShell सॉर्ट में दोनों ही दुनिया में सबसे खराब कार्य उस कोष्ठक के साथ घोषित किए जाते हैं और उनके बिना कहा जाता है।

— क्रिश हार्पर

59

जो अधिक गणितीय तरीका लगता है

कार्यात्मक भाषाएं लैम्ब्डा कैलकुलस से प्रेरित हैं । इस क्षेत्र में, कोष्ठक का उपयोग फ़ंक्शन अनुप्रयोग के लिए नहीं किया जाता है।

मुझे यह भी लगता है कि बाद की शैली बहुत अधिक स्पष्ट और पठनीय है, बिना परनों के।

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

इस सम्मेलन का उपयोग करने के लिए करी भी एक अच्छा कारण है। हैस्केल में, आप निम्नलिखित को परिभाषित कर सकते हैं:

add :: Int -> Int -> Int
add x y = x + y

x = add 5 6 -- x == 11
f = add 5
y = f 6 -- y == 11
z = ((add 5) 6) -- explicit parentheses; z == 11

Parens के साथ, आप दो सम्मेलन का उपयोग कर सकते हैं: f(5, 6)(करी नहीं) या f(5)(6)(करी)। हैक्सेल सिंटेक्स क्यूरिंग अवधारणा के लिए उपयोग करने में मदद करता है। आप अभी भी एक गैर-करी संस्करण का उपयोग कर सकते हैं, लेकिन कॉम्बिनेटर के साथ इसका उपयोग करना अधिक दर्दनाक है

add' :: (Int, Int) -> Int
add' (x, y) = x + y
u = add'(5, 6) -- just like other languages
l = [1, 2, 3]
l1 = map (add 5) l -- [6, 7, 8]
l2 = map (\x -> add'(5, x)) l -- like other languages

ध्यान दें कि दूसरा संस्करण आपको एक चर के रूप में x को पंजीकृत करने के लिए कैसे मजबूर करता है, और यह कि उपप्रकार एक फ़ंक्शन है जो पूर्णांक लेता है और इसमें 5 जोड़ता है? करी संस्करण बहुत हल्का है, लेकिन बहुत से पठनीय माना जाता है।

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

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

फ़ंक्शन अनुप्रयोग के लिए अन्य कन्वेंशन भी हैं:

लिस्प: (एफएक्स) - बाहरी कोष्ठक के साथ उपसर्ग
फोर्थ: xf - पोस्टफिक्स

— साइमन बर्गोट
स्रोत

7

माइनर नाइटपिक: शब्द "क्यूरिंग" और "क्यूरेड" हैं, न कि "क्यूरिफ़िकेशन" और "क्यूरिफ़ाइड"।

— डोभाल

"नॉन करी" हस्केल में एक गैर-करीबी फ़ंक्शन क्या है?

— वेन

3

@ user1737909 एक फ़ंक्शन जो एक तर्क के रूप में एक ट्यूपल लेता है।

— डोभाल

1

@ डोवाल वास्तव में यह "स्कोन्फिंकलिंग" और "स्कोन्फिंकेल्ड" होना चाहिए। लेकिन ओह ठीक है, इतिहास हमेशा विजेता को पूर्वव्यापी रूप से परिभाषित करता है।

— प्रोफैप्टेक

एक parenthesized currying वाक्य रचना, कुछ तरह के बारे में सोच f(a, ,b)या add(a, )या add(, b)डिफ़ॉल्ट रूप से और अधिक लचीला प्रतीत होता है।

— १०:३० पर

25

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

ध्यान दें कि यह कार्यात्मक भाषाओं के लिए विशिष्ट नहीं है, जैसे में स्मालटाक , पहले OO भाषाओं और भाषाओं यह से प्रेरित (में से एक स्व , Newspeak , ऑब्जेक्टिव-सी), लेकिन यह भी आईओ और यह से प्रेरित भाषाओं (Ioke, Seph) में, व्हाट्सएप का इस्तेमाल मेथड कॉल के लिए किया जाता है।

स्मालटाक शैली:

anArray sort
anArray add: 2
aString replace: "a" with: "b"

(उत्तरार्द्ध मामले में, विधि का नाम है replace:with:)

आईओ-शैली:

anArray sort
anArray add(2)
aString replace("a", "b")

स्काला विधि कॉल के लिए भी व्हाट्सएप की अनुमति देता है:

foo bar(baz)

और यदि केवल एक ही तर्क हो तो कोष्ठकों को छोड़ देना:

foo bar baz

रूबी आपको कोष्ठक छोड़ने की अनुमति देती है:

an_array.sort
an_array.add 2
a_string.replace "a", "b"

कोष्ठक का उपयोग करना, जो अधिक गणितीय तरीका लगता है

ज़रुरी नहीं:

f(x)
sin x
x²
|x|
x!
x + y
xy
½

मैथ नोटेशन लंबे समय से एक भयानक तरीके से विकसित हुआ है।

यदि सभी में, कार्यात्मक भाषाएं λ-पथरी से अपनी प्रेरणा लेती हैं, जहां व्हाट्सएप का उपयोग करके फ़ंक्शन एप्लिकेशन लिखा जाता है।

— जॉर्ग डब्ल्यू मित्तग
स्रोत

3

संपादन की अर्थव्यवस्था के लिए भी एक तर्क है। विशेष रूप से, कार्यात्मक भाषाएं आमतौर पर सीधे रचना का समर्थन करती हैं। तर्क के बजाय फ़ंक्शन के चारों ओर कोष्ठकों को रखना समझ में आता है। आपको केवल "एक बार" करना है: (e। F। G) x को e (f (g (x))) के विपरीत। साथ ही, हास्केल, कम से कम, एक को x के बजाय f (x) करने से नहीं रोकेगा। यह सिर्फ मुहावरेदार नहीं है।

— नोमन जूल

18

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

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

— सीन डी
स्रोत

7

नहीं भी हो मुझ पर शुरू कर दिया है f(x)बनाम sin xबनाम x²बनाम |x|बनाम x!बनाम x + yबनाम xyबनाम ½बनाम एक योग बनाम एक अभिन्न बनाम ...

— Jörg डब्ल्यू Mittag

2

वॉन न्यूमन बोली के लिए +1। शेष उत्तर के लिए +1, लेकिन मैं +2 नहीं दे सकता। :(

— poverb

2

मैं यहाँ अभिजात्य वर्ग का एक संकेत पकड़ता हूं; मैं "कार्यात्मक प्रोग्रामिंग भाषा डिजाइनर बेहतर शिक्षित हूं " की तटस्थता पर विवाद करता हूं ।

— कैप्टनकोडमैन

7

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

— पॉल

5

@CaptainCodeman नहीं, क्योंकि उन्होंने कभी नहीं निहित किया कि वे सामान्य रूप से अधिक शिक्षित हैं, बस गणित में अधिक शिक्षित हैं। ठीक यही उन्होंने कहा: "व्यापक गणितीय शिक्षा"। :)

— पॉल

8

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

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

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

val message = line split "," map (_.toByte)

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

— कार्ल बेवफेल्ड
स्रोत

2

"लब्बोलुआब यह है, उन सभी कोष्ठकों को पढ़ने और ट्रैक करने के लिए परेशान किया जाता है। यह संभवतः एक कारण है कि LIS अधिक लोकप्रिय नहीं है।": मुझे नहीं लगता कि कोष्ठक लिस्प के लोकप्रिय नहीं होने का एक कारण है: मुझे नहीं लगता है वे विशेष रूप से पढ़ना मुश्किल हैं, और मुझे लगता है कि अन्य भाषाओं में बहुत अधिक अजीब वाक्यविन्यास है।

— जियोर्जियो

2

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

— कार्ल बेवेलफेल्ट

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

— सेस टिम्मरमैन

4

दोनों ही परिसर गलत हैं।

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

जीएचसीआई> एफ ३
४
जीएचसीआई> एफ (३)
४
जीएचसीआई> (एफ) ३
४

बेशक अगर आप न तो एक जगह का उपयोग करते हैं और न ही परेंस का, तो यह आम तौर पर काम नहीं करेगा, बस क्योंकि अभिव्यक्ति ठीक से टोकन नहीं है

GHCi> f3

<‌interactive>: 7: 1:
दायरे में नहीं: 'f3'
शायद आपका मतलब 'f' (पंक्ति 2) था

लेकिन अगर इन भाषाओं को 1-वर्ण चर नामों तक ही सीमित रखा गया तो यह भी काम करेगी।
न ही गणित सम्मेलनों में आमतौर पर फ़ंक्शन अनुप्रयोग के लिए कोष्ठक की आवश्यकता होती है। न केवल गणितज्ञ अक्सर पाप x लिखेंगे - रैखिक कार्यों के लिए (आमतौर पर रैखिक ऑपरेटरों कहा जाता है) तो यह भी बहुत सामान्य है कि बिना तर्क के तर्क लिख सकते हैं, शायद क्योंकि (कार्यात्मक प्रोग्रामिंग में किसी भी फ़ंक्शन की तरह) रैखिक कार्यों को अक्सर सीधे आपूर्ति के बिना नियंत्रित किया जाता है एक विवाद।

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

— leftaroundabout
स्रोत

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

— पॉवरब

2

न ही गैर-कार्यात्मक भाषाएं हैं जो कोष्ठक की आवश्यकता में एकमत हैं; कुछ उदाहरणों के लिए, स्मॉलटाक के पास object method: args, ऑब्जेक्टिव C है [object method: args], और रूबी और पर्ल दोनों को फंक्शन और मेथड कॉल्स में पैरेंटिंग को छोड़ने की अनुमति देता है, केवल उन्हें अस्पष्टता को हल करने की आवश्यकता होती है।

— जूल

1

एक छोटा ऐतिहासिक स्पष्टीकरण: गणित में मूल अंकन कोष्ठक के बिना था !

लीबनीज ने कार्यों की बात शुरू करने के तुरंत बाद 1700 के आसपास जोहान बर्नौली द्वारा एक्स के एक मनमाने कार्य के लिए संकेतन एफएक्स पेश किया था (वास्तव में बर्नौली ने ) x लिखा था )। लेकिन है कि कई लोगों को पहले से ही जहां की तरह पाप अंकन का प्रयोग करके करने से पहले एक्स या lx (के लघुगणक एक्स के लिए) विशिष्ट के कार्यों एक्स , कोष्टक के बिना। मुझे संदेह है कि आज भी बहुत से लोग पाप (x) के बजाय पाप x लिखते हैं ।

बरनौली के छात्र रहे यूलर ने बर्नौली के changed x को अपनाया और एफएक्स लिखकर ग्रीक को लैटिन पत्र में बदल दिया । बाद में उन्होंने देखा कि "मात्रा" के लिए f को भ्रमित करना आसान हो सकता है और यह मानना है कि fx एक उत्पाद था, इसलिए उन्होंने f: x लिखना शुरू किया । इसलिए नोटेशन एफ (एक्स) यूलर के कारण नहीं है। बेशक यूलर को कोष्ठक की आवश्यकता थी उसी कारण से हमें अभी भी कार्यात्मक प्रोग्रामिंग भाषाओं में कोष्ठक की आवश्यकता है: उदाहरण के लिए (fx) + y को f (x + y) से अलग करना । मुझे संदेह है कि ईयूलर के बाद लोग कोष्ठक को एक डिफ़ॉल्ट के रूप में अपनाते हैं क्योंकि उन्होंने मुख्य रूप से ईयूलर को एफ (कुल्हाड़ी + बी) जैसे यौगिक भाव लिखते हुए देखा था।। उन्होंने शायद ही सिर्फ एफएक्स लिखा हो ।

इस पर और अधिक देखें: क्या Euler ने कभी कोष्ठक के साथ f (x) लिखा था? ।

मुझे नहीं पता कि कार्यात्मक प्रोग्रामिंग भाषाओं के डिजाइनर या लैंबडा कैलकुलस के आविष्कारक उनके अंकन की ऐतिहासिक जड़ों से अवगत थे। व्यक्तिगत रूप से मैं बिना अधिक प्राकृतिक रूप से कोष्ठक के अंकन को पाता हूं।

— माइकल बेअख्तोल्ड
स्रोत