Внезапно есть типы которые нельзя сравнить

Ну смотрите, может тут и загвоздка. r = (A 1) == (A 2) работает же.

Только за счёт deriving

работает, потому что и у T, и у Integer есть инстанс Eq

притом инстанс Eq (T a) – задерайвленный! – требует инстанс Eq a

что довольно логично

мне кажется, я понял затруднение ТС :) твой тип - однопараметрический, и нет НИКАКИХ ограничений на то, что сувать туда. И никакой дерайвинг еку или орд не ограничивает тебя - ты можешь засунуть все равно то что не екушится и не ордится. Вот для этого и ограничения в инстансах даже при дерайвинге.

мне кажется, я понял затруднение ТС :) твой тип - однопараметрический, и нет НИКАКИХ ограничений на то, что сувать туда. И никакой дерайвинг еку или орд не ограничивает тебя - ты можешь засунуть все равно то что не екушится и не ордится. Вот для этого и ограничения в инстансах даже при дерайвинге.

Кажется у меня блеснуло понимание.

То есть в одном месте кода ты можешь засунуть туда числа - и сравнивать свой тип. А в другом месте того же кода - засунуть в тот же тип функции - и ничего не поломается, даже будет работать (инстансы функтора и т.п.)

но екушиться уже не будет

Те он смотрит на конечный тип и для T Integer решает что == это ок из deriving

Но в instance он не смотрит на то, что потом это тоже T Integer?

Ты можешь засунуть T (T (T Int)) и это волшебнорекурсивно отъекушится

Но только для == , а не для моего класса

Такие и были подозрения, но какой-то осадочек пока не понятный :)

потому что судя по словам у тебя каша в голове и терминах

На deriving надейся, а сам не плошай. Пойду попробую понять когда deriving Eq не будет срабатывать.

потому что судя по словам у тебя каша в голове и терминах

Есть такое наверное, неизбежно :)

Хотя в целом в данной ситуации вроде все понятно, но просто не понятно как оно работает.

Я думал deriving гарантирует Eq

ну ты вроде можешь еще StandaloneDeriving

читай выше про НИКАКИХ )

deriving instance Eq a => Eq (T a)

В том плане что сам написать инстанс Eq ? Это ясно вроде.

Понятно что не понятно как срабатывает deriving, вроде без него картина относительно светлая.

можешь считать что дерайвинг работает как макрос, пишущий лобовые инстансы как если бы ты писал их сам

deriving Eq, это значит делается инстанс Eq a

И тут, получается, тоже не хватает ограничителя.

делается, если есть такая возможность

не еку а а еку твоего типа

не еку а а еку твоего типа

Ага

а еку а не делается а предполагается

для любого a сделать Eq (T a) он не сможет

мог бы, конечно - (==) _ _ = False, например, но здравый смысл подсказывает так не делать

Понятно что не понятно как срабатывает deriving, вроде без него картина относительно светлая.

можешь взять да посмотреть, какие инстансы получаются при deriving Eq я взял твой код и скомпилил его с флагом -ddump-deriv, вот что получилось [yom@shiny tmp]$ ghc -ddump-deriv eq.hs [1 of 1] Compiling Main ( eq.hs, eq.o ) ==================== Derived instances ==================== Derived instances: instance GHC.Classes.Eq a_a1u2 => GHC.Classes.Eq (Main.T a_a1u2) where (GHC.Classes.==) (Main.A a1_a1u3) (Main.A b1_a1u4) = ((a1_a1u3 GHC.Classes.== b1_a1u4)) (GHC.Classes.==) (Main.B a1_a1u5) (Main.B b1_a1u6) = ((a1_a1u5 GHC.Classes.== b1_a1u6)) (GHC.Classes.==) _ _ = GHC.Types.False (GHC.Classes./=) a_a1u7 b_a1u8 = GHC.Classes.not ((GHC.Classes.==) a_a1u7 b_a1u8) а если убрать мусор, то вот так выглядит instance Eq a => Eq (T a) where (==) (A a) (A b) = (a == b) (==) (B a) (B b) = (a == b) (==) _ _ = False (/=) a b = not ((==) a b) заметь Eq a слева от =>

я чет запутался с функторами в теории категорий

они же получается отличаются от того что есть в хаскеле

я чет запутался с функторами в теории категорий

функторы это морфизмы между категориями

функторы это морфизмы между категориями

с законом

ну это понятно

Functor f => (a -> b) -> f a -> f b

а и б это категории

что тогда f?

с законом

в Хаскеле - с законом, в ТК - с двумя 😊

гм.. а какой второй?

что тогда f?

отображение между типами

f :: * -> *

в Хаскеле - с законом, в ТК - с двумя 😊

ну из-за паратримитичности не надо 2 проверять)

Кметт когда-то написал https://www.schoolofhaskell.com/user/edwardk/snippets/fmap

гм.. а какой второй?

фигасе, приплыли. композиция мапов равна мапу композиции. Да, на эту статью Кметта я и намекаю )

получается, что это f в теории категорий не нужно

в чем отличие ExistentialQuantification от RankType?

ёлыпалы, точно

получается, что это f в теории категорий не нужно

как это?

вроде как ExisentialQuanticitation выражается через RankNTypes

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

(fmap f) дает морфизм. f параметризует его

в хаскеле эндофункторы

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

функтор отображает категорию в категорию, у категории есть объекты и морфизмы, f отображает объекты в объекты, fmap отображает морфизмы в морфизмы

в хаскеле эндофункторы

и эндоморфизмы)

например, Maybe отображает Int в Maybe Int, а fmap отображает even :: Int -> Bool в Maybe Int -> Maybe Bool

я, возможно, неправильные термины использую, в обычной жизни я на плюсах пишу :D

Int -> Maybe Int?

это какая-то монада получается

> :t fmap @Maybe @Int even fmap @Maybe @Int even :: Maybe Int -> Maybe Bool

Int -> Maybe Int?

Maybe - можно рассматривать как преобразование типа

функтор это просто мап из одной категории в другую сохраняя структуру

ну как бы это переход в другую подкатегорию

тогда многие функции в хаскеле - функторы?

функтор это просто мап из одной категории в другую сохраняя структуру

Да, но как уже напоминали, в хачкеле только эндофункторы. Поэтому он сопоставляет Hask у Hask

так стоп

Каждому объекту (типу) он сопоставляет другой объект (тип) с помощью конструктора типов * -> *

функции функторы в вышеупомянутых плюсах )

тогда f - категория?

Functor f => (a -> b) -> f a -> f b

здесь

f a - категория, не?

тогда f - категория?

Нет категория одна - Hask

ааа

здесь

f - это отображение из объектов одной категории в объекты другой

но зачем нам f