Линейно-зависимые, Идрис претендует, но не проверено

если сделают завтипы до конца 90-х продвинут

а можно сначала линейные типы?

если сделают завтипы до конца 90-х продвинут

Да ладно, завтипы это 72'ой

ну первый язык с завтипами-то где-то 97-й

Coq 89'ый

так это пруфасситент а не язык

Возможно, что если будет язык с зависимостью от линейных, это уже 2020-е

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

Потому что AFAIK никто до сих пор не знает, как это сделать

Идрис это тоже пруфасистент так-то, просто с фичами языка

Идрис это тоже пруфасистент так-то, просто с фичами языка

Чот мне кажется ровно наоборот

язык с фичами пруфассистента

Пруф ассистент в нём сбоку припёку через рефлекшон расширения

Чот мне кажется ровно наоборот

Он декларируется наоборот. А по факту из агды (которая декларируется именно как пруфасистент в фичами языка) и то лучше язык получается

Он декларируется наоборот. А по факту из агды (которая декларируется именно как пруфасистент в фичами языка) и то лучше язык получается

Субъективненько

ну агда скорее тоже язык с фичами пруфассистента

ну агда скорее тоже язык с фичами пруфассистента

Ну если агда язык, то и идрис, конечно, язык.

ATS 2 - язык?

то что я считаю первым ЯП с завтипами - Cayenne - точноне пруфассистент, даже без терминейшон чекера

Nurpl почему нет тогда?

да, плохой критерий действительно

А кто-нибудь знает, как в Haskell с model checking? Я находил библиотеки, но они какие-то уж очень proof-of-concept :-/

Downloaded ghc-ncurses6-8.4.3. Installing GHC ... Received ExitFailure 2 when running Raw command: /usr/bin/gmake install Run from: /home/jelf/.stack/programs/x86_64-linux/ghc-ncurses6-8.4.3.temp/ghc-8.4.3/ А где у ней логи спрятаны? (это $ stack build офк)

а хотя я могу просто запустить gmake и он в stodut все что надо напишет

@morozzzko будет жить. Поприветствуем!

Downloaded ghc-ncurses6-8.4.3. Installing GHC ... Received ExitFailure 2 when running Raw command: /usr/bin/gmake install Run from: /home/jelf/.stack/programs/x86_64-linux/ghc-ncurses6-8.4.3.temp/ghc-8.4.3/ А где у ней логи спрятаны? (это $ stack build офк)

.stack-work/logs/

.stack-work/logs/

даже папку не создало :(

~/.stack/global-project/.stack-work/logs/?

даже папку не создало :(

это в проекте или глобально?

это в проекте или глобально?

ни там ни там

да и нет глобального проекта

в общем там добавилась зависимость от tinfo а у меня она внутри soшника ncurses, типичная гентупроблема короче

ни там ни там

так не бывает. если не в проекте, то ~/.stack/global-project/ должен создаваться

оно же ещё на этапе stack setup упало

а, это же не сборка пакета

это (до)сборка ghc

отож!

надо в .stack/programs/x86_64-linux/ghc-ncurses6-8.4.3.temp/ghc-8.4.3/ поискать логи

я там не нашел :(

но не суть

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

если я буду использовать стаковский yml вместо cabal, у меня не будет проблем с публикацией бибилотеки7

нет

там генерируется кабалфайл

если я буду использовать стаковский yml вместо cabal, у меня не будет проблем с публикацией бибилотеки7

А сейчас подходящее время, чтобы сказать, что не надо использовать ни stack, ни hpack?

@ix_designer будет жить. Поприветствуем!

Всем привет! Есть предложение для разработчиков/начинающих стартаперов. Я – senior product дизайнер по enterprise/SaaS/веб/мобилкам (ui/ux). Сейчас нахожусь в активном поиске работы уже несколько месяцев, потому что мне постоянно то компания, то проекты, то оплата не подходит. Но я не могу не заниматься дизайном и простаивать. Я делаю или бесплатно или очень дорого. Поэтому предложение: Готов бесплатно выделять +-8 часов в неделю на разработку вашего продукта, начиная от полного проектирования по бизнес-процессам/идеям и заканчивая hi-fi мокапами. Вы разработчик, который хочет сделать проект для портфолио с крутым дизайном? Пишите мне. Вы стартапер, у которого нет бюджета на хороший дизайн? Пишите мне. С вас какие-то гарантии, что проект будет в продакшене и отсутствие NDA.

А сейчас подходящее время, чтобы сказать, что не надо использовать ни stack, ни hpack?

если речь про nix то не особо, если чисто тезисы против то подходящее

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

Всем привет! Есть предложение для разработчиков/начинающих стартаперов. Я – senior product дизайнер по enterprise/SaaS/веб/мобилкам (ui/ux). Сейчас нахожусь в активном поиске работы уже несколько месяцев, потому что мне постоянно то компания, то проекты, то оплата не подходит. Но я не могу не заниматься дизайном и простаивать. Я делаю или бесплатно или очень дорого. Поэтому предложение: Готов бесплатно выделять +-8 часов в неделю на разработку вашего продукта, начиная от полного проектирования по бизнес-процессам/идеям и заканчивая hi-fi мокапами. Вы разработчик, который хочет сделать проект для портфолио с крутым дизайном? Пишите мне. Вы стартапер, у которого нет бюджета на хороший дизайн? Пишите мне. С вас какие-то гарантии, что проект будет в продакшене и отсутствие NDA.

Haskell?

Haskell?

Не относится?

реклама не про Хаскель — спам

почему же, человек хочет с закорешиться поработать с хаскелистами) хаскель по АПИ, дизайн через апи подключается - профессиональный ктож не хочет

А сейчас подходящее время, чтобы сказать, что не надо использовать ни stack, ни hpack?

что хпак не надо использовать - вполне подходящее, со стеком не все так однозначно

если речь про nix то не особо, если чисто тезисы против то подходящее

Насколько я знаю, @int_index использует cabal + nix, может быть он может рассказать про workflow.

Я про hpack раньше писал уже.

Выскажу не самое популярное мнение, но мне сильно не нравится hpack. Как по мне, он даёт не так много преимуществ, но поддержка со стороны тулинга и дружелюбность экосистемы уменьшается. А точнее по пунктам: 1. Многим нравится поле общих зависимостей (и не только) в hpack, но в cabal-2.2. это уже впилено, и там можно указать в общей станзе любой кусок станзы. 2. Автоматический поиск модуля: добавить модуль — одна строка. Это не так часто происходит, чтобы было слишком неудобно. К тому же, когда есть модули, которые генерируются пакетами вроде proto-lens, то их всё равно надо добавлять в package.yaml явно, без этого не работает, поэтому проблема всё равно полностью не решается. 3. YAML. Я сам лично не люблю этот формат, мне в нём много не нравится. Например, там были проблемы с парсингом версий, когда они у пакетов похожи на число. В одном multi-package проекте мы использовали hpack, и там дублицирование кода уменьшилось благодаря алиасам в yaml. Но полностью дублирование убрать не удалось, потому что yaml не поддерживает конкатенацию списков. Поэтому общие куски зависимостей между пакетами всё равно нельзя вынести в отдельный файл :( Если уж хочется полноценную и программируемую конфигурацию, тогда лучше использовать dhall. 4. Генерация .cabal файла с новым хешом каждый раз. Если над проектом работает несколько людей, то у них постоянно будут конфликты в этом .cabal файле, если он есть на GitHub. А если его нет на GitHub, то людям, у которых не стоит hpack, будет трудней сбилдить проект, надо прилагать больше усилий, чтобы этот cabal файл сгенерить. Да, stack работает, но вокруг одного stack мир не вертится. То есть как по мне, преимущества довольно сомнительные, но есть недостатки, создаётся раскол в сообществе, ухудшается и без того не самый хороший тулинг. Уж лучше все силы, что были потрачены на создание hpack ушли бы в cabal — добавить в exposed-modules какое-нибудь поле типа automatic, и весь hpack был бы не нужен.

А сейчас подходящее время, чтобы сказать, что не надо использовать ни stack, ни hpack?

верно говорит этот человек

Выскажу не самое популярное мнение, но мне сильно не нравится hpack. Как по мне, он даёт не так много преимуществ, но поддержка со стороны тулинга и дружелюбность экосистемы уменьшается. А точнее по пунктам: 1. Многим нравится поле общих зависимостей (и не только) в hpack, но в cabal-2.2. это уже впилено, и там можно указать в общей станзе любой кусок станзы. 2. Автоматический поиск модуля: добавить модуль — одна строка. Это не так часто происходит, чтобы было слишком неудобно. К тому же, когда есть модули, которые генерируются пакетами вроде proto-lens, то их всё равно надо добавлять в package.yaml явно, без этого не работает, поэтому проблема всё равно полностью не решается. 3. YAML. Я сам лично не люблю этот формат, мне в нём много не нравится. Например, там были проблемы с парсингом версий, когда они у пакетов похожи на число. В одном multi-package проекте мы использовали hpack, и там дублицирование кода уменьшилось благодаря алиасам в yaml. Но полностью дублирование убрать не удалось, потому что yaml не поддерживает конкатенацию списков. Поэтому общие куски зависимостей между пакетами всё равно нельзя вынести в отдельный файл :( Если уж хочется полноценную и программируемую конфигурацию, тогда лучше использовать dhall. 4. Генерация .cabal файла с новым хешом каждый раз. Если над проектом работает несколько людей, то у них постоянно будут конфликты в этом .cabal файле, если он есть на GitHub. А если его нет на GitHub, то людям, у которых не стоит hpack, будет трудней сбилдить проект, надо прилагать больше усилий, чтобы этот cabal файл сгенерить. Да, stack работает, но вокруг одного stack мир не вертится. То есть как по мне, преимущества довольно сомнительные, но есть недостатки, создаётся раскол в сообществе, ухудшается и без того не самый хороший тулинг. Уж лучше все силы, что были потрачены на создание hpack ушли бы в cabal — добавить в exposed-modules какое-нибудь поле типа automatic, и весь hpack был бы не нужен.

не убедительно 6)

врочем не важно

я примерно тоже самое писал

в общем у hpack нету ни одного значимого плюса, при очевидных минусах

разве что формат кабала все ещё нигде не специфицирован в виде машиночитаемого документа

ERROR: S client not available

впрочем к yaml я схемы тоже не видел

@mitutee будет жить. Поприветствуем!

Интересует тема реверсивных парсеров, было ди что-то свежее за последние пару лет?

Там где комбинаторы строят парсер и принтер одновременно.

Там где комбинаторы строят парсер и принтер одновременно.

Мы в Kowainik как раз работаем над библиотекой tomland, которая является двусторонним конвертером для формата TOML (парсер и принтер одновременно): * https://github.com/kowainik/tomland Реализация основана на идее Monadic Profunctors (не мы придумали, идея не новая). Пример использования можно посмотреть тут: * https://github.com/kowainik/tomland/blob/master/examples/Playground.hs Буквально на этих выходных я впилил поддержку суммы типов на основе чего-то среднего между изоморфизмов и призм. Окончательный дизайн не до коцаа устаканен, поэтому туториалов пока нет, и документация может быть не самой хорошей. Но мы эту библиотеку используем в продакшене в нескольких проектах уже. А сама идея описана в этом блог посте: * https://blog.poisson.chat/posts/2017-01-01-monadic-profunctors.html

Удачно я попал, спасибо, изучу!

lift2 = lift . lift -- Есть do elem:elems <- lift2 get lift2 $ put elems return elem -- Хочу что то вроде lift2 $ state $ head &&& tail -- Но в первом варианте за счет MonadPlus паттерн-матчинг -- давал mempty для [], а тут очевидно exception Есть какие то способы написать код в стиле второго варианта?

lift2 не нужен, потому что он уже полиморфен

lift2 не нужен, потому что он уже полиморфен

кто полиморфен?

lift

он уже поднимается до нужной монады в стеке

неа

у меня transformers если что

http://hackage.haskell.org/package/transformers-0.5.5.0/docs/Control-Monad-Trans-Class.html

он уже поднимается до нужной монады в стеке

если mtl а не tf

полиморфный lift он как раз из transformers

может я инстансы не подгрузил?

тип посмотри

import Control.Monad.Trans.Class

lift :: Monad m => m a -> t m a

он с предыдущего уровня на следующий поднимает

lift :: (MonadTrans t, Monad m) => m a -> t m a

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

lift2 нужно, все верно

хм, окей, это верно тогда

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

получше работает

иногда

и специализируется почти всегда

и можно много уровней одного типа иметь