Например для списка это будет либо [] либо def:def:def:def...

В зависимости от того, какой конструктор стоит первый там у списка, не помню

> вне теории множеств класс это баззворд, эпитет

Stop it please. В чем смысл вашей олимпиады?

А в теории множеств класс это более широкое понятие чем множество

твое утверждение "в любом множестве s есть дефолтный элемент a ∈ s" ну во-первых это неверно для пустого множества

Я не утверждал такого. Давай так - пара {S, d} является множеством с дефолтным элементом если d принадлежит S. По анологии с моноидом, но без операции

ну а в теории множеств он либо неформальный (т.е. баззворд, эпитет), либо "семейство, которое не может быть элементом других семейств" (aka множество_1, Set_1 в Agda)

так что не могу проследовать за цепочкой рассуждений

Я не утверждал такого. Давай так - пара {S, d} является множеством с дефолтным элементом если d принадлежит S. По анологии с моноидом, но без операции

OK. Как d выбирать будешь?

Никак. Это абстракция

Ну раз никак не выбирать, значит его и не будет

Эм, в классической математике не требуется конструктивности

Все равно что в определении моноида сказать "как операцию выбирать будешь"?

Не обязательно выбирать, чтобы доказать существование

Я не утверждал такого. Давай так - пара {S, d} является множеством с дефолтным элементом если d принадлежит S. По анологии с моноидом, но без операции

Непротиворечиво

Все равно что в определении моноида сказать "как операцию выбирать будешь"?

ок, я понял, зависимости нет. Тогда Default не может быть классом в Haskell

потому что Default выбирает уникально тёрм по типу

ок, я понял, зависимости нет. Тогда Default не может быть классом в Haskell

Почему?

потому что классы выбирают тёрм по типу

ты говоришь классу тип, он даёт тебе тёрм

Monoid (Sum Integer) дает тебе { (<>) = (+), mempty = 0 }

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

Хорошо Default (Sum Integer) даст { def = 0 }

не очень понятно, в чем смысл этого Default вне контекста моноида

а Default (Product Integer) даст { def = 1 }

типа дефолтный для чего это вообще

тогда это mempty просто, и без <> ты бы правильное значение не выбрал

о чём и речь

не очень понятно, в чем смысл этого Default вне контекста моноида

В том что иногда операция не нужна

тогда и Sum не будет

В конфиге например

тогда и Sum не будет

вот-вот, Sum-то вообще в честь операции и назван

Хорошо Default (Sum Integer) даст { def = 0 }

тут ты выбрал дефолтный ПО ОПЕРАЦИИ, а потом говоришь, что операция не нужна, тут mutual взаимосвязь, убрав один не будет и другого

тут ты выбрал дефолтный ПО ОПЕРАЦИИ, а потом говоришь, что операция не нужна, тут mutual взаимосвязь, убрав один не будет и другого

Конечно, для моноида это очевидный выбор

в конфиге у тебя будет своя операция (иначе зачем там дефолт), вот для нее и будет моноид с твоим дефолтным конфигом

В конфиге например

В конфиге операция - это программа, которую ты конфигурируешь. Она Config -> IO (), условно говоря.

Поэтому дефолты там выбираются по поведению этой программы

Если у тебя какой-то язык конфигов, который от программы не зависит (например YAML), то не может быть там дефолтов

Предположим что операция не ассоциативна

Я вообще не говорю про ассоциативные операции или моноиды, потому что mempty и def явно разные вещи

Это у тебя было утверждение, что они одно и то же, и что надо сделать Default m => Monoid m

тогда это будет структура { M: Set , f: M -> M -> M , e: M, , p: (forall x in M) f x e = f e x = x }

не знаю, есть ли у нее имя, но структура есть (имя не первично)

Это у тебя было утверждение, что они одно и то же, и что надо сделать Default m => Monoid m

Они могут быть одним и тем же. И дефолтная реализация mempty = def

могут быть, но "могут быть" - явно слабое условие для того, чтобы делать наследование

Да ладно. Для каждого моноида сделать инстанс Default

А если нет инстанса моноида, то какой операцией выбирать значение def?

То же самое как Monad наследует Applicative

А если нет инстанса моноида, то какой операцией выбирать значение def?

Свободно

Уже проходили этот вариант

instance Default Integer where def = 42 change my mind

да вот я сделал data X = A | B | C instance Default X where def = C instance Monoid X where mempety = A (<>) A x = x (<>) x A = x (<>) B C = A (<>) C B = A (<>) B B = C (<>) C C = B

какая тут связь дефолта с моноидом вообще

instance Default Integer where def = 42 change my mind

А почему бы не определить для Integer моноид со сложением по модулю 2 например?

потому что 42 мне больше нравится ты же сказал произвольно

я похоже не на тот вопрос ответил

Monoid для Integer вообще определять не нужно, потому что их существует >1

Ну я могу и моноид для инта написать например mempty = 0 mconcat a b = 0 потому что мне нравится. И дальше что?

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

Ну я могу и моноид для инта написать например mempty = 0 mconcat a b = 0 потому что мне нравится. И дальше что?

ты не моноид написал

Ну я могу и моноид для инта написать например mempty = 0 mconcat a b = 0 потому что мне нравится. И дальше что?

так ты и ответь, ты же сам за произвольность

вот выше я описал тип для конфига

ты не моноид написал

Почему?

и дефолтное значение хочу C

во-первых потому что mconcat :: [m] -> m

но нейтральным элементом это не будет

ERROR: S client not available

Ну я могу и моноид для инта написать например mempty = 0 mconcat a b = 0 потому что мне нравится. И дальше что?

А соблюдение законов?

во-вторых если ты имел в виду mappend a b = b, то это не удовлетворяет свойству mappend a mempty = a

так что это не моноид

во-вторых если ты имел в виду mappend a b = b, то это не удовлетворяет свойству mappend a mempty = a

Да, имел

Да, чёт я загнался

в-третих если бы даже удовлетворяло, я уже сказал, что есть возможных инстансов >1, то их не надо определять вообще

для Integer возможны как минимум (+) и (*), поэтому нет у него Monoid никакого

а кто определит - тот дурак

в-третих если бы даже удовлетворяло, я уже сказал, что есть возможных инстансов >1, то их не надо определять вообще

Только в хаскеле этому правилу не следуют

зря

для Integer возможны как минимум (+) и (*), поэтому нет у него Monoid никакого

Что за + и -?

Я думаю для любого множества с числом элементов больше 2 число возможных моноидов >1

(+) и (*) - я опечатался

Не, второй для ненулевых.

Я думаю для любого множества с числом элементов больше 2 число возможных моноидов >1

поэтому Monoid это вообще неудачный класс

лучше бы он структурой был data Monoid m = Monoid { (<>) :: m -> m -> m; mempty :: m }

Но для классов всегда остается вариант выбирать его ньютайпом по крайней мере

Тут вопрос полезности. Некоторые моноиды полезны в программистской практике

Т.е. если инстансов >1, то сделать по ньютайпу

как сделано Sum и Product

Т.е. если инстансов >1, то сделать по ньютайпу

Или нет, как с ZipList

лучше бы он структурой был data Monoid m = Monoid { (<>) :: m -> m -> m; mempty :: m }

+

Вот неявные инстансы классов -- это же компромисс. Очумеешь их все явно передавать.

Не, второй для ненулевых.

Поясни?

Вроде всё норм там с 0 и умножением

Или нет, как с ZipList

я не поддерживаю каждое решение стандарта Haskell, в том числе наличие инстансов от Monoid до Monad для []

или там Functor/Foldable/Traversable для (,)

у них же естественный смысл есть

Для этого можно отдельные ньютайпы определить newtype Second a b = Second (a, b) deriving Functor newtype Swap a b = Swap (b, a) deriving Functor

Вроде всё норм там с 0 и умножением

Да, похоже, что норм. Я не прав про (*).

а у (,) нет смысла естественного, это пара просто

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