« Rev
@haskellru   1479
Fwd »


Cheese
если отладочную печать, то смириться с Аски
Cheese
если Юникод, то выводить в Doc или yaml
IC
а не будет ли в мск скоро хаскельных конф?
Cheese
насколько мне известно, вероятность ненулевая, но очень низкая. если есть темы докладов, присылай мне
IC
странно.. я вспомнил, как это чуть ли уже не done deal было... где-то зимой
Cheese
Πάντα ῥεῖ
Cheese
ты прав, зимой оценка вероятности была выше
Alexander
тут скоро зурихак
Alexander
что сильно понижает вероятность того что люди ещё и в мск соберутся
Anatolii
я в других языках видел асертеры для тестов которые показывали дифф по типу гита - тоесть только ту часть структур которые разошлись, hunit мне просто печатает полностью expected и actual
Anatolii
и что-то я не могу такого нагуглить
Anatolii
может подскажет кто?
Cheese
только в hedgehog видел подобное
Влод
Hspec
Anatolii
hedgehog мне сейчас не оч подходит
Anatolii
буду hspec смотреть
Anatolii
я насколько помню - там property-based тестирование?
IC
там всё есть. есть и простые ассерты
IC
пишешь кейс вручную, а потом заворачиваешь в forAll генератор значений и получаешь проперти
IC
я заворачивал в обвязку tasty и мне понравилось
Anatolii
Хм, надо будет глянуть, а у тебя нет нигде примеров кода?
anton
широко известная группа в узких кругах 65daysofstatic пишет музыку на хаскеле https://www.youtube.com/watch?v=_OAKUlRlNF0
anton
библиотека Tidal
anton
https://github.com/tidalcycles/Tidal
IC
Хм, надо будет глянуть, а у тебя нет нигде примеров кода?
-- обвязка tasty для интеграции в `TestTree` Hedgehog.property $ do -- assert foo === "foo" -- property test <- forAll $ Gen.element [0..100] test === 42
IC
там в принципе отчёт о завале теста выглядит шикарно
IC
дифы, логи, промежуточные значения... единственное не хватает запуска IO с перехватом stdin/stderr
IC
делаешь Debug.Trace.traceM и в выводе куча-мала
IC
особенно если параллельно гоняешь
Aleksei (astynax)
Накал про установку хаскельтулзов: https://github.com/ruHaskell/ruhaskell/wiki/%D0%A3%D1%81%D1%82%D0%B0%D0%BD%D0%BE%D0%B2%D0%BA%D0%B0-%D0%B2%D1%81%D0%BF%D0%BE%D0%BC%D0%BE%D0%B3%D0%B0%D1%82%D0%B5%D0%BB%D1%8C%D0%BD%D1%8B%D1%85-%D0%BF%D1%80%D0%BE%D0%B3%D1%80%D0%B0%D0%BC%D0%BC-%D0%B4%D0%BB%D1%8F-%D1%80%D0%B0%D0%B7%D1%80%D0%B0%D0%B1%D0%BE%D1%82%D0%BA%D0%B8-%D0%BD%D0%B0-Haskell-%D1%81-%D0%BF%D0%BE%D0%BC%D0%BE%D1%89%D1%8C%D1%8E-stack
Sr
Если хочется compile-time, то придётся TH/QQ использовать
Sr
вот, кстати, было бы здорово иметь что-то для статического вычисления. прагму, например
Sr
Это не совсем задача компилятора. Любые такие вычисления можно проделать за рамками компиляции.
Sr
В примере выше статические константы. Их иметь вычисленными на этапе компиляции - удобно и логично
Sr
особенно если они частичные
Sr
Это сахар. Понятно что это удобнее чем считать самому, но все же это сахар. Потому что для вычислений вам нужно выполнить полный пол тюнингу код. А компиляция создана немножко для другого
Sr
это оптимизация, но когда ещё применять оптимизации, кроме как в компиляторе?
Sr
В хаскеле компиляция создана для всего, что можно туда запихнуть - кодогенерацию, IO, встраивание ресурсов в бинарник. Туда же относятся вычисления на типах. Вычисление констант ничем не отличается от вышеперечисленного.
Sr
Нет смотри. Вычисления на типах, биением и все что ты описал это не вычисления на хаскель. И это важно. А помнил, давай в общий чат, я там отвечу
Aleksei (astynax)
$(embedFile "foo") - вполне себе вычисление
Sr
И так, всё выше перечисленное это не хаскель. Тоесть тебе не нужно компилировать программу на хаскель чтобы поработать с типами библиотеками, помнить оптимизации и ТД.
Aleksei (astynax)
На этапе компиляции
Aleksei (astynax)
Если "не хаскель", то что?
Aleksei (astynax)
Это препроцессор в C++ - не C++. А TH, QQ - это хаскель
Aleksei (astynax)
Просто это не одна программа, а несколько. Часть программ выполняется при компиляции, а часть - в рантайме
Aleksei (astynax)
И всё это Хаскель
Cheese
$(embedFile "foo") - вполне себе вычисление
собственно, я начал с того, что помечтал о синтаксическом сахаре (а лучше отдельной фиче) для $(lift _expr)
Sr
Но если тебе нужно для компиляции программы А на языке Х выполнить программу В на языке Х используя определения из программы А то это рекурсия. И чтобы это решим тебе нужно компилировать программу А дважды. Первый раз без оптимизаций статических вычислений, потом провести все статические вычисления, потом написать новую программу А' в которой все статические вычисления заменятся константами
Sr
Это тянет на серьезный вклад в развитие компилятора Haskell
Sr
А когда все это появится в компиляторе то ты захочешь чтобы не только именованные константы предвычислчлись, но и все вычисоения, для которых аргументы известны на этапе компиляции там и были посчитаны. Тоесть это будут анонимные статические константы. Типа тех же fib 32
кана
ну и такое практикуют
Sr
> используя определения из программы Это не позволяется как раз. Но само по себе многофазное компилирование - есть и используется.
Я о том и говорю. Использовать определения из самой программы на этапе компиляции это сложная алгоритммическая задача
Sr
Это возможно но это не просто.
Aleksei (astynax)
Пристойное компилирование хаскеля - сложная алгоритмическая задача :) И её решают. Хоть и сложная. Но решают.
Aleksei (astynax)
Но считать, что вынос чего-то на этап компиляции, это фу-фу и "не компилятора это дело" - лишать себя кучи возможностей.
Aleksei (astynax)
При этом конечно же никто Фибоначчи числа не считает в compile time (хоть на хаскеле это и сильно проще, чем на многих других языках).
Aleksei (astynax)
Не считают Фибоначчи ещё и потому, что compile time programming на Хаскеле не то чтобы очень удобный. Поэтому и применяется тогда, когда выигрыш большой.
Sr
Ну вот и я о том же)
Sr
Хотя сделать это было бы классно
Anonymous
Всем добрый день, кто нибудь делал когда нибудь парсеры для ответа api сайта? Или может кто помочь советом:)
Alexander
вот, кстати, было бы здорово иметь что-то для статического вычисления. прагму, например
Пиккеринг предлагает подобное сейчас с пруф концептом CC @cblp_su , типа TH но эвалиться оптимизатором будет
Alexander
Это не совсем задача компилятора. Любые такие вычисления можно проделать за рамками компиляции.
constant propagation это задача компилятора, одна из оптимизаций важных
Alexander
но обычно он очень лимитированный
Alexander
в общем Пиккеринг предлагает особый подвид ТН без интроспекции, но который не байткод интерпретатором, а оптимизатором выполняетсы
Alexander
у оптимизатора есть подстановка, переименование из операций
Alexander
splice = вычислить насколько можно, quote - отсановить вычисление
Alexander
там сейчас в гхцдев рассылке обсуждают
Cheese
Всем добрый день, кто нибудь делал когда нибудь парсеры для ответа api сайта? Или может кто помочь советом:)
для API обычно не нужно писать парсер, а просто взять готовый и написать библиотечку
Cheese
парсеры HTTP, JSON, XML уже написаны
Alexander
ну может там binary blob в ответе
Alexander
ктож знает
Cheese
я написал "обычно"
Cheese
правда, это тогда задача для просто парсера, а не парсера ответа API сайта
Cheese
я сильно подозреваю, что нужна библиотека-клиент, а не парсер
Cheese
и вот ещё один спросил и убежал
« Rev
@haskellru   1479
Fwd »