wreq с линзами

как первую либу я даже не знаю можно ли его предлагать

кто тут auth0 спрашивал?

https://github.com/alasconnect/auth0

не ожидал, что хаскелист станет такие вещи делать, конечно https://haskell-code-explorer.mfix.io/package/lens-4.16.1/show/src/Control/Lens/Indexed.hs#L425

не ожидал, что хаскелист станет такие вещи делать, конечно https://haskell-code-explorer.mfix.io/package/lens-4.16.1/show/src/Control/Lens/Indexed.hs#L425

что именно не так в этой строке?

речь не про строку, а про то, что ее показывает

Всем привет. Есть ли в Haskell способ сделать деструктуризацию значения из конструктора полиморфно? Хотелось бы вместо этого: chatId' = (\(ChatId id) -> show id) . chatId . messageChat <$> mСделать что-то вроде этого: chatId' = show . UNPACK_CONSTRUCTOR_FN . chatId . messageChat <$> m

generic-lens

Всем привет. Есть ли в Haskell способ сделать деструктуризацию значения из конструктора полиморфно? Хотелось бы вместо этого: chatId' = (\(ChatId id) -> show id) . chatId . messageChat <$> mСделать что-то вроде этого: chatId' = show . UNPACK_CONSTRUCTOR_FN . chatId . messageChat <$> m

пакет newtype

если newtype там, то использовать coerce

и не мучаться

если много конструкторов, то generic-lens

generic-lens

Iso из lens — да. generic — детали

Prism я не iso если конструктора боьлше 1

в линзах это Wrapped

chatId = coerce . chatId . messageChat <$> m

Спасибо ?

coerce FTW

Prism я не iso если конструктора боьлше 1

из примера кажется, что там ровно один конструктор. кому нужны частичные функции?

мне

почему люди боятся частичных функций

Топовый чат у Вас. Не только помогут, а и расскажут о нескольких вариантах и их различиях :)

спасибо

Что за частичные функции?

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

почему люди боятся частичных функций

я не боюсь, просто когда я хочу, чтобы программа падала в рантайме, я беру JavaScript

например head для списка

без них конечно всегда лучше

но прятать голову в песок и требовать убарть их все в т.ч. из base/prelude - затея не очень

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

но прятать голову в песок и требовать убарть их все в т.ч. из base/prelude - затея не очень

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

не у меня просто проект долго компиляется

Мне нужно в несколько тредов делать IO, и у каждого треда должно быть состояние, которое обновляется, и должен быть главный тред, который по таймеру собирает самые актуальные состояния тредов. Есть какой-нибудь design pattern для этого случая, или, может быть, библиотека?

Я бы STM запользовал

async?

Я бы STM запользовал

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

async?

А как он поможет? Есть тред-мониторинг, который данные других тредов собирает. А те крутятся сами по себе

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

Ну что значит - вместе. Если они вообще изменяются, и хочется их прочитать, не блокируя ничего

STM нужен

Ну что значит - вместе. Если они вообще изменяются, и хочется их прочитать, не блокируя ничего

atomicModifyIORef

паттерна не видел

atomicModifyIORef

это вопрос нужно ли читать все данные транзакционно или нет

atomicModifyIORef

Ну можно, конечно. Не очень удобно, но можно

это вопрос нужно ли читать все данные транзакционно или нет

вот я с этого и начал

если newtype там, то использовать coerce

Я даже реализовал в relude несколько полезных утилитных фуцнкций на основе Coercible по работе с ньютайпами. Можно примеры здесь посмотреть: http://hackage.haskell.org/package/relude-0.3.0/docs/Relude-Extra-Newtype.html

это вопрос нужно ли читать все данные транзакционно или нет

Даже если не нужно транзакционно, что мешает использовать STM?

вот я с этого и начал

а, я просто прочитал там "изменяться" а не читаться

IORef пошустрее

и поменьше шума, там atomically писать не надо и все такое

но вообще использовать STM by default это нормально

а, я просто прочитал там "изменяться" а не читаться

правильно прочитал. но я имел в виду любой доступ, не только modify

Ну, это уже пошли неявные предположения о требованиях, которые озвучены не были

на ум приходит что-то вроде Map ThreadId IORef

Мне нужно в несколько тредов делать IO, и у каждого треда должно быть состояние, которое обновляется, и должен быть главный тред, который по таймеру собирает самые актуальные состояния тредов. Есть какой-нибудь design pattern для этого случая, или, может быть, библиотека?

тредов фиксировнное число или нет?

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

Не должны. А чем подход forkIO + MVar хуже/отличается?

MVar дороже IORef

будет блокировка

тредов фиксировнное число или нет?

Не фиксированное.

@cblp_su предложил forkIO + IORef

вообще forkIO + какая-то структура поверх STM/IORef/MVar на выбор

Map ThreadID IORef вполне норм

IORef пошустрее

readTVarIO вроде такой-же

IORef (Map ThreadID IORef)

readTVarIO вроде такой-же

возможно, это не мерял

вообще STM по умолчанию вполне норм

Ок, пока буду использовать IORef. Транзакции и блокировки мне не нужны точно.

если одна нить пишет, а другая читает, то нужна атомарность

ты ж не в вектор пишешь вещи больше слова

так.. стоп, я чего-то imply-ю что другие думают

в общем если тебе нужно единомоментный срез всех состояний

то тогда нужны транзакции

т.е. пока ты читаешь состояние одного треда - состояние других поменяется

если хочется это исключить,то нужны транзакции

в так IORef дает нужную атомарность

если хочется это исключить,то нужны транзакции

Мне не нужно это исключать.

в целом: r <- mkRegistry .. forkWithUnmask $ \release -> )register r »= release . runStuff x) `finally` unregsiter r)

где mkRegistry это newIORef Map.empty

register r = myThreadId »= \x -> newIORef emptyState »= \s -> atomicallyModifyIORef r (Map.insert x s) » pure s

IORef (Map ThreadID IORef)

А первый IORef зачем?

если у тебя не главный тред форкает и отстанавливает

то тогда у тебя хранилище это тоже shared струтура

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

(обновил код выше)

unregister r = myThreadId »= atomicallyModifyIORef' r . Map.delete

что-то такое, писал сразу в чятик

и вместо ThreadID может быть ключ поближе к задаче

да

Спасибо.

ещё можно предложить вообще решение вбок - и скидывать состоояние в канал какой

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

если состояние "готово — не готово", то вообще async как есть

ещё можно предложить вообще решение вбок - и скидывать состоояние в канал какой

?

мы ж задачи не знаем

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

мониторящий тред смотрит канал если надо и что-то делает

В STM каналы тоже есть, ага