Конфликт функциональных зависимостей Haskell

Пробовали ли вы на самом деле использовать вторую версию? Я предполагаю, что во время компиляции экземпляров вы начнете получать двусмысленность и ошибки перекрытия при вызове foo.

Самым большим камнем преткновения здесь является то, что fundeps не взаимодействуют с переменными типа так, как вы могли бы ожидать, — выбор экземпляра на самом деле не ищет решения, он просто слепо сопоставляется, пытаясь унифицировать. В частности, когда вы пишете Foo a a, a является совершенно произвольным и, таким образом, может унифицироваться с таким типом, как b -> b. Когда второй параметр имеет форму b -> b, он соответствует обоим экземплярам, ​​но фундэпсы говорят, что в одном случае первый параметр должен быть b -> b, а в другом — b. Отсюда и конфликт.

Поскольку это явно удивляет людей, вот что произойдет, если вы попытаетесь использовать вторую версию:

• bar = foo () () приводит к:

  Couldn't match type `Bool' with `()'
    When using functional dependencies to combine
      Foo Bool a,
  

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

• bar = foo True () приводит к:

  Couldn't match type `()' with `Bool'
    When using functional dependencies to combine
      Foo a a,
  

  ...потому что Fundep сообщает через первый экземпляр, что любой тип в качестве второго параметра однозначно определяет тот же тип для первого. Таким образом, первый параметр должен быть ().

• bar = foo () True приводит к ошибкам из-за обоих экземпляров, так как на этот раз они соглашаются, что первый параметр должен быть Bool.

• bar = foo True True приводит к:

  Overlapping instances for Foo Bool Bool
    arising from a use of `foo'
  

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

Довольно весело, да?

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

Правка. Сначала я предположил, что работает второй пример. Это было сделано на ghc 7.0.4, но это не имело смысла, и эта проблема, похоже, была решена в более новых версиях.