2009-02-13 15 views
7

में कार्यों के आंतरिक भागों की जांच मैं एक Haskell नौसिखिया हूँ, हालांकि पिछले एक लिस्प/योजना अनुभव था। अभी मैं एसआईसीपी के उदाहरणों को देख रहा हूं और अधिक हाथ से अनुभव पाने के लिए उन्हें हास्केल में लागू करने की कोशिश कर रहा हूं। व्याख्यान में 3 बी लेखकों ने प्रतीकात्मक रूप से डेरिवेटिव की गणना करने के लिए एक समारोह प्रस्तुत किया है। यह होता है, दूसरों को, निम्नलिखित लाइनों के बीच:हास्केल

(define (deriv exp var) 
    (cond ((constant? exp var) 0) 
      ((same-var? exp var) 1) 
; ... 
इसके अलावा व्याख्यान में

, कुछ और कार्यों परिभाषित कर रहे हैं:

(define (constant? exp var) 
    (and (atom? exp) 
     (not (eq? exp var)))) 

वहाँ है एक तरह से हास्केल में एक ही बात करते हैं, यानी atomicity के लिए जाँच और कुछ अन्य समारोह के लिए प्रतीकात्मक समकक्ष? या अधिक सामान्य, Haskell में "disassembling" कार्यों के साधन क्या हैं?

उत्तर

4

आपका योजना उदाहरण वास्तव में योजना कार्यों की जांच नहीं करते। मैं हाल ही में निम्न प्रकार के मूल्यों पर हास्केल में कुछ प्रतीकात्मक भेदभाव किया:

data Exp a = Lit a 
      | Exp a :*: Exp a 
      | Exp a :+: Exp a 
      | Var String 
    deriving Eq 

के बजाय atom? या का उपयोग करते हुए भेदभाव eq? आप case (या अन्य पैटर्न मिलान) और == का उपयोग करें।

+0

क्या आपके ऍक्स्प डेटा मूल्यांकन के बारे में (जहाँ तक मैं समझता हूँ, यह अंततः एक सूची है)? –

+0

मुझे वास्तव में एक eval समारोह की जरूरत नहीं थी; मैं सी कोड उत्सर्जित करने के लिए प्रतीकात्मक भेदभाव का उपयोग कर रहा था। यदि आप एक लिखना चाहते हैं और परेशानी है, तो एक प्रश्न पोस्ट करें :-) –

1

मुझे नहीं लगता कि आप ऐसा कर सकते हैं। लिस्प homoiconic है, हास्केल नहीं है।

हालांकि, आगे Googling Liskell कर दिया है, जो (?) एक दिलचस्प संकर।

+1

हाँ, मैं हालांकि homoiconicity के बारे में। हालांकि, मुझे फ़ंक्शंस, डेटा और प्रोग्राम को उसी तरह प्रदर्शित करने की आवश्यकता नहीं है। तथ्य यह है कि बीजगणितीय डेटा प्रकार का प्रतिनिधित्व कार्यक्रम में से एक से अलग है, जो मुझे deconstructing में सीमित नहीं करता है। –

6

सबसे पहले, हालांकि SICP महान है, मैं इसके खिलाफ हास्केल सीखने के लिए सिफारिश करेंगे। (#) इस सवाल में कठिनाई में से कुछ इस वजह से उपजी है।

लिस्प/योजना में, 'function' कोड के एक टुकड़े के बारे में सोचा जाता है, और एक फ़ंक्शन की जांच करने का मतलब बस इसका कोड जांचना है। हास्केल में, 'function' का मतलब है कि इसकी गणितीय परिभाषा के करीब कुछ सेट ए से एक सेट बी के मानचित्र के रूप में है। उदाहरण के लिए, यह दो कार्यों की तुलना करने के लिए लिस्प संदर्भ में समझ में आता है: बस उनके कोड की तुलना करें। (लेकिन (x+y)^2 और x^2+2*x*y+y^2 विभिन्न कार्यों कर रहे हैं?) हास्केल में, यह है कि क्या वहाँ कार्यों आप विचार कर रहे हैं के वर्ग के लिए समानता निर्धारित करने के लिए एक रचनात्मक प्रक्रिया मौजूद है पर निर्भर करता है।

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

derive :: Expression -> Expression 

कि एक Expression disassembles पैटर्न मिलान निर्माणों का उपयोग कर लिखने (या Expression एस कैसे बनाया गया था इस पर निर्भर करता है)।


(#): कारण SICP एक बिल्कुल अलग दर्शन है, जो एक untyped प्रोग्रामिंग भाषा के उपयोग और कोड और डेटा के बीच के अंतर की कमी को प्रोत्साहित करना शामिल होता है। हालांकि "कोड = डेटा" तर्क में कुछ योग्यता है (उदाहरण के लिए वॉन न्यूमैन आर्किटेक्चर पर हम इसका उपयोग करते हैं, "सबकुछ 0 और 1 वैसे भी है"), यह जरूरी नहीं है कि समस्याओं के बारे में तर्क या मॉडलिंग का कोई अच्छा तरीका न हो।(फिलिप वाद्लेर इस बारे में अधिक के लिए के Why Calculating is Better than Scheming देखें।) आप के बजाय एक कार्यात्मक स्वाद एक Real World एक, शायद साइमन थॉम्पसन के Haskell: The Craft of Functional Programming या रिचर्ड बर्ड्स Introduction to Functional Programming using Haskell बेहतर विकल्प हैं के साथ एक हास्केल किताब पढ़ने के लिए चाहते हैं।