а потом имея Int так хоп (decode :: T)

s/Int/Nat

Фактически меня интерезует десерелизация экзестенциальных типов данных.

https://ruhaskell.org/posts/theory/2016/01/06/serialization-with-deptypes.html

может подойдет?

Сейчас пороюсь в этом направлении, благодарю.

если честно я не до конца уверен стоит ли оно того

было написано в ответ на вопрос, в стиле "because I can"

тут нам не идрис, там немного человечнее можно

тут нам не идрис, там немного человечнее можно

Очень жаль :( но вроде бы народ усиленно впиливает зависимые типы.

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

можно многое но сильно меньше, чем в идрисе

В статье конечно немного жестоко, отнюдь не то элегантное решение, которое мне бы хотелось :(

достаточно элегантным решением будет ADT и один парсер :)

хм.. в tasty есть withResource: withResource :: IO a -> (a -> IO ()) -> (IO a -> TestTree) -> TestTree

а есть какая-нить человеческая возможность засунуть туда ресурс формы withX ?

только если все тесты оборачивать

ну или каждый конкретный

под-дерево только так

поидее я могу With ( R a -> IO a) засунуть внутрь, но как-то это не очень почеловечески будет

достаточно элегантным решением будет ADT и один парсер :)

Ну сейчас там data T = T1 T1 | T2 T2, если грубо.

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

хм.. в tasty есть withResource: withResource :: IO a -> (a -> IO ()) -> (IO a -> TestTree) -> TestTree

все эти withX можно использовать с Codensity IO или более красивее c Managed https://hackage.haskell.org/package/managed-1.0.6/docs/Control-Monad-Managed.html

т.е. класс ошибок, который она снимет достаточно маленький

все эти withX можно использовать с Codensity IO или более красивее c Managed https://hackage.haskell.org/package/managed-1.0.6/docs/Control-Monad-Managed.html

мне кажется же что Managed туда не натянется

оно ползволяет красивее писать, а не "разбивать" вычисление

так там ResourceT?

у тебя

тип withResource видишь?

вот у меня он

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

Отговорите плз заменять [Word8] на ByteString

Я в общем-то и так не хочу, но чувство эквивалентное прекрасному пока сильнее.

Заменяй на ShortByteString

Заменяй на ShortByteString

Слишком немэйнстримно

/me отхлебнул смузей. Ну да

На самом деле он там и не подойдёт.

Этот же для всяких константных словарей типа хедеров, не?

А у меня скорее билдер/парсер

Ну да, типа чтоб не дырявить память

в любом случае, [a] - не контейнер а control structure

Этот же для всяких константных словарей типа хедеров, не?

это для unpinned

ну и у него нету операций за O(1) откусить кусок

ByteString вообще сильно лучше [Word8]

с Storable.Vector Word8 тоже лучше

и ByteArray# =)

#anime а вот например

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

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

FML

https://twitter.com/dshevchenko_biz/status/981186400769970176

Везде где поинтфри совсем не лезет

$ ag 'do\s' | wc -l 3559

Я просто нашёл один простой пакетик, cond называется. Он содержит conditional operators для работы в монадическом контексте, а-ля ifM. И мне нравится такой, но не снизит ли это читабельность кода?

Я просто нашёл один простой пакетик, cond называется. Он содержит conditional operators для работы в монадическом контексте, а-ля ifM. И мне нравится такой, но не снизит ли это читабельность кода?

а чем guard плох?)

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

получается компактнее, но не теряется ли простота восприятия?..

да, я понимаю, риторический вопрос

ByteString вообще сильно лучше [Word8]

Чем же?

memory layout-ом хотя бы

ты ж знаешь что Word8 размер слово?

а не 8 бит?

Незначительный фактор у меня. Удобство кода скорее поважнее будет.

и на каждый indirection

и объетное представление

и cons конструктор

Я просто нашёл один простой пакетик, cond называется. Он содержит conditional operators для работы в монадическом контексте, а-ля ifM. И мне нравится такой, но не снизит ли это читабельность кода?

Мне пришлось такие комбинаторы в С++ использовать. Там они улучшают читаемость.

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

WHNF: https://wiki.haskell.org/Weak_head_normal_form (для тех, кто в танке)

Я сказал, что на хаскеле нет работы и мне дали этот чат, но я же знаю, что половина из вас это фронтендщики

Я просто нашёл один простой пакетик, cond называется. Он содержит conditional operators для работы в монадическом контексте, а-ля ifM. И мне нравится такой, но не снизит ли это читабельность кода?

Поддерживаю. Часто чего-то такого хочется. И многие прелюдии притаскивают подобные функции

Я сказал, что на хаскеле нет работы и мне дали этот чат, но я же знаю, что половина из вас это фронтендщики

Не, фронтендеры не тут сидят

Тут рубисты и питонисты одни же

@kana_sama фронтендер

("фронтендщики" и "работа на Haskell" не конфликтуют)

@kana_sama фронтендер

Но он и не работает на хаскеле :)

Но он и не работает на хаскеле :)

так нет

подожди

ты нарушил логическую цепочку

поинт был в том что типа «мне дали этот чат, но я же знаю что половина из вас это [не хаскеллисты а] фронтендщики»