в большинстве случаев безосновательно

Вот это сейчас мощно было

модно?

чуваки полегче, вы ведь все боги

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

Тренд я бы сказал

например нераспарсить что написано и влезть с авторитетным мнением, это нормально

да ладно, парсер штука сложная, все ошибаются

а ещё он всегда приходит когда у меня плохое настроение и я не против поругаться

:/

Юз кейсов XML никто так и не нашел

мне аж стыдно

а ещё он всегда приходит когда у меня плохое настроение и я не против поругаться

А мне не стыдно)

неужто банкообщение и прочее ушло на yaml?

в странах где einvoice и т.п. стали обыденностью, конечно

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

Ага, половина софта XML использует, а юзкейсов нет)

Haskell https://combot.org/chat/-1001043143583 https://t.me/haskellru

Даже среди типовых форматов файлов xml'я полно.

ну наверное простой конфиг я бы не хотел xml-ем писать

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

Хз, я не раз это делал, и не жалею. Простые конфиги имеют свойство становиться непростыми.

и когда я не хочу автоматом pdf из сообщения негерить

и xslt трансформации натравливать

расширяемость ибо

дело было в рельсах, там есть возможность сериализовывать объекты прямо в yaml и хранить их в таком виде прямо в базе. Раз возможность есть, то рано или поздно кто-нибудь ей воспользуется. Чтобы такой yaml корректно парсился нужно чтобы он соответствовал коду, а в код понадобилось как то внести изменения. После первого опыта такого апдейта появилось понимание что надо что то менять. Так как база была postgres, выбор был между jsonb (aka json) и xml. В json данные нормально просто было не впихнуть а xml позволял писать простые миграции на xslt, но примерно в этот момент мы заметили что десериализация это ботлнек и в итоге пришлось фигачить байткод, а обновление писать на тяжелых костылях прямо в рантайме

ну наверное простой конфиг я бы не хотел xml-ем писать

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

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

неужто банкообщение и прочее ушло на yaml?

Ещё с кобола не все ушли

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

кстати, а хаскель вообще yaml 1.2 поддерживает? На уровне библиотек

Джентельмены, а как реализуется функция pure?

в зависимости от класса типов

Джентельмены, а как реализуется функция pure?

А вы с какой целью интересуетесь?

Просто так

мне вопрос не до конца понятен

Просто так

для каждого инстанса Applicative по своему

Понял

Спасибо:)

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

Джентельмены, а как реализуется функция pure?

return (или pure) упаковывает значение в контейнер тривиальным образом, т.е. как будто (побочного) эффекта нет. Монада Maybe описывает вычисления с возможной ошибкой, но return x = Just x, т.е. ошибки нет. Монада списка описывает недетерменированные вычисления, но return x = [x], т.е. результат детерменирован. Монада State описывает вычисления с изменяющимся состоянием, но return x = \s -> (x, s), то есть состояние не меняется. И так далее.

А чем return от pure отличается?

Там монада а там апликатив?

pure в Applicative, return в Monad. Для тех типов, для которых есть Monad — ничем не отличается

Спасибо:)

Джентельмены, а как реализуется функция pure?

Возможно хорошая интуиция - pure описывает не результат, а аргумент. То есть pure берет чистое (pure) значение и отдает эффектное значение (лишь по типу, никаких эффектов оно не делает (по законам, по факту зависит от реализации)) То есть типа (seconds 10, color "red", pure 10)

у меня нету проблем с кабалом и зависимостями

Счастливый человек. Даже жалко, что у остальных не так...

а какие проблемы?

и как стек их решает

ну кроме того что помогает засунуть голову в песок

Не знаю, что там сейчас в кабал-инстале... Раньше жесть была. Посмотрю ещё раз, когда префиксы уберут у команд.

Я к тому, что нет смысла топить за свой любимый фронт к библиотеке, тем более таким образом.

Стэк это не только вредно, но и полезно.

каким-таким?

@icrbow ^

похоже я так и не узнаю каким образом я топлю за кабал

печалька

и почему таким образом топить за кабал нельзя

и можно ли каким-то образом топить за стек

видимо можно, т.к. цитаты тем, кто топит за стек из истории никто не выдергивает

Последние разы когда я стэуом пользовался - часто прилодилось чистить папку стэка.

Я за Никс+Кабал

Мы туда же идем в Serokell.

stack clean --full является у нас мемом.

Задача инкрементить одну переменную в разных потоках странная, но именно такой тест был бы полезен для замера производительности STM и MVar.

Что странного? Есть набор объектов, обрабатываемых в разных потоках. Нужны два счётчика: общее количество и количество "плохих" объектов. В отдельном, не сильно загруженом потоке выводится всякая статистика: скорость обработки объектов, качество обработки и т.д. Достаточно типовая задача, имхо.

самым быстрым — то ли atomicModifyIORef, то ли внезапно Vector.Stored из одного элемента

А как в Vector сделать атомарное инкрементирование? succ справится? Компилятор сделает его атомарным?

я бы решая такую задачу инкрементил в потоке-суперввизоре

хотя по перформансу не так круто, конечно

Можно и так

но вообще странно что перформанс инкремента важен в контексте обработки объектов

мне кажется на фоне обработки пофигу

В целом, да. Но если это делается двумя-тремя строчками кода, почему бы и не улучшить производительность на 0.01% ;)

ну это при прочих равных

Что странного? Есть набор объектов, обрабатываемых в разных потоках. Нужны два счётчика: общее количество и количество "плохих" объектов. В отдельном, не сильно загруженом потоке выводится всякая статистика: скорость обработки объектов, качество обработки и т.д. Достаточно типовая задача, имхо.

Совсем не ясно из текста, зачем инкрементить переменные конкурентно, а не, скажем, вернуть из потоков локальное количество после того, как потоки отработают.

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

В целом, да. Но если это делается двумя-тремя строчками кода, почему бы и не улучшить производительность на 0.01% ;)

А проблема-то есть с производительностью? Сначала нужно вот этот вопрос понять. Смысл что-то оптимизировать, если и так все хорошо. Тем более на 0.01%

А как в Vector сделать атомарное инкрементирование? succ справится? Компилятор сделает его атомарным?

атомарное - никак

Так а зачем тогда Vector.Storable предлагать? Там же сразу гонка будет на инкрементации

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

можно как-нибудь Applicative и Functor автоматически вывести из Monad? Хочу удалить такой код instance Applicative where pure = return (<*>) = ap instance Functor where fmap = ap . return

или так все пишут, и это норм?

Тут тоже задача не ясна. Что значит - удалить код? Кто-то его написал, а ты решил, что это не нужно? Или ты написал свою монаду и захотел инстансы не определять?