2013-02-13 15 views
7

यह अच्छी तरह से ज्ञात है कि Monad उदाहरणों को मोनाड कानूनों का पालन करना चाहिए। यह शायद कम ज्ञात है कि Functor उदाहरणों को फंक्टर कानूनों का पालन करना चाहिए। फिर भी, मुझे एक जीएचसी पुनर्लेखन नियम लिखने में काफी आत्मविश्वास महसूस होगा जो fmap id == id को अनुकूलित करता है।मानक हास्केल प्रकार के वर्गों को बनाए रखने की अपेक्षा रखने वाले कानून क्या हैं?

अन्य मानक वर्गों के पास कानून क्या हैं? (==) एक असली समकक्ष संबंध होना चाहिए? क्या Ord को आंशिक क्रम बनाना है? कुल आदेश? क्या हम कम से कम यह संक्रमित मान सकते हैं? विरोधी सममित?

ये अंतिम कुछ हास्केल 2010 की रिपोर्ट में निर्दिष्ट नहीं दिखते हैं और न ही मुझे विश्वास है कि वे लिखने के नियमों को पुनः लिखने के नियमों को फिर से लिखेंगे। क्या कोई सामान्य पुस्तकालय है जो करते हैं? एक उदाहरण कितना रोगजनक आत्मविश्वास से लिख सकता है?

आखिरकार, यह मानते हुए कि इस तरह के एक उदाहरण के लिए एक मानक, व्यापक संसाधन है कि प्रत्येक प्रकार के वर्ग उदाहरण को बनाए रखने के लिए एक मानक, व्यापक संसाधन हो सकता है?


उदाहरण के लिए, कितना मुसीबत मैं में

newtype Doh = Doh Bool 
instance Eq Doh where a == (Doh b) = b 

परिभाषित करने के लिए यह महज समझना कठिन है या होगा होगा संकलक का अनुकूलन गलत तरीके से कहीं भी?

+4

ध्यान दें कि बहुत से समझदार ध्वनि वाले कानून (मौजूदा कोड द्वारा स्पष्ट रूप से ग्रहण किए गए समेत) एक व्यक्ति 'ऑर्ड', 'न्यू' के लिए प्रस्तावित कर सकता है, और संबंधित वर्गों का उल्लंघन ' फ़्लोट 'और' डबल '। उदाहरण के लिए, 'डेटा.मैप' में एक महत्वपूर्ण ब्रेक लुकअप के रूप में NaN का उपयोग करके और सटीक समस्याओं का अर्थ है कि फ़्लोटिंग पॉइंट एडिशन सहयोगी नहीं है। –

+3

@ सीए.एमसीकैन जिसका मतलब है कि प्रलोभन के उदाहरण हैं कि इसे नहीं करना चाहिए! 'फ्लोट' और 'डबल' 'Eq' –

+2

@ फिलिपजेएफ के सदस्य नहीं होना चाहिए: एक तरफ, मैं सहमत हूं। लेकिन उनका 'न्यू' उदाहरण थोड़ा बेहतर है, और इसके तार्किक निष्कर्ष पर तर्क की उस पंक्ति के बाद प्रत्येक इंस्टेंस को हटाने की ओर जाता है जो फ्लोटिंग पॉइंट प्रकारों को व्यावहारिक रूप से उपयोगी बना देता है। संयोग से, [मैं कैसे टूट उनके 'Ord' उदाहरण एक पुराने पोस्ट में है का एक प्रदर्शन दे दी है।] (Http://stackoverflow.com/a/6399798/157360) –

उत्तर

5

Haskell report के लिए कानूनों का उल्लेख है:

  • functor (जैसे fmap id == id)
  • इकाई (जैसे m >>= return == m)
  • इंटीग्रल (जैसे (x ‘quot‘ y)*y + (x ‘rem‘ y) == x)
  • अंक (abs x * signum x == x)
  • शो (showsPrec d x r ++ s == showsPrec d x (r ++ s))
  • आईएक्स (उदाहरण के लिए । inRange (l,u) i == elem i (range (l,u)))

यह सब मुझे मिल सकता है। विशेष रूप से, ईक (6.3.1) के बारे में अनुभाग में कोई कानून नहीं है, न ही ऑर्ड के बारे में अगला कार्य करता है।

2

मेरे क्या कानून "चाहिए टू बी" का अपनी राय सभी मानक उदाहरणों द्वारा वैध ठहराया नहीं है, लेकिन मुझे लगता है कि

  • Eq एक तुल्यता संबंध होना चाहिए।
  • Ord कुल आदेश
  • NumfromInteger एक अंगूठी समरूपता के साथ, एक अंगूठी होना चाहिए होना चाहिए, और abs/signum स्पष्ट तरीके से व्यवहार।

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

+0

मैं मूल रूप से आपसे सहमत , हालांकि मेरे ज्ञान के बावजूद इन ज्ञानों का उल्लंघन नहीं किया जाता है। यही वह दिल है जिसे मैं जानना चाहता हूं-मैं कितना गलत हूं? एक गैर-रिफ्लेक्सिव 'ईक' उदाहरण को परिभाषित करना सिर्फ "चुनौतीपूर्ण" नहीं बल्कि वास्तव में गलत होने के लिए अनुकूलित भी है? –

+1

@tel मुझे शक है "गलत अनुकूलित" लेकिन निश्चित रूप से "बनाता है कई कार्यों के अनिश्चित परिणाम हो" –

+0

हाँ, मेरे मन में वहाँ "हार्ड" विफलता है जहां रीराइट नियम आप को खराब करता है और "सॉफ्ट" विफलता जहां प्रमुख मान्यताओं के खिलाफ जाना पूरी भाषा में और यह वास्तव में भ्रमित हो जाता है। दोनों खराब हैं, लेकिन एक भी बदतर है। शायद सबसे महत्वपूर्ण उदाहरण 'ईक डबल' होगा। –

0

ऐसा नहीं है कि Ix कानूनों को तोड़ने तुम सिर्फ कुछ के बारे में करते हैं होता हुआ करता था। इन दिनों मुझे लगता है कि उन्होंने इसे ठीक कर दिया है। यहां अधिक जानकारी: Does anyone know (or remember) how breaking class laws could cause problems in GHC?

संबंधित मुद्दे