Кажется я видел такое

А, стоп, я перепутал, мне просто функтор нужен)

А я старался, вспоминал!(

TIL. спасибо

это, получается, полугруппа в категории эндофункторов?

у Telegram есть ограничение по отправке сообщений за секунду. допустим, есть основной поток, который обрабатывает сообщения от пользователей, и другой, который только отправляет сообщения. так как эти потоки работают независимо, то они не знают, как много сообщений было отправлено за секунду, поэтому можно привысить лимиты. решение очевидно — сделать очередь, в которую будут складываться все сообщения, которые нужно отправить, но возникает пару вопросов:
1) как реализовать эту очередь? стоит ли прибегать ко всяким RabbitMQ?
2) стоит ли делать два отдельных бинарника или можно всё оставить в одном бинарном файле? (условно, один поток наблюдает за изменениями на сайте и если они есть, то он присылает сообщение, а второй отвечает за непосредственное взаимодействие с теми, кто пользуется ботом)

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

Берёшь TQueue и делаешь отдельный поток

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

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

Очередь достаточно из циферок, а не самих сообщений.

извините, но я вас не понял. я попробую объяснить, почему без очереди нельзя обойтись. очевидно, отправкой сообщений надо заниматься в отдельном потоке. надо передавать данные в этот самый поток, сообщения могут накапливаться, поэтому нужно такое хранилище, которые сможет хранить более одного сообщения. что делает этот поток? он достаёт сообщение, далее проверяет по времени, можно ли его отправить, иначе либо ждёт, либо переходит к следующему сообщению (тут надо подумать над алгоритмом) и так, пока не закончатся сообщения в очереди. вот моя задумка. может быть, можно проще, но, честно, я не знаю как

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

а. понял. т.е. сразу же планировать отправку сообщения, а не усыплять поток. интересно... спасибо

делай батчи и отправляй за раз все нужные сообщения, не?

так не получится, потому что с помощью sendMessage можно отправить только одно сообщение за раз. и смысла собирать сообщения в группу нет, всё равно лучше их отправку лучше запланировать

А я бы не планировал ничего (сложно это), а использовал бы Rate Limited queue consumption. То есть, вот у меня сам "сервис", который читает очередь и делает sednMessage был бы ограничен определённым количеством операций в секунду.
Может быть даже https://hackage.haskell.org/package/rate-limit-1.4.2 подощёл бы.

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

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

entities <- m_obj .: "entities"
let (mapped_entities :: [Maybe Text]) = fmap convert entities
      where
        convert = AesonT.parseMaybe (Aeson.withObject "Entity" (\val -> val .: "type"))
guard (Just "bot_command" `elem` mapped_entities)

Это часть из parseJSON, мне по сути нужно убедится, что в массиве "entities" есть объект с ключем "type" и значением "bot_command"