Связная ссылка на функции в не импортируемых модулях

Question

В модуле B У меня есть документация со ссылкой 'A.foo', ссылающаяся на foo член модуля A. В модуле A я импортирую модуль B. Пикша делает это ссылкой на A.html#t:foo, а именно на типfoo (которого нет) не функция foo, которая находится на A.html#v:foo.

• Почему Haddock ссылается на t: для переменных, начинающихся с буквы нижнего регистра? Это ошибка? Для 'A.Foo' Я вижу, что это может быть тип или конструктор, поэтому возникают проблемы с именами. Для foo кажется, что переменная, по крайней мере, наиболее правдоподобна.
• Есть ли способ подделать ссылку? Я пишу это в образцах кода, поэтому мне нужно, чтобы он отображался как foo. Я пробовал привязки, но они отображались как имя модуля, а для прямых гиперссылок у вас нет контроля над отображаемым текстом.
• Я рассмотрел почтовый процессор (заменив t:[a-z] на v:), но для этого требуется специальная Setup.hs, которая вызывает проблемы и довольно уродлива.
• Я не смог найти флаги командной строки Haddock, чтобы получить более разумное поведение, например, указать, что foo является переменной.
• Невозможно добавить импорт: A - B без ввода круговых оборотов, что подливает его добавление исключительно для документации.

Я столкнулся с этой проблемой в Shake documentation, где в качестве примера removeFilesAfter не получил правильную ссылку.

Answer 1

Это был Haddock bug #228 и № Haddock bug #253 от Neil, и исправление было в течение нескольких месяцев. Вы можете создать GHC HEAD и перестроить свою документацию или подождать 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 

поэтому возвращает имя первого истолковано как бы то ни было раньше (вероятно, ссылка на значение), а затем интерпретируется как конструктор типа. Как регулярное имя может быть конструктором типа? Я предполагаю, что это было добавлено, когда TypeOperators были преобразованы в GHC 7.6, которые теперь разделяют пространство имен с операторами уровня ценности.

Тогда матчи пикши на результат: если первый из них является конструктором типа, используйте его, в противном случае используйте второй. Так или раньше это был конструктор типа, тогда он используется. Или это не так, но тогда должна использоваться модифицированная версия, созданная dataTcOccs.

Мне кажется, что пикша должна всегда использовать первый вариант здесь, а код - всего лишь вводящая в заблуждение копия того, как несколько результатов используются, когда они действительно могут быть разрешены.