वाई कॉम्बिनेटर और पूंछ कॉल अनुकूलन


20

एफ # में एक वाई कॉम्बिनेटर की परिभाषा है

let rec y f x = f (y f) x

च के पहले तर्क के रूप में पुनरावर्ती उपप्रकारों के लिए कुछ निरंतरता होने की उम्मीद है। एक निरंतरता के रूप में yf का उपयोग करते हुए, हम देखते हैं कि च को लगातार कॉल पर लागू किया जाएगा जैसा कि हम विकसित कर सकते हैं

let y f x = f (y f) x = f (f (y f)) x = f (f (f (y f))) x etc...

समस्या यह है कि, एक प्राथमिकता, यह योजना किसी भी पूंछ कॉल अनुकूलन का उपयोग करती है: वास्तव में, एफ में लंबित कुछ ऑपरेशन हो सकता है, जिस स्थिति में हम एफ से जुड़े स्थानीय स्टैक फ्रेम को केवल म्यूट नहीं कर सकते हैं।

इसलिए :

  • एक छोर पर, वाई कॉम्बिनेटर के उपयोग से फ़ंक्शन की तुलना में एक स्पष्ट अलग निरंतरता की आवश्यकता होती है।
  • टीसीओ लागू करने के लिए, हम चाहेंगे कि कोई भी कार्यवाही च में लंबित न हो और केवल स्वयं को कॉल करें।

क्या आप किसी भी तरह से जानते हैं कि उन दोनों में सामंजस्य स्थापित किया जा सकता है? संचायक चाल के साथ Y की तरह, या CPS चाल के साथ Y? या एक तर्क यह साबित करता है कि ऐसा कोई तरीका नहीं है?


क्या आपने अपने कार्यान्वयन के लिए आरईसी कीवर्क को जोड़ा है? मुझे यह सोचना चाहिए कि इसे मेरे पढ़ने से चाहिए ..
जिमी हॉफ

क्या आपके पास सबूत है कि यह पूंछ कॉल का अनुकूलन नहीं करता है? मुझे लगता है कि आप उस समारोह के लिए आईएल पढ़ना चाहते हैं और देख सकते हैं, मुझे आश्चर्य नहीं होगा कि कंपाइलर कुछ के साथ आने के लिए पर्याप्त स्मार्ट है ..
जिमी होफा

सीधी अनुत्तरित पुनरावृत्ति के मामले में यह नहीं होता है: हालाँकि आप इसे फिर से लिख सकते हैं कि इस तरह की चीज़ के लिए अनुमति दें तथ्य यह है कि स्टैक फ्रेम को y कॉल के माध्यम से पुन: उपयोग किया जाता है। हाँ, आईएल को देखने की आवश्यकता हो सकती है, इसमें कोई अनुभव नहीं है।
निकोलस

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

जवाबों:


4

क्या आप किसी भी तरीके से जानते हैं जिसमें उन दोनों को समेटा जा सकता है?

नहीं, और अच्छे कारण के साथ, IMHO।

वाई-कॉम्बिनेटर एक सैद्धांतिक निर्माण है और इसे केवल लैम्ब्डा कैलकुलस को पूरा करने के लिए बनाने की आवश्यकता है (याद रखें, लैम्ब्डा कैलकुलस में कोई लूप नहीं हैं, न ही लैम्ब्डा में ऐसे नाम हैं जो हम पुनरावृत्ति के लिए उपयोग कर सकते हैं)।

जैसे, वाई कॉम्बिनेटर वास्तव में आकर्षक है।

लेकिन : वास्तविक पुनरावर्तन के लिए कोई भी वास्तव में वाई-कॉम्बिनेटर का उपयोग नहीं करता है! (मस्ती के लिए शायद छोड़कर, यह दिखाने के लिए कि यह वास्तव में काम करता है।)

टेल-कॉल ऑप्टिमाइज़ेशन, OTOH, जैसा कि नाम कहता है, एक ऑप्टिमाइज़ेशन है। यह एक भाषा की व्यापकता के लिए कुछ भी नहीं जोड़ता है, यह केवल व्यावहारिक विचारों जैसे स्टैक स्पेस और पुनरावर्ती कोड के प्रदर्शन के कारण है जो हम इसकी परवाह करते हैं।

तो आपका प्रश्न इस प्रकार है: क्या बीटा कमी के लिए हार्डवेयर समर्थन है? (बीटा कमी यह है कि लैम्ब्डा एक्सप्रेशन कैसे कम किए जाते हैं, आप जानते हैं।) लेकिन कोई कार्यात्मक भाषा (जहां तक ​​मुझे जानकारी है) लैम्बडा एक्सप्रेशन के प्रतिनिधित्व के लिए इसके सोर्स कोड को संकलित करता है जो कि रनटाइम में कम हो जाएगा।


2
वाई-कॉम्बिनेटर एक गाँठ को फिर से जोड़ने जैसा है जो प्रत्येक उपयोग के बाद अप्रयुक्त रहता है। अधिकांश प्रणालियों ने इसे छोटा कर दिया और गाँठ को मेटा-स्तर पर बाँध दिया, जैसे कि इसे कभी भी सेवानिवृत्त होने की आवश्यकता नहीं है।
दान डी।

1
अंतिम पैराग्राफ के अनुसार, हास्केल पर विचार करें जो आलसी मूल्यांकन करने के लिए ग्राफ में कमी का उपयोग करता है । लेकिन मेरा पसंदीदा इष्टतम कमी है जो चर्च-रोसेर जाली में हमेशा कम से कम पूर्ण सामान्य रूप में कटौती के साथ पथ लेता है। जैसे कि एस्परटी और गुरेरिनी की ऑप्टिमल इंप्लीमेंटेशन ऑफ फंक्शनल प्रोग्रामिंग लैंग्वेजेज में दिखाई देता हैBOHM 1.1 भी देखें ।
दान डी।

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

1
वास्तविक यह ग्राफ की कमी का उपयोग करता है: "जीएचसी स्पिनलेस टैगलेस जी-मशीन (एसटीजी) के लिए संकलित करता है। यह एक कुख्यात ग्राफ कमी मशीन है (यानी, एक आभासी मशीन जो ऊपर बताए अनुसार ग्राफ में कटौती करती है)।" से ... एसटीजी मशीन पर अधिक के लिए, साइमन पेटन जोन्स को स्टॉक हार्डवेयर पर आलसी कार्यात्मक भाषाओं को लागू करते हुए देखें: स्पिनलेस टैगलेस जी-मशीन
दान डी।

@DanD। आपके द्वारा लिंक किए गए एक ही लेख में, यह आगे पढ़ता है कि जीएचसी "उस प्रतिनिधित्व पर कई अनुकूलन करता है, अंत में इसे वास्तविक मशीन कोड (संभवतः जीसीसी का उपयोग करके सी के माध्यम से) में संकलित करता है।"
इंगो

0

मैं इस उत्तर के बारे में पूरी तरह से निश्चित नहीं हूं, लेकिन यह सबसे अच्छा है जिसके साथ मैं आ सकता हूं।

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

let rec y f x = f (y f) x

आपकी परिभाषा यह देखती है कि इसे समाप्त करने के लिए आलस्य की आवश्यकता होती है, या (y f)तर्क कभी भी मूल्यांकन समाप्त नहीं करेगा और इसका मूल्यांकन करना होगा या नहीं f। TOC एक आलसी संदर्भ में अधिक जटिल है, और इसके परिणामस्वरूप (y f)आवेदन के साथ दोहराया समारोह रचना का परिणाम है x। मुझे यकीन नहीं है कि यह ओ (एन) मेमोरी लेने की जरूरत है जहां n पुनरावृत्ति की गहराई है, लेकिन मुझे संदेह है कि आप टीओसी के उसी प्रकार को प्राप्त कर सकते हैं जैसे कि कुछ के साथ संभव है (जैसे हास्केल पर स्विच करना क्योंकि मुझे वास्तव में नहीं पता है एफ #)

length acc []    = acc
length acc (a:b) = length (acc+1) b 

यदि आप पहले से ही इसके बारे में नहीं जानते हैं, foldlऔर foldl'हास्केल के बीच का अंतर स्थिति पर कुछ प्रकाश डाल सकता है। foldlएक उत्सुक भाषा में किया जाएगा के रूप में लिखा है। लेकिन TOC'd होने के बजाय, यह वास्तव में इससे भी बदतर है foldrक्योंकि एक्सीलेटर संभावित रूप से विशाल थंक को संग्रहीत करता है जिसका आंशिक मूल्यांकन नहीं किया जा सकता है। (यह इस बात से संबंधित है कि फोल्ड और फोल्डल दोनों 'अनंत सूचियों पर काम नहीं करते हैं।) इस प्रकार हास्केल के अधिक हाल के संस्करणों में foldl'जोड़ा गया था , जो संचयकर्ता के मूल्यांकन को बल देता है, जब भी फ़ंक्शन यह सुनिश्चित करता है कि कोई भारी गड़बड़ी पैदा न हो। मुझे यकीन है कि http://www.haskell.org/haskellwiki/Foldr_Foldl_Foldl%27 I से बेहतर व्याख्या कर सकता है।

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