eitherDecodeStrict . encodeUtf8

import Data.Aeson (ToJSON, FromJSON, decodeStrict, eitherDecodeStrict) import Data.Text.Encoding (encodeUtf8)

ну еще ByteString -> Text

combot.org/c/-1001043143583

мне сейчас нужен только Semigroup

Можно просто туплом, воспользовавшись инстансом instance (Semigroup a, Semigroup b) => Semigroup (a, b)`

Ну для Either инстанс Semigroup уже занят

значит тебе всё равно что-то своё делать

left x = (x, mempty) right x = (mempty, x) "конструкторы"

Интересен юзкейз не-Bounded полурешётки

чем интересен?

Тем, что совершенно всё, что я встречал на практике всегда имело какой-то баунд. Типа там пустого сета/мэпа, минимального/максимальнрго элемента и т.п

Интересен юзкейз не-Bounded полурешётки

или «юзкейс» — это практическое применение?

нууу да

я применяю полурешётки в https://github.com/ff-notes/ff

Некий новый процесс должен стартовать с пустым состоянием

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

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

Ну обычно-таки bound ом в полурешётке называют нейтральный элемент.

Ну тогда твоим общим CRDT будет какая-то разновидность Set. Но ок, от каждого элемента этого Set уже границ не требуется, логично

я ненавижу стек

без стека все работает

Проблема значительной части материалов по продвинутым фишкам Haskell в том, что она пишется математиками и для математиков. И вместо того, чтобы объяснять и показывать использование, в этих материалах предмет вводится аксиоматически, а потом обсуждаются его свойства. Ну вроде такого: "Такую-то вещь мы называем Type Family и записываем вот так: blah-blah И теперь мы получаем возможность записывать на уровне типов то-то и то-то, при этом мы должны следить, чтобы типы были такими-то и такими-то, потому что механизм вывода типов имеет недостатки" Это ничуть не лучше, чем вводить понятие монады через пресловутый моноид в категории эндофункторов, а потом обсуждать, какие же у монады должны быть законы. Меня совершенно не интересует математическая постановка проблемы и следствия из аксиоматически заданных конструкций. Я хочу видеть сначала практическую задачу, которую пытаются решить другим способом, и это получается не очень. Потом я хочу видеть объяснение, почему подфича Х-1 из набора большой фичи Х здесь может помочь лучше, чем что-то другое. Потом я хочу видеть конкретно этот пример, решенный с помощью подфичи Х-1, а не изучать аксиоматически введенный набор Х-1, Х-2, Х-3, потому что уже сказано, что Х-2 и Х-3 к задаче не имеют отношения. И уж тем более мне не интересно, что там у Х-1, Х-2 или Х-3 за математические следствия, распространяющиеся на дизайн языка. Конечно, математикам такая форма подачи привычна и удобна. Даем вводную и разворачиваем следствие. Но это не то, как пишется реальный софт и решаются реальные задачи. И это не то, как мыслят большинство программистов.

Проблема значительной части материалов по продвинутым фишкам Haskell в том, что она пишется математиками и для математиков. И вместо того, чтобы объяснять и показывать использование, в этих материалах предмет вводится аксиоматически, а потом обсуждаются его свойства. Ну вроде такого: "Такую-то вещь мы называем Type Family и записываем вот так: blah-blah И теперь мы получаем возможность записывать на уровне типов то-то и то-то, при этом мы должны следить, чтобы типы были такими-то и такими-то, потому что механизм вывода типов имеет недостатки" Это ничуть не лучше, чем вводить понятие монады через пресловутый моноид в категории эндофункторов, а потом обсуждать, какие же у монады должны быть законы. Меня совершенно не интересует математическая постановка проблемы и следствия из аксиоматически заданных конструкций. Я хочу видеть сначала практическую задачу, которую пытаются решить другим способом, и это получается не очень. Потом я хочу видеть объяснение, почему подфича Х-1 из набора большой фичи Х здесь может помочь лучше, чем что-то другое. Потом я хочу видеть конкретно этот пример, решенный с помощью подфичи Х-1, а не изучать аксиоматически введенный набор Х-1, Х-2, Х-3, потому что уже сказано, что Х-2 и Х-3 к задаче не имеют отношения. И уж тем более мне не интересно, что там у Х-1, Х-2 или Х-3 за математические следствия, распространяющиеся на дизайн языка. Конечно, математикам такая форма подачи привычна и удобна. Даем вводную и разворачиваем следствие. Но это не то, как пишется реальный софт и решаются реальные задачи. И это не то, как мыслят большинство программистов.

Зато такой подход и правда помогает авойдить саксесс эт эни кост.

Проблема значительной части материалов по продвинутым фишкам Haskell в том, что она пишется математиками и для математиков. И вместо того, чтобы объяснять и показывать использование, в этих материалах предмет вводится аксиоматически, а потом обсуждаются его свойства. Ну вроде такого: "Такую-то вещь мы называем Type Family и записываем вот так: blah-blah И теперь мы получаем возможность записывать на уровне типов то-то и то-то, при этом мы должны следить, чтобы типы были такими-то и такими-то, потому что механизм вывода типов имеет недостатки" Это ничуть не лучше, чем вводить понятие монады через пресловутый моноид в категории эндофункторов, а потом обсуждать, какие же у монады должны быть законы. Меня совершенно не интересует математическая постановка проблемы и следствия из аксиоматически заданных конструкций. Я хочу видеть сначала практическую задачу, которую пытаются решить другим способом, и это получается не очень. Потом я хочу видеть объяснение, почему подфича Х-1 из набора большой фичи Х здесь может помочь лучше, чем что-то другое. Потом я хочу видеть конкретно этот пример, решенный с помощью подфичи Х-1, а не изучать аксиоматически введенный набор Х-1, Х-2, Х-3, потому что уже сказано, что Х-2 и Х-3 к задаче не имеют отношения. И уж тем более мне не интересно, что там у Х-1, Х-2 или Х-3 за математические следствия, распространяющиеся на дизайн языка. Конечно, математикам такая форма подачи привычна и удобна. Даем вводную и разворачиваем следствие. Но это не то, как пишется реальный софт и решаются реальные задачи. И это не то, как мыслят большинство программистов.

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