Ошибка соответствия типа из-за неиспользованного квалифицированного импорта

Вот «простой» ответ: импортируя модуль Git.Libgit2, квалифицированный или нет, вы выбираете r ~ LG.LgRepo, поэтому просто дайте GHC то, что он хочет:

listReferences :: (MonadGit LG.LgRepo m) => m [RefName]
listReferences = runConduit $ sourceReferences .| sinkList

Это может выдать предупреждение о хрупких привязках, которое вы можете устранить, включив расширение MonoLocalBinds (которое в любом случае будет включено, если вы используете GADTs или TypeFamilies):

{-# LANGUAGE MonoLocalBinds #-}

или обратитесь напрямую, отменив ограничения через экземпляр-нарушитель, что довольно грубо:

import qualified Git.Libgit2 as LG
import qualified Git.Libgit2.Types as LG

listReferences :: (LG.MonadExcept m, MonadUnliftIO m, LG.HasLgRepo m) => m [RefName]
listReferences = runConduit $ sourceReferences .| sinkList

В любом случае, следующий модуль должен ввести проверку:

{-# LANGUAGE GHC2021, MonoLocalBinds #-}

module Foo where

import Conduit
import Git.Types
import qualified Git.Libgit2 as LG

listReferences :: MonadGit LG.LgRepo m => m [RefName]
listReferences = runConduit $ sourceReferences .| sinkList

Вот более длинный ответ...

Это странное взаимодействие между глобальной областью экземпляров, зависимостями типов и проверками на неоднозначность.

В Haskell экземпляры не имеют области действия — все они находятся в одной и той же «глобальной области видимости экземпляров». Итак, если вы поработаете достаточно усердно, вы можете создать пример, в котором квалифицированный импорт модуля вводит новый экземпляр в эту глобальную область видимости, что нарушает компиляцию, даже если никакие определения из квалифицированного импорта фактически не «используются».

В этом конкретном случае класс MonadGit определен в Git.Types с функциональной зависимостью:

class ... => MonadGit r m | m -> r where

Насколько я могу судить, в пакете gitlib нет экземпляров, поэтому, когда GHC пытается ввести текст, проверьте подпись:

listReferences :: MonadGit r m => m [RefName]

поскольку импортирован только Git.Types, все, что нужно, — это класс типа. Теперь, без функциональной зависимости, эта сигнатура типа была бы неоднозначной, поскольку тип r появляется в ограничении, но не встречается ни в одном из последующих «видимых» типов. Однако из-за функциональной зависимости m -> r GHC заключает, что этот тип не является двусмысленным, поскольку - после того, как вы вызовете listReferences в конкретном m, функциональная зависимость определит правильный r.

Однако когда вы добавляете квалифицированный импорт Git.Libgit2, в область видимости попадает следующий экземпляр:

instance ... => Git.MonadGit LgRepo m where

Поскольку этот экземпляр применяется ко всем m, он тривиальным образом подчиняется функциональной зависимости — каждый выбор m подразумевает, что r ~ LgRepo. Итак, у GHC нет проблем с этим экземпляром.

К сожалению, это вызывает проблемы с проверкой неоднозначности. Когда GHC пытается определить, является ли r неоднозначным или нет, он в конечном итоге приходит к выводу, что - из-за нового экземпляра в области видимости, который через функциональную зависимость говорит, что для любого выбора m мы должны иметь r ~ LgRepo - единственный допустимым типом для r является r ~ LgRepo, поэтому он пытается объединить r и LgRepo и в конечном итоге выдает ошибку проверки типа, потому что r — это «жесткий» тип, который невозможно унифицировать таким образом.

Вы можете подумать, что это ошибка или неправильное поведение, или что GHC должен знать лучше, но это так, как есть.

Как отмечалось выше, самый простой способ решить эту проблему — специализировать использование от r до LgRepo, что является единственным r возможным, когда Git.Libgit2 является частью вашей программы.