Alexander
Prism я не iso если конструктора боьлше 1
Зигохистоморфный
в линзах это Wrapped
Alexander
chatId = coerce . chatId . messageChat <$> m
Artem
Спасибо 😊
Alexander
coerce FTW
Cheese
Prism я не iso если конструктора боьлше 1
из примера кажется, что там ровно один конструктор. кому нужны частичные функции?
Alexander
мне
Alexander
почему люди боятся частичных функций
Artem
Топовый чат у Вас.
Не только помогут, а и расскажут о нескольких вариантах и их различиях :)
Alexander
спасибо
Artem
Что за частичные функции?
Alexander
которые не выдают значения, а ломаются на определенном множестве параметров
Cheese
почему люди боятся частичных функций
я не боюсь, просто когда я хочу, чтобы программа падала в рантайме, я беру JavaScript
Alexander
например head для списка
Alexander
без них конечно всегда лучше
Alexander
но прятать голову в песок и требовать убарть их все в т.ч. из base/prelude - затея не очень
A64m
я понимаю, почему люди боятся частичных функций, я не понимаю почему они боятся особенно или даже исключительно крайне узкой их разновидности в языке где чуть менее чем все функции такие
Cheese
но прятать голову в песок и требовать убарть их все в т.ч. из base/prelude - затея не очень
я же сейчас не про prelude, а про лямбду в пользовательском коде. а у тебя пригорело
Alexander
не у меня просто проект долго компиляется
Vladimir
Мне нужно в несколько тредов делать IO, и у каждого треда должно быть состояние, которое обновляется, и должен быть главный тред, который по таймеру собирает самые актуальные состояния тредов.
Есть какой-нибудь design pattern для этого случая, или, может быть, библиотека?
Alexander
Я бы STM запользовал
Зигохистоморфный
async?
Cheese
Я бы STM запользовал
только если разные состояния должны изменяться вместе. если не вместе, то STM не нужен
Alexander
async?
А как он поможет? Есть тред-мониторинг, который данные других тредов собирает. А те крутятся сами по себе
Alexander
только если разные состояния должны изменяться вместе. если не вместе, то STM не нужен
Ну что значит - вместе. Если они вообще изменяются, и хочется их прочитать, не блокируя ничего
Alexander
STM нужен
Cheese
Alexander
паттерна не видел
Dmitrii
если newtype там, то использовать coerce
Я даже реализовал в relude несколько полезных утилитных фуцнкций на основе Coercible по работе с ньютайпами. Можно примеры здесь посмотреть:
http://hackage.haskell.org/package/relude-0.3.0/docs/Relude-Extra-Newtype.html
Alexander
это вопрос нужно ли читать все данные транзакционно или нет
Даже если не нужно транзакционно, что мешает использовать STM?
Alexander
IORef пошустрее
Alexander
и поменьше шума, там atomically писать не надо и все такое
Alexander
но вообще использовать STM by default это нормально
Cheese
а, я просто прочитал там "изменяться" а не читаться
правильно прочитал. но я имел в виду любой доступ, не только modify
Alexander
Ну, это уже пошли неявные предположения о требованиях, которые озвучены не были
Cheese
на ум приходит что-то вроде Map ThreadId IORef
Alexander
Мне нужно в несколько тредов делать IO, и у каждого треда должно быть состояние, которое обновляется, и должен быть главный тред, который по таймеру собирает самые актуальные состояния тредов.
Есть какой-нибудь design pattern для этого случая, или, может быть, библиотека?
тредов фиксировнное число или нет?
Vladimir
только если разные состояния должны изменяться вместе. если не вместе, то STM не нужен
Не должны.
А чем подход forkIO + MVar хуже/отличается?
Alexander
MVar дороже IORef
Alexander
будет блокировка
Alexander
@cblp_su предложил forkIO + IORef
Alexander
вообще forkIO + какая-то структура поверх STM/IORef/MVar на выбор
Alexander
Map ThreadID IORef вполне норм
Leonid 🦇
Alexander
IORef (Map ThreadID IORef)
Alexander
вообще STM по умолчанию вполне норм
Vladimir
Ок, пока буду использовать IORef. Транзакции и блокировки мне не нужны точно.
Cheese
если одна нить пишет, а другая читает, то нужна атомарность
Alexander
ты ж не в вектор пишешь вещи больше слова
Alexander
так.. стоп, я чего-то imply-ю что другие думают
Alexander
в общем если тебе нужно единомоментный срез всех состояний
Alexander
то тогда нужны транзакции
Alexander
т.е. пока ты читаешь состояние одного треда - состояние других поменяется
Alexander
если хочется это исключить,то нужны транзакции
Alexander
в так IORef дает нужную атомарность
Alexander
в целом:
r <- mkRegistry
..
forkWithUnmask $ \release -> )register r »= release . runStuff x) `finally` unregsiter r)
Alexander
где mkRegistry это newIORef Map.empty
Alexander
register r = myThreadId »= \x -> newIORef emptyState »= \s -> atomicallyModifyIORef r (Map.insert x s) » pure s
Alexander
если у тебя не главный тред форкает и отстанавливает
Alexander
то тогда у тебя хранилище это тоже shared струтура
Alexander
и тред который мониторит должен получать обновления
Alexander
(обновил код выше)
Alexander
unregister r = myThreadId »= atomicallyModifyIORef' r . Map.delete
Alexander
что-то такое, писал сразу в чятик
Cheese
и вместо ThreadID может быть ключ поближе к задаче
Alexander
да
Vladimir
Спасибо.
Alexander
ещё можно предложить вообще решение вбок - и скидывать состоояние в канал какой
Alexander
внутри треда же состояние не обязано в изменяемой переменной жить
Cheese
если состояние "готово — не готово", то вообще async как есть
Alexander
мы ж задачи не знаем