а стоп, увидел что eitherc не возвращает, а принимает продолжение, это может быть подсказкой

а если не будет ни одного инстанса?

там точно ансейф какой-нибудь где-то

Там куда интереснее инлайнинга. Вся идея в QuantifiedConstraint'e Hold r => r, где

class c => Hold c
instance c => Hold c,

чтоб тайпчекер на зациклился.

ghc когда видит конкретный реализованный r вместо очевидного \dict -> dict дает \_ -> knownDict.

eitherC дает в качестве Hold r undefined и с помощью unsafePerformIO смотрит, вылетел ли экcепшн. Если нет - у нас на руках r, если вылетел - фоллбэкаемя на l.

Самое интересное, чтобы ghc на стороне определения не выкинул Hold r => r как тривиальный, Hold определен в .hs-boot без суперкласса и импортирован {-# SOURCE #-}, так что он еще не тривиальный.

Ансейфа конечно дофига, левый констрейнт требуется напрямую так что хоть один точно будет

что-то на эльфийском

Если интересно, вот код: https://github.com/aadaa-fgtaa/eitherconstraint

Ограничений конечно полно, так что серьезно использовать нельзя.

Во-первых, полностью полагается на оптимизатор, а там как повезет. О нет, не работает в репле!

Во-вторых, очень легко фоллбекается на левый констрейнт. На самом деле, даже синоним eitherC в майне не определить.

В-третьих, все функции, требующие either-констрейнта, нельзя определять если где-то выше был не-SOURCE импортирован Hold, иначе ghc сразу выкидывает  Hold r => r как тривиальный и сказке конец.

Так что получается четкое разделение - до не-SOURCE импорта Hold either-констрейнты вообще не разрешаются, после все немедленно разрешаются, выбирая дефолтный констрейнт если второй еще не появился.

Но писать было весело

Ничего не понял 👀
Вне классов и инстансов
type Bar a b = b
Работает как функция, и ее можно "вызвать" как Bar Bool Int и получить Int.
А в классах по-другому, получается? Что тогда там означает эта запись?

Там дело-то не в type families. Давайте раскроем везде FooType a q = q и уберем FooType вообще:

class Foo a where
    foo :: a -> q

instance Num n => Foo [x] where
    foo :: forall q . [x] -> q
    foo xs = fromIntegral $ length xs :: n

Это дает ту же самую ошибку, expected q got n, что вроде логично: n вообще не при делах, она введена в инстанс хеаде и с q никак не связанна. Вообще идея трогать в констрейнтах типопеременные которых нет в самом классе идея такая себе, о чем компилятор подсказывает требуя включить AllowAmbiguousTypes.

Еще пример: если вместо Num n => в инстансе добавить Num q => в класс все заработает:

class Foo a where
    type FooType a q
    foo :: Num q => a -> FooType a q

instance Foo [x] where
    type FooType [x] g = g
    foo xs = fromIntegral $ length xs

наверняка же уже где-то есть такое?

finallyError :: MonadError e m => m a -> m () -> m a
finallyError tryF finallyF = 
    tryIt `catchError` catchIt
  where
    tryIt = do  
        z <- tryF 
        finallyF
        pure z
    catchIt e = finallyF >> throwError e

хотя может и нет, если поведение finallyF может быть разным, и имплементацию в общем случае нельзя сделать

хм, bracket?

только для MonadError

ну или bracket, да
а он разве есть для MonadError?

не знаю, я не видел, но тоже уверен что кто-нибудь написал наверняка

у меня подозрение, что никто брекеты и файналли не писал для MonadError потому что там сильно все зависит от того, могут ли выкидывать ошибку инициализатор и финализатор (если такие слова вообще есть, но думаю понятно что это)

хотя вдруг все-таки написали

а exceptions либа котируется?

там как раз есть bracket для MonadMask