Или что-то такое

Точнее не typeable

А какой там тип для маркера

я без понятия что ты понимаешь под маркером

То, что в Data.Dynamic

и как тебе рантайм выберет функцию для преобразования по “маркеру”, а в компайл-тайме убедится что у тебя такая есть?

TypeRep, во

в компайл тайме кажется никак

Надо написать. Будет киллер-приложение!

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

понадобилось :)

Придется писать

А на хаскеле полторы либы для запуска IO в стиле Cron

этож норм вполне, почти как кварц в жаве.

Норм. Если бы сопровождались и фичи имели.

начинается http://reasonmlhub.com/exploring-reasonml/

для фронтенда Reason, имхо, сойдёт

для фронтенда уже есть Хаскель

реакт бы кто портировал

а то несолидно

а для клиентской стороны Пурскрипт и Эльм. зачем ещё один такой же язык?

вроде уже портировали https://pursuit.purescript.org/packages/purescript-react/5.1.0

пурскрипт не считается

и даже на сабж https://github.com/fpco/ghcjs-react

пурскрипт не считается

пока Хаскель нормально не заработает в браузере, Пурскрипт считается за Хаскель

пока Хаскель нормально не заработает в браузере, Пурскрипт считается за Хаскель

там llvm и wasm обещали вроде

петпроджекты по идее уже можно делать

и даже на сабж https://github.com/fpco/ghcjs-react

спасибо

Пурскрипт не хаскель по очевидным причинам (ибо не ленивый), но лучше ризона, естественно

наш эксперт @A64m_qb0 говорит, что в WAsm не хватает важных для Хаскеля примитивов

да что вы ждёте то от wasm?

там можно просто числа складывать

всё

Нет конечно

наш эксперт @A64m_qb0 говорит, что в WAsm не хватает важных для Хаскеля примитивов

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

Но все почему-то думают что wasm для них специально делали

wasm в первую очередь будет лучше чем js.gz

Пурскрипт не хаскель по очевидным причинам (ибо не ленивый), но лучше ризона, естественно

тайпклассами и синтаксисом?

тайпклассы это счастье

Я думаю медленнее чем буквальное прочтение ghc в браузере воббще нереально сделать даже если постараться. ghcjs это такая видимость решения проблемы, чисто формальная, кому совсем припёрло

да что вы ждёте то от wasm?

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

тайпклассами и синтаксисом?

HKT ж

единственная нормальная реализация ООПшных интерфейсов

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

это, да

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

а где-то есть продвижения в эту сторону?

Есть

Но это всё равно не то чего все ожидают

а где-то есть продвижения в эту сторону?

тут, например https://github.com/WebGHC

мне всетаки кажется, что люди ожидают чтобы было быстрее чем трансляция в js

и эти ожидангия оправдываются

Вы не будете делать интерфейс на нём, это попросту оверкилл. И на этом месте внезапно выясняется что других желаний у людей как-то не наблюдается

Коллеги, поясните один момент. Вот если я делаю stack install snap-loader-static - всё ок, пакет ставится, всё отлично

есть какая нибудь надежда что в этом или следующем году можно общаться с гц-шными объектами?

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

Но если он в .cabal файле - то всё падает, stack init упорно не видит пакет

мне всетаки кажется, что люди ожидают чтобы было быстрее чем трансляция в js

Всё быстрее чем безумная идея затащить весь хаскел в рантайм

где в этом логика?

Вы не будете делать интерфейс на нём, это попросту оверкилл. И на этом месте внезапно выясняется что других желаний у людей как-то не наблюдается

почему сразу оверкилл? Можно будет использовать одни и те же модели данных на фронте и бэке, это удобно

статические проверки api это счастье

а какого то оверхеда по сложности разработки для интерфейсов не будет имо

есть какая нибудь надежда что в этом или следующем году можно общаться с гц-шными объектами?

Я не могу сказать про сроки но концепция gc разрабатывается, но чтобы сразу исключить запросы в духе "мне нужен был от gc %feature_name%" его делают максимально низкоуровневым, набором инструментов чтобы каждый сам себе сделал тот gc который потребуется (если вывезет)

Всё быстрее чем безумная идея затащить весь хаскел в рантайм

не совсем, из-за гхц-ного оптимизатора результат может быть быстрее того, если хаскельный рантайм на яваскрипте не делать но и не оптимизировать нормально (а кто там нормально оптимизирует-то?)

нет

почему сразу оверкилл? Можно будет использовать одни и те же модели данных на фронте и бэке, это удобно

Если у вас нельзя так делать сейчас то это, конечно, весьма грустно

я не про кастомный гц

Если у вас нельзя так делать сейчас то это, конечно, весьма грустно

предлагаешь бэкенд на node.js?

про общение с объектами из хипа

гц-шного

предлагаешь бэкенд на node.js?

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

чтобы хоть какой то здравый язык можно было сделать

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

ну в этом есть своя логика

надо бы подумать об этом

Причём я сейчас не умозрительно рассуждаю, а у нас так и есть

dtdшки трансилруете в код?

Бэкенд и все платформы работают на единой основе. Скала -> js, ObjC, Desktop и ещё что-то, короч все платформы

dtdшки трансилруете в код?

Можно сказать и так

Коллеги, поясните один момент. Вот если я делаю stack install snap-loader-static - всё ок, пакет ставится, всё отлично

stack install не устанавливает пакеты, сторого говоря. Они просто скачиваются, собираются и сохраняются в кэше соответствующего снапшота

вот если "устанавливать" программу, а не билиотеку, то полученный исполняемый файл потом копируется в ~/.local/bin и получается "установка"

В конкретном проекте пакет может не подцепляться потому, например, что пакет отсутствует в снапшоте. Тогда потребудется указание в секции extra-deps в stack.yaml

@ahiddenseeker даёте больше информации - ошибку от stack, строку с зависимостью в .cabal

@astynax спасибо, уже сам разобрался, просто прописал в extra-deps stack.yaml, предварительно сгенерив его через stack init с пропуском пакетов.

?

Бэкенд и все платформы работают на единой основе. Скала -> js, ObjC, Desktop и ещё что-то, короч все платформы

круть. исходники кодогенератора открыты?

круть. исходники кодогенератора открыты?

Пока нет, но рассчитываю скоро выолжить

а как вообще со всем этим IDE дружат?

ну то есть делаете ли что-то чтобы не ломался комплит и инспекции, если да то что, если нет то как жить?

а как вообще со всем этим IDE дружат?

если там валидный исходник, то должно быть всё нормально

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

но это в идеальном мире

если там валидный исходник, то должно быть всё нормально

хм, то есть получается кодогенератор генерирует модель один раз и она кладётся вместе с исходниками? я просто думал типа как в kapt (процессор аннотаций для котлина), там код генерируется сразу в папку билда, то есть он не попадает в git репозиторий и всё такое, что с одной стороны логичнее, с другой стороны требует некоторых телодвижений для того чтобы в IDE не ломались инспекции, комплит и всё такое

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

я всё ещё не уверен что кодогенерация вообще должна быть, в целом это всегда выглядит как некий костыль)

хм, то есть получается кодогенератор генерирует модель один раз и она кладётся вместе с исходниками? я просто думал типа как в kapt (процессор аннотаций для котлина), там код генерируется сразу в папку билда, то есть он не попадает в git репозиторий и всё такое, что с одной стороны логичнее, с другой стороны требует некоторых телодвижений для того чтобы в IDE не ломались инспекции, комплит и всё такое

не, версионировать нагенеренное обязательно. его только мержить нельзя.

> версионировать нагенеренное обязательно зачем, если версионировать исходник (допустим то же описание модели в JSON)?

я всё ещё не уверен что кодогенерация вообще должна быть, в целом это всегда выглядит как некий костыль)

ну в руби генерят код в рантайме, начиная со stdlib. это адочек. все 5 лет, которые я это ворочаю.

ну в руби генерят код в рантайме, начиная со stdlib. это адочек. все 5 лет, которые я это ворочаю.

не, я немного про другое в целом почти все применения кодогенерации которые я встречал выглядят как костыль для обхода ограничений языка (взять хоть тот же Go с его отсутствием дженериков и какими-то приблудами для эмуляции дженериков через собственно кодогенерацию внешними тулзами)

> версионировать нагенеренное обязательно зачем, если версионировать исходник (допустим то же описание модели в JSON)?

затем, чтобы нагенеренное точно соответствовало исходнику и чтобы по исходникам было проще ползать из вебморды гитхаба/bitbucket/gitlab и сторонних инструменты вроде Upsource

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

не, я немного про другое в целом почти все применения кодогенерации которые я встречал выглядят как костыль для обхода ограничений языка (взять хоть тот же Go с его отсутствием дженериков и какими-то приблудами для эмуляции дженериков через собственно кодогенерацию внешними тулзами)

но вот в случаях когда надо разные языки связать альтернатив вроде как нет

но вот в случаях когда надо разные языки связать альтернатив вроде как нет

вот это, да

ну то есть делаете ли что-то чтобы не ломался комплит и инспекции, если да то что, если нет то как жить?

У меня генерируется полное описание типов для flow, типы получаются даже намного подробнее чем хотелось бы)

мне даже интересно стало как это "намного подробнее чем хотелось бы"