गैर-आयातित मॉड्यूल में कार्यों के लिए हैडॉक लिंक

Question

मॉड्यूल B में मेरे पास 'A.foo' लिंक के साथ दस्तावेज़ है, जो foo मॉड्यूल A के सदस्य से लिंक है। मॉड्यूल A में मैं मॉड्यूल B आयात करता हूं। हैडॉक इसे A.html#t:foo के लिंक के रूप में प्रस्तुत करता है, अर्थात् टाइपfoo (जो मौजूद नहीं है) पर इंगित करता है foo, जो कि A.html#v:foo पर है।

• क्यों चर है कि एक लोअर केस अक्षर से शुरू के लिए t: को हेडॉक लिंक? क्या यह एक बग है? 'A.Foo' के लिए मैं देख सकता हूं कि यह एक प्रकार या कन्स्ट्रक्टर हो सकता है, इसलिए नामस्थान समस्याएं हैं। foo के लिए ऐसा लगता है कि एक चर कम से कम सबसे व्यवहार्य है।
• क्या नकली लिंक का कोई तरीका है? मैं इसे कोड नमूने में लिख रहा हूं, इसलिए मुझे इसे foo के रूप में प्रस्तुत करने की आवश्यकता है। मैंने एंकरों की कोशिश की, लेकिन वे मॉड्यूल नाम के रूप में प्रस्तुत करते हैं, और सीधे हाइपरलिंक के लिए आपके पास प्रदर्शित टेक्स्ट पर कोई नियंत्रण नहीं है।
• मैंने एक पोस्ट प्रोसेसर (t:[a-z] को v: के साथ बदलकर) माना, लेकिन इसके लिए कस्टम सेटअप एचएस की आवश्यकता होती है जो समस्याएं पैदा करती है और काफी बदसूरत है।
• मुझे एक अधिक उचित व्यवहार प्राप्त करने के लिए कोई हैडॉक कमांड लाइन झंडे नहीं मिल सका, जैसे कि foo एक चर है।
• मैं सर्कुलर आयात शुरू किए बिना AB का आयात नहीं जोड़ सकता, जो दस्तावेज़ीकरण के लिए पूरी तरह से जोड़ने के लिए बेकार है।

मैं Shake documentation में इस समस्या में भाग रहा हूं, जहां एक उदाहरण removeFilesAfter सही लिंक नहीं मिलता है।

Answer 1

यह Haddock bug #228 और नील का Haddock bug #253 था और कुछ महीनों के लिए फिक्स अपस्ट्रीम रहा है। आप जीएचसी हेड बना सकते हैं और अपने प्रलेखन का पुनर्निर्माण कर सकते हैं या 7.8 की प्रतीक्षा कर सकते हैं और फिर ऐसा कर सकते हैं।

Answer 2

मैं आंशिक रूप से पहले प्रश्न का जवाब दे सकता हूं (क्यों?); सुनिश्चित नहीं है कि यह एक बग या वांछित व्यवहार है।

जब हडॉक LexParseRn.rename में संदर्भों को हल करता है, तो यह पर्यावरण में पहचानकर्ता को देखने की कोशिश करता है (lookupGRE_RdrName के माध्यम से)। यह असफल होना चाहिए। इसके बाद ऐसा लगता है कि का मतलब क्या हो सकता है (dataTcOccs from GHC’s RnEnv का उपयोग कर)। प्रासंगिक पंक्तियां हैं:

dataTcOccs :: RdrName -> [RdrName] 
-- Return both the given name and the same name promoted to the TcClsName 
-- namespace. This is useful when we aren't sure which we are looking at. 
dataTcOccs rdr_name 
    [...] 
    | isDataOcc occ || isVarOcc occ 
    = [rdr_name, rdr_name_tc] 
    [...] 
    where 
    occ = rdrNameOcc rdr_name 
    rdr_name_tc = setRdrNameSpace rdr_name tcName 

तो यह रिटर्न नाम पहले जो कुछ भी यह पहले (संभावना एक मूल्य के लिए एक लिंक) था के रूप में व्याख्या, और फिर एक प्रकार निर्माता के रूप में व्याख्या। नियमित नाम एक प्रकार का कन्स्ट्रक्टर कैसे हो सकता है? मेरा अनुमान है कि यह जोड़ा गया था जब टाइपऑपरेटर्स को जीएचसी 7.6 में सुधार किया गया था, जो अब नाम-स्तर ऑपरेटरों के साथ नामस्थान साझा करते हैं।

फिर परिणाम पर हैडॉक मैच: यदि पहला एक प्रकार का कन्स्ट्रक्टर है, तो इसका उपयोग करें, अन्यथा दूसरे का उपयोग करें। तो या तो यह पहले एक प्रकार का कन्स्ट्रक्टर था, तो इसका उपयोग किया जाता है। या यह नहीं था, लेकिन फिर dataTcOccs द्वारा उत्पन्न संशोधित संस्करण का उपयोग किया जाना है।

ऐसा लगता है कि हैडॉक को हमेशा पहले विकल्प का उपयोग करना चाहिए, और कोड केवल एक गुमराह प्रतिलिपि है कि वास्तव में इसका समाधान कब किया जा सकता है।