но полурешеток вроде нету

раздельные есть в lattices

простую я сам изобретал

фигово, что нельзя простым образом добавить в base

т.к. сложность бешено быстро растет

сложность программирования

Что именно? Более вменяемые классы для чисел?

ага

ну вообще всю эту алгебру честную бы засунуть

у нас только vector-space и numeric-prelude как эксперименты

Ну хотя бы выдрать аддитивную группу и кольцо из Num

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

Ну хотя бы аддитивную группу

и fromInteger отделить как синтаксический костыль

и в transition period сделать Num зависяшим от себя

да-да-да

реально бесит

Всех — слишком много. Выходит по классу на операцию :( С одной стороны так и надо, с другой — морочно

ну т.е. будет промежуточный вариант, хочешь - используешь, не хочешь берёшь Int/Double где все есть

у нас только vector-space и numeric-prelude как эксперименты

есть еще пакет algebra

о кметтопакет

Вопрос, а почему я в рамках ду нотации часто вижу pure вместо return? Экономия на символах?

некоторые считают такой подход более принципиальнм

return - это реликт со времен, когда Monad и Applicative не были в одной иерархии

у меня получилась такая иерархия class CFoo a where foo :: TFoo class CFoo a => CFooBar a where foobar :: TFooBar class CFoo a => CFooBaz a where foobaz :: TFooBaz fooViaBar :: TFooBar -> TFoo fooViaBaz :: TFooBaz -> TFoo data X instance CFoo X where foo = fooViaBar instance CFooBar X where foobar = (realImplementation) data Y instance CFoo Y where foo = fooViaBaz instance CFooBaz Y where foobaz = (realImplementation) чувствую, что-то не так, но не могу понять как правильно. что посоветуете?

некоторые считают что return путает людей

и.к. это не ретурн из императивных яп

"pure - для аппликативных выражений, return - для do-блоков" :)

у меня получилась такая иерархия class CFoo a where foo :: TFoo class CFoo a => CFooBar a where foobar :: TFooBar class CFoo a => CFooBaz a where foobaz :: TFooBaz fooViaBar :: TFooBar -> TFoo fooViaBaz :: TFooBaz -> TFoo data X instance CFoo X where foo = fooViaBar instance CFooBar X where foobar = (realImplementation) data Y instance CFoo Y where foo = fooViaBaz instance CFooBaz Y where foobaz = (realImplementation) чувствую, что-то не так, но не могу понять как правильно. что посоветуете?

в клиентском коде как ограничения используются все 3 класса — когда реализация не важна и когда важно, чтобы реализация была в одном из "стилей"

у меня получилась такая иерархия class CFoo a where foo :: TFoo class CFoo a => CFooBar a where foobar :: TFooBar class CFoo a => CFooBaz a where foobaz :: TFooBaz fooViaBar :: TFooBar -> TFoo fooViaBaz :: TFooBaz -> TFoo data X instance CFoo X where foo = fooViaBar instance CFooBar X where foobar = (realImplementation) data Y instance CFoo Y where foo = fooViaBaz instance CFooBaz Y where foobaz = (realImplementation) чувствую, что-то не так, но не могу понять как правильно. что посоветуете?

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

Нужны классы-синонимы. Тогда развесистые иерархии не страшны и можно дробить тайпкласссы. Что-то вроде class Functor a => Applicative a = Pointed a, Apply a class Pointed ... class Apply ... Можно объявлять инстансы по отдельности, а можно вместе. instance Applicative даёт инстансы Pointed и Apply, инстансы Pointed и Apply дают Applicative

у меня получилась такая иерархия class CFoo a where foo :: TFoo class CFoo a => CFooBar a where foobar :: TFooBar class CFoo a => CFooBaz a where foobaz :: TFooBaz fooViaBar :: TFooBar -> TFoo fooViaBaz :: TFooBaz -> TFoo data X instance CFoo X where foo = fooViaBar instance CFooBar X where foobar = (realImplementation) data Y instance CFoo Y where foo = fooViaBaz instance CFooBaz Y where foobaz = (realImplementation) чувствую, что-то не так, но не могу понять как правильно. что посоветуете?

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

Гранулярная иерархия становится нестрашной

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

Ассоциированный тип в Foo и диспетчеризация по нему?

Ассоциированный тип в Foo и диспетчеризация по нему?

да, об этом и думаю

Нужны классы-синонимы. Тогда развесистые иерархии не страшны и можно дробить тайпкласссы. Что-то вроде class Functor a => Applicative a = Pointed a, Apply a class Pointed ... class Apply ... Можно объявлять инстансы по отдельности, а можно вместе. instance Applicative даёт инстансы Pointed и Apply, инстансы Pointed и Apply дают Applicative

не понял синтаксис

type Applicative a = (Functor a, Pointed a, Apply a)?

Да, плюс сахар для объявления инстансов

instance Applicative f where pure = ... (<*>) = ... рассахаривается в instance Pointed f where pure = ... instance Apply f where (<*>) = ...

Да, плюс сахар для объявления инстансов

а, это про алгебру, не про мой вопрос?

Это про страдания с классами.

Тредов нет

всё вперемешку

а ещё можно Old.Applicative

+ deriving via

Просто в этом случае мы автоматически получаем инстансы для Pointed и Apply. Для всех типов, где есть Applicative

но с дерайвинг в другую сторону не будет

А тут в обе стороны

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

если менять язык, то можно создавать автоматические классы из функций. правда, все сразу начнут создавать мультиметоды — беззаконные классы

classy (+) :: a -> a -> a instance (+) :: Int -> Int -> Int where ....

Автоматические классы?

Автоматические классы?

полуявные

Это уже что-то нездоровое, кмк

Мои идеи дальше дробления тайпклассов не идут

В смысле уменьшения боли от дробления

т.е. если я в либе ввожу Pointed и Apply то я могу их автоматом получить если у меня есть type Applicative = (Pointed, Apply) ?

и если я что-то ввожу в своей либе, то если у меня будут Pointed и Apply то я получу Applicative бесплатно?

Идея в том, что в base поменяли определение Applicative, и все, кто объявил инстанс Applicative получает бесплатно инстансы Pointed и Apply. В другой стороны их можно объявлять по отдельности и необярательно оба

В общем да

f :: HasField "a" r0 r1 String Int => HasField "b" r1 r2 Int String => Record r0 -> Record r2 вот имею такой код, хочу написать хелпер для композиции HasField, но для этого придется скрыть из внешнего скоупа r1 и добавить в скоуп внутри семейства, это реально?

Что-то тут не так. Почему имена полей разные, а типы соответствуют? Так надо?

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

Что-то тут не так. Почему имена полей разные, а типы соответствуют? Так надо?

ну мы сначала требуем линзу для поля "a" из String в Int, на выходе получаем r1 потом требуем для r1 линзу для поля "b" из Int в String, на выходе r2

почему в Int преобразуем поле "a", а из Int уже "b"?

В любом случае, я думаю, что должно быть что-то вроде f :: forall r1. (HasField name r r1 ..., HasField name r1 r2 ...) => Record r -> Record r2С указанием @r1 при вызове f

почему в Int преобразуем поле "a", а из Int уже "b"?

ну это функция вида: { a :: String, b :: Int | r } -> { a :: Int, b :: String | r }

Никто не пробовал делать авторизация через auth0 на хаскеле? Думаю рест апи сервак на хаскеле запилить, но auth0 нужен

ERROR: S client not available

f :: HasField "a" r0 r1 String Int => HasField "b" r1 r2 Int String => Record r0 -> Record r2 f = (field @"b" %~ show) . (field @"a" %~ length)

auth0 == OAuth?

https://auth0.com/

или это?

чем auth0 отличается от стандартного OAuth?

f :: HasField "a" r0 r1 String Int => HasField "b" r1 r2 Int String => Record r0 -> Record r2 f = (field @"b" %~ show) . (field @"a" %~ length)

ага... т.е. мы меняем разные поля (и их типы). Типы случайно совпали как при композиции поля - String -> Int, Int -> String

или это?

На который ты ссылку прислал, просто у нас много чего через него работает

ага... т.е. мы меняем разные поля (и их типы). Типы случайно совпали как при композиции поля - String -> Int, Int -> String

да, это совпадение

auth0 == OAuth?

ну вроде oauth это проток

а auth0 - сервис

да, но является ли auth0 просто сервисом поддерживающим OAuth

или предоставляет какое-то дополнительное API которое нужно и используется

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

а во втором - нужно писать самому

@kana_sama Думаю, в f надо добавить forall r1.. А при вызове f @R1.

@kana_sama Думаю, в f надо добавить forall r1.. А при вызове f @R1.

нет-нет, код выше работает прекрасно же

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

типа forall r0 r2. Delta [("a", A, B), ("b", C, D)] r0 r2 === forall r0 {r1} r2. (F "a" r0 r1 A B, F "b" r1 r2 C D)

но этого нельзя делать в семействе

"этого" - это чего? forall?

да, нельзя скрыть внутри forall r1

от forall здесь вроде мало толку все равно. Потом придется это "доказывать". Надо конкретно вычислять. Не для произвольных r, а для каких-то твоих обобщенных рекордов. Мне кажется так.

да, но является ли auth0 просто сервисом поддерживающим OAuth

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

да, но является ли auth0 просто сервисом поддерживающим OAuth

а с того конца, где авторизация, там да, OAuth, или OpenID Connect, или SAML

ну т.е. для полноценного взаимодействия нужна либа

которую надо написать и помочь сообществу

Ассоциированный тип в Foo и диспетчеризация по нему?

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

завтипы) Чет подобная тема только что возникала в блахе

не пойду же я в бла за ответами по Хаскелю

у тебя в примере как-то типы не сходятся

или fooViaBar игнорируют параметр?