ну монадки слишком абстрактны

в его случае он вообще поведения комонады хочет w a -> a

да ето так

ну если не скатываться совсем в оффтопик

то имея в do-нотации строку уровня myInt <- getIntFromSomewhere

можно написать рядом let squaredInt = sqr myInt

видимо, этого @valsaven и хочет

постановки задачи даже не увидел

ну «передать Int от пользователя в функцию»

звучит как «получить Int извне, преобразовать чистыми функциями и выплюнуть обратно»

насколько позволяют понять мои телепатические способности

лучше конечно разобраться почему, если интересно (https://t.me/haskell_learn), иначе это будет до следующей подобной "проблемы"

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

Тем более там IO в самом конце))

@valsaven вот тебе пример с передачей Int process = do n <- print "Input count of numbers " >> getLine case (readEitherSafe :: String -> Either String Int) n of Left s -> print s >> process Right v -> do xs <- T.for [1..v] $ \ i -> do print $ "Input number #" ++ show i getLine case traverse (readEitherSafe :: String -> Either String Int) xs of Left s -> print s Right xs'' -> print $ sum xs'' main :: IO () main = process

Скажите, пожалуйста, кто-нибудь понимает, как поживают OverloadedRecordFields? после февраля 2017 (эпический бой про линзы https://github.com/ghc-proposals/ghc-proposals/pull/6) ничего не видно, в том числе, в ghc wiki

Скажите, пожалуйста, кто-нибудь понимает, как поживают OverloadedRecordFields? после февраля 2017 (эпический бой про линзы https://github.com/ghc-proposals/ghc-proposals/pull/6) ничего не видно, в том числе, в ghc wiki

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

т.е. механика орфовская из пропозала вся в 8.2 есть, только инстанс для лейблов не прошел

собственно вопрос, есть ли новости, когда и в каком виде пройдёт?

но есть ли в этом смысл? сам функционал у ORF довольно убогий, не лучше ли какой-нибудь generic-lens использовать?

собственно вопрос, есть ли новости, когда и в каком виде пройдёт?

нет, новостей никаких нет, никто над этим не работает

ну, вернее, можно предположить что работа Гендри над абстрактными линзами это часть работы по ORF

я не хотел бы обсуждать линзы: изначально ORF рекламировался, как более гибкий механизм геттеров (условно, избавление от требования уникальности имён). Разница с линзами такая, что геттеры это entry-level средство Haskell, в то время как линзы это что угодно,но не entry-level (называйте advance или ка квам нравится)

я не хотел бы обсуждать линзы: изначально ORF рекламировался, как более гибкий механизм геттеров (условно, избавление от требования уникальности имён). Разница с линзами такая, что геттеры это entry-level средство Haskell, в то время как линзы это что угодно,но не entry-level (называйте advance или ка квам нравится)

ну та часть ORF где избавление от уникальности имен с 8.0 работает

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

(Duplicate)

геттерами как функциями нельзя (без аннотации типа, там такой убогий близорукий TDNR), а в пм с вайлдкартами можно, я так их всегда восновном и использовал

а роу-полиморфизм для геттеров из ORF в 8.2 и сам по себе не энтрилевельный, там уже что с линзами что без линз. Без линз просто убого все и неудобно

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

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

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

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

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

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

никогда. в первоначальном плане это было, но инстанс не успел в 8.0, а до 8.2 уже кучу библиотек использующих лейблы понаписали, значительную часть из них этот инстанс сломал бы, общественность растревожилась и инстанс заклевала. Конец истории

ну, может можно протащить сиротский инстанс в отдельном модуле в base, который все равно в библиотеках не используешь, также можно и подругому ORF сделать, но вроде никто не делает

ORF Гендри и так раза 4 делал прежде чем он в нынешнем виде попал в 8.2, я что-то сомневаюсь, что 5й раз будет делать

последнее что видно от него на эту тему это подпиливание DRF (октябрь 2017) https://github.com/ghc-proposals/ghc-proposals/pull/84

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

а пример, кстати, есть где-то в общедоступном месте? я вот искал и не нашёл. Там instance IsLabel нужен?

последнее что видно от него на эту тему это подпиливание DRF (октябрь 2017) https://github.com/ghc-proposals/ghc-proposals/pull/84

да, но это никак не улучшает ситуацию с геттерами (наоборот, ухудшает)

а пример, кстати, есть где-то в общедоступном месте? я вот искал и не нашёл. Там instance IsLabel нужен?

он там в обсуждении же был вроде

{-# LANGUAGE AllowAmbiguousTypes , FlexibleInstances , MultiParamTypeClasses , ScopedTypeVariables , TypeApplications , DuplicateRecordFields , OverloadedLabels , FlexibleContexts #-} module Records where import GHC.OverloadedLabels import GHC.Records instance HasField x r a => IsLabel x (r -> a) where fromLabel = getField @x как-то так это должно все выглядеть

{-# LANGUAGE AllowAmbiguousTypes , FlexibleInstances , MultiParamTypeClasses , ScopedTypeVariables , TypeApplications , DuplicateRecordFields , OverloadedLabels , FlexibleContexts #-} module Records where import GHC.OverloadedLabels import GHC.Records instance HasField x r a => IsLabel x (r -> a) where fromLabel = getField @x как-то так это должно все выглядеть

о, здорово, спасибо! примера на видном месте так и не нашёл :( кстати, опытным путём установлено, что AllowAmbiguousTypes, OverloadedLabels и FlexibleContexts можно опустить; тем не менее, выглядит, конечно, печально…

получилось вот как-то так: {-# LANGUAGE FlexibleInstances , MultiParamTypeClasses , ScopedTypeVariables , TypeApplications , DuplicateRecordFields , OverloadedLabels #-} import GHC.OverloadedLabels import GHC.Records data Person = MkPerson { name :: String } data Dog = MkDog { name :: String } instance HasField x r a => IsLabel x (r -> a) where fromLabel = getField @x bark :: Dog -> IO () bark d = putStrLn $ "Arrg from " ++ #name d main = bark $ MkDog "Spike"

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

OverloadedLabels как раз нужны там где соотв. синтаксис используется

в примере выше же есть #name или речь о каком-то другом синтаксисе?

в примере выше же есть #name или речь о каком-то другом синтаксисе?

есть, так что не должно без OverloadedLabels компилироваться

ну вот компилируется…

наверное просто ранее скомпилированное работает или что-то вроде

да, извиняюсь, это я в GHCi пробовал с включённым флагом

Ребят, я дико извиняюсь, но что это за лейблы и как они связаны с линзами?

Ребят, я дико извиняюсь, но что это за лейблы и как они связаны с линзами?

синтаксис #foo который рассахаривается в вызов метода класса fromLabel @"foo" т.е. можно написать инстанс который будет линзу для поля с именем foo или геттер как в примере выше подставлять

Ребят, я дико извиняюсь, но что это за лейблы и как они связаны с линзами?

более подробное объяснение тут https://github.com/ghc-proposals/ghc-proposals/pull/6#issuecomment-276150270

Нас 600

Нас 600

элита ?

давайте всё-таки поговорим о том, когда не стрёмно использовать type family , а не data family

иногда они нужны

есть какие-то best practices / или заметки, что избегать в каких случаях

я почти никогда не использую data family

ну помимо ассоциированных?

или ты даже и в ассоциированные делаешь type family, а потом везде прокси таскаешь или type applications ?

так-то понятно, что без data family удобнее было бы.

народ, haskell же не делает откаты, как Prolog?

а пролог делает откаты? надо его внедрить в госсектор

Подскажите, пожалуйста, правильно ли я понимаю работу с SQLite в Haskell при помощи sqlite-simple (https://github.com/nurpax/sqlite-simple). Создаём АДТ (data), который будет отображать одну запись в отдельно взятой таблице нашей БД. Создаём инстанс тайпкласса FromRow для этого АДТ, в котором реализуем функцию для преобразования SQL-записи в этот АДТ. Можете, пожалуйста, исправить и/или дополнить то, что я сказал?

народ, haskell же не делает откаты, как Prolog?

нет, паттерн матчинг строго линейный

нет, паттерн матчинг строго линейный

то есть, первый, который подошел, тот и отработает, да?

Да

ERROR: S client not available

супер) спасибо)

Подскажите, пожалуйста, правильно ли я понимаю работу с SQLite в Haskell при помощи sqlite-simple (https://github.com/nurpax/sqlite-simple). Создаём АДТ (data), который будет отображать одну запись в отдельно взятой таблице нашей БД. Создаём инстанс тайпкласса FromRow для этого АДТ, в котором реализуем функцию для преобразования SQL-записи в этот АДТ. Можете, пожалуйста, исправить и/или дополнить то, что я сказал?

да, (лично меня такой стиль бесит и я из рядов руками разбираю или делаю инстанс для vinyl/vinyl-like структуры)

Ясно, спасибо. Наверное я всё же где-то налажал с определениями/описаниями?

на текущий момент какой самый быстрый и норм. работающий бинарный сериализатор есть?

нужен что бы 1) сдампить объект 2) посчитать хэш 3) использовать как ключ

т.е версионность не нужна, например

https://hackage.haskell.org/package/store - ок, например?

store/cvor

cbor

один из этих

вы что используете?

и как давно

За cvor и cbor стреляешь в упор?

cbor называется сериалайз же

я не помню, когда использовали то cbor был

сейчас мы store юзаем, оно под наши данные лучше точно

+ у нас только trusted source и мы их прямо во внешний мир не отдаем, и многие vector-like

ну мне вообще просто хэш посчитать от чего-нибудь.

от сериализованного представления норм?

ну, да.

store аллоцирует всю байтостроку, но это ж норм?

объекты маленькие

пока что.

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

пока что кажется что это пофиг, ботлнек будет не здесь

наверное с компактами можно?

ну да

разумно

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

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

store норм

что-то мне кажется компакты не самая хорошая идея чтоб хеш считать