..как хорошо что это интернет и здесь не понять когда люди серьёзны, а когда троллят

начинать обучение с теории категорий

ну, для начала надо учителям объяснить (а при учёте, что в пед.институты идут тее, кто никуда более не поступил....) + мировосприятие детей в 5,6,7..11 лет разное (психология, педагогика, простигосподи)

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

что верно, ибо в начальной школе у ребёнка конкретное мышление, а не абстрактное (не, есть, конечно, иднивидуумы)

По сабжу рекомендю статьи академика Арнольда и его полемику с Бурбакистами. Для затравки - байка от него, якобы реальная. Во французской начальной школе одного первоклассника спросили - сколько будет 3+2. Он ответил - не знаю, но будет столько же, сколько 2+3, потому что сложение коммутативно (С)

Добрый вечер, хотел спросить.

data T a = A a | B a deriving Eq

Class TT (T a) ...

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

например, моноид, можно на примере строк объяснить

Instance TT (T a) where eq x y = x==y

а свободный на примере списка

или, скажем, жд состав - прицепили вагоны справа, прицепили слева

Вопрос: зачем он требует ограничить a в инстанс по Eq ?

Ведь у T есть deriving Eq и он нормально сравнивается

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

Ведь у T есть deriving Eq и он нормально сравнивается

T станет Eq только если a тоже Eq

T станет Eq только если a тоже Eq

Если я пишу deriving Eq - то оно станет Eq, если может.

Но кажется я слона пропустил , в классе я описал через ::a->a->Bool, а надо было ::(T a)->(T a)->Bool

Имхо хорошо бы определиться - или дерайвинг, или инстанс

> data T a = A a | B a deriving Eq > data R = R > A R == A R <interactive>:24:1: error: • No instance for (Eq R) arising from a use of ‘==’

Дерайвинг для Eq, а инстанс для eq - функции. Но по-любому спасибо, сейчас проверю.

твоя eq = (==) или совсем по-другому можешь ее определить - хозяим барин. Хоть eq _ _ = True

Если я пишу deriving Eq - то оно станет Eq, если может.

вот именно, что если может, а может оно только если a тоже Eq

data T a = T a deriving Eq = instance Eq a => Eq (T a) where ...

ахаа

Не, извиняюсь, не заработало и я не понял.

время веселых снимков экрана)

Сделай в тайпклассе TT тип eq :: a -> a -> Bool

У тебя нету телеграма на компе?

К сожалению нет, на рабочем.

Но на последней картинке видно норм надеюсь :) сорян конечно.

К сожалению нет, на рабочем.

(web.telegram.org можно открыть, если что)

С работы нельзя.

а, понятно

Смотрите, eq тип описан

И он T a, у T есть Eq и он норм работает если просто == сравнить.

Зачем он требует ещё ограничить внутренний параметр T ?

А в инстансе eq (A x) (A y) = x == y eq (A _) (B _) = False ...

Не хочу

Честно говоря мне не оч понятно чего ты хочешь :)

С работы нельзя.

а на хаскелл писать можно?)

Ок, описал как вы написали, тоже самое: с Eq a => работает, а без - нет

Честно говоря мне не оч понятно чего ты хочешь :)

Хочу понять. Почему он требует ограничить параметр типа, который derived Eq

> у T есть Eq попробуй сделай A id == A not в репле

Страннота какая-то в чате (С) Александр Вершилов

А как ты хочешь чтобы без Eq a сравнивать их?

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

Ну смотрите, может тут и загвоздка. 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

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

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