हैडॉक मॉड्यूल फ़ील्ड पोर्टेबिलिटी, स्थिरता और रखरखाव का उपयोग कैसे किया जाता है?

Question

हेडॉक-उत्पन्न मॉड्यूल प्रलेखन के बहुत सारे में (जैसे Prelude), ऊपरी दाएं भाग में एक छोटे से बॉक्स देखा जा सकता है, पोर्टेबिलिटी, स्थिरता और मेंटेनर जानकारी युक्त:

स्रोत कोड देख से इस तरह के मॉड्यूल और प्रयोग करने के लिए, मैं इस बात की पुष्टि है कि यह जानकारी मॉड्यूल के वर्णन में निम्न की तरह लाइनों से उत्पन्न होता है:

:

-- Maintainer : libraries@haskell.org 
-- Stability : stable 
-- Portability : portable 

इस बारे में कई अजीब बातें हैं

• क्षेत्रों केवल इस क्रम में काम करने के लिए लगता है - किसी भी फ़ील्ड आदेश बस मॉड्यूल वर्णन खुद के हिस्से के रूप का इलाज कर रहे हैं से बाहर डाल दिया। यह इस तथ्य के बावजूद है कि स्रोत फ़ाइल में ऑर्डर उत्पन्न जेनरेट किए गए दस्तावेज़ में क्रमशः है!

• मैं इन क्षेत्रों के किसी भी आधिकारिक दस्तावेज को खोजने में असमर्थ रहा हूं। Cabal package property नाम stability है, उदाहरण के मान जो समकक्ष हैडॉक फ़ील्ड्स में देखे गए मानों से मेल खाते हैं, लेकिन उससे परे, मुझे कुछ भी नहीं मिला है।

तो: कैसे इन उपयोग के लिए लक्षित क्षेत्रों हैं, और वे कहीं भी प्रलेखित रहे हैं?

विशेष रूप से, मैं जानना चाहते हैं:

• Portability और Stability के लिए सामान्य रूप से प्रयुक्त मूल्यों की पूरी सूची। This HaskellWiki page में एक सूची है, लेकिन मैं यह जानना चाहता हूं कि यह सूची कहां से उत्पन्न हुई है।

• यह तय करने के लिए मानदंड कि मॉड्यूल पोर्टेबल या गैर-पोर्टेबल है या नहीं। विशेष रूप से, पैकेज मैं acme-strfry के लिए इन प्रश्नों के उत्तर देना चाहता हूं, एक एफएफआई strfry पर बाध्यकारी है, जो केवल ग्लिब में उपलब्ध एक फ़ंक्शन है। पैकेज गैर-पोर्टेबल है, क्योंकि यह केवल ग्लिब सिस्टम, या पोर्टेबल पर काम करता है, क्योंकि यह किसी भी हास्केल भाषा एक्सटेंशन का उपयोग नहीं करता है? आम उपयोग बाद वाले को इंगित करता है।

• स्रोत फ़ाइल में फ़ील्ड का एक विशिष्ट क्रम क्यों आवश्यक है, और यह जेनरेट किए गए दस्तावेज़ों में ऑर्डरिंग के विपरीत क्यों है।

Answer 1

ओह, मैंने सोचा था कि वे फ़ील्ड कैबल पैकेज विवरण से थे। वे हैडॉक के दस्तावेज़ों पर बिल्कुल दस्तावेज नहीं लगते हैं। मैं इस, जो वास्तव में अपने प्रश्न का उत्तर नहीं करता, लेकिन मिल गया है:

http://trac.haskell.org/haddock/ticket/71

तो अगर यह वैसे भी freeform है, यही कारण है कि अभी लिख नहीं "गैर पोर्टेबल (glibc पर निर्भर करता है)?" मैंने "पोर्टेबल (ghc पर निर्भर करता है)" देखा है, जो विषम है। मुझे आश्चर्य है कि फू को हास्केल 2010 में जोड़ा जाने के बाद गैर-हास्केल 9 8 एक्सटेंशन फू के कारण गैर-पोर्टेबल मॉड्यूल के साथ क्या होता है।

ध्यान दें कि आपके द्वारा लिंक किए गए कैबल डॉक्यूमेनेशन में भी स्थिरता निःशुल्क है। बेशक, यहां तक ​​कि यदि हैडॉक या कैबल को परिभाषित करना था कि स्वीकार्य मूल्य क्या हैं, तो यह अभी भी बनाए रखने वाले को बनाए रखने के लिए होगा।

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

पीएस: स्ट्रैफी हास्केल समुदाय में एक अमूल्य योगदान है, लेकिन यह शुद्ध और पोर्टेबल होना चाहिए, आपको नहीं लगता?

Answer 2

आह हाँ, हैडॉक की अधिक अस्पष्ट और क्रूर सुविधाओं में से एक।

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

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