короче

я утверждаю

как он дерайвится?

он — это кто?

Num

Num никак не дерайвится

что это единственный возможный способ задерайвить Num для произведения двух полиморфных типов

data Pair a b = Pair a b deriving Show instance (Num a, Num b) => Num (Pair a b) where Pair a b + Pair a' b' = Pair (a + a') (b + b') Pair a b - Pair a' b' = Pair (a - a') (b - b') Pair a b * Pair a' b' = Pair (a * a') (b * b') negate (Pair a b) = Pair (negate a) (negate b) abs (Pair a b) = Pair (abs a) (abs b) fromInteger x = Pair (fromInteger x) (fromInteger x) signum (Pair a b) = Pair (signum a) (signum b)

ессли я не прав, то ткните

а. он не тайпчекается

б. нет, возможно поведение как у комплексных чисел

deriving должен не только для произведений работать

а стоп, я наркоман

что не тайпчекается?

тайпчекается

но поведение как у комплексных чисел может хотеться

б. нет, возможно поведение как у комплексных чисел

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

Лишнего написано. Вычитание через сумму и негейт делается.

это во первых, во вторых

но поведение как у комплексных чисел может хотеться

если хочешь нетривиального, пиши код сам

instance Num b=> Num (Pair a b) where

Лишнего написано. Вычитание через сумму и негейт делается.

да, можно вычернуть negate

не спорю

instance Num a => Num (Pair a b) where

Лучше минус убрать.

ничуть не хуже

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

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

это естественный способ ввести бин. операции на произведении типов, если введены операции на типах

instance Num a => Num (Pair a b) where

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

нет, с бин операциями проблем нету

а вот с fromInteger есть

там неоткуда взять значение

ха, действительно, ты не напишешь instance Num a => Num (Pair a b)

а instance (Num a, Num b) => Num (Pair a b) напишешь

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

так что попробуй придумать другой тривиальный инстанс

@qnikst ^

но всё же не вижу проблемы в fromInteger x = Pair (fromInteger x) (fromInteger x)

но всё же не вижу проблемы в fromInteger x = Pair (fromInteger x) (fromInteger x)

не вижу причин, почему бы тебе не реализовать это в TH

deriveNumRecursive ''Pair

короче вопрос остался открытым:)

между прочим

для кортежей дерайвнуто Ord

лексикографически

слева направо

хотя это не единственный способо задерайвить Ord для кортежей

так что, даже наличие других тривиальных инстансов не мешает GHC пользовать deriving

короче вопрос остался открытым:)

какой вопрос?

почему это до сих пор не сделано?

какой вопрос?

почему в GHC не сделан deriving Num для произведения двух типов, или для кортежей из двух типов

ну для кортежей сделано, но в отдельном пакете

потому что никому кроме тебя это не было нужно

Ord для кортежей нужен почти каждому почти каждый день

потому что никому кроме тебя это не было нужно

так никому не было, что соответствующий пакет добавили в 2008 году

хрень не неси

Data.NumInstances.Tuple

ну вот, сделай свой тип нютайпом вокруг кортежа

и ещё расширение для newtype понадобится %)

я ж не говорю, что нельзя

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

ещё один контрдовод — Num создавался как костыль, чтобы писать одинаковый (+) для разных чисел. а если мы будем всякие штуки, не очень являющиеся числами, класть в Num, это может повлечь какие-нибудь странные ошибки.

почему в GHC не сделан deriving Num для произведения двух типов, или для кортежей из двух типов

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

или что угодно еще

>никому кроме тебя не было нужно >почти каждому нужно почти каждый день

слово "почти" убирает категоричность

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

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

откуда вы вообще взяли, что deriving должен быть только в случае единственно возможного способа это сделать

ок, скажу помягче. очень похоже на то, что никто до тебя не нашёл в себе силы внести такое поведение в Хаскелл

как бы многие deriving выбирают одну из множества возможностей

потому что least surprise

которую разрабы GHC нашли самой частоисполльзуемй

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

потому что least surprise

как по мне, комплексные числа это как раз most surprise

ну вот да

я бы ожидал одинакового дерайвинга Num для кортежей из двух элементов и для трех

и мой способ работает для любого числа элементов в кортеже

кстати, добавь заодно аналогичные инстансы для Моноида и Полугруппы. когда я пишу руками эти инстансы, они всегда получаются как (<>) по всем полям

а комплексные числа - только для кортежей из двух эл-тов

это математически ужасное решение совершенно

а для четырех кватернионы выводить или векторы?

боже мой

векторы конечно

потому что для любого N

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

ну и есть же Generic

выводи-не-хочу

в общем, главный ответ на вопрос "почему что-то не сделано?" — это "потому что никто до сих пор не сделал"

когда отправишь письмо в рассылку ghc-dev или патч в GHC, узнаешь, чему на самом деле это мешает. или нет

Ну кстати да, через генерики такое можно вывести.

я вижу варианты fromInteger x = Pair x x, Pair x 0, Pair 0 x

кстати, нашёл хороший аргумент в пользу предлагаемого мной fromInteger

For pairs, I like fromInteger n = (fromInteger n, fromInteger n). Then, for instance, 1 * (a,b) = (a,b).

из рассылки

варианты с нулями так уже не смогут

когда отправишь письмо в рассылку ghc-dev или патч в GHC, узнаешь, чему на самом деле это мешает. или нет

https://mail.haskell.org/pipermail/libraries/2012-October/018684.html

уже обсудили

и на чём порешили?

нет, с кортежами не интересно, это можно просто в библиотеку положить

речь-то про дерайвинг для произвольного произведения

ну можно обойтись кортежами и {-# LANGUAGE GeneralizedNewtypeDeriving #-}