мб. под одну конкретую либу. http://hackage.haskell.org/package/language-java вот что нашёл генерировать скорей всего буду жёстко в строки. без написания либы под котлиновый AST

ну тип не конвертация кода. а просто оборачивание например в джаве делают гетер/сетер, в котлине есть проперти (ну хотя котлин такое умеет имплиситно делать, но это как пример)

а

вот такое в скале точно не помешало бы

к слову fpconf попросили архитектурную штуку, а не inline-X иначе бы я про это говорил на fpconf

там тип есть что рассказать? (без иронии, на самом деле не представляю объём работы)

в inline-java кстати уже есть чего интересного. Ну и вообще такой подход к разработке и интеграции с чужими экосистемами

даже в inline-c которая из этих библиотек самая простая было бы что рассказать

который раст из сишки делает?

corrode

все время обсуждения ленгвидж-прагм и как хорошо, что в идрисе их нету я чувствовал, что что-то не то, но не мог вспомнить. Но теперь-то вспомнил. В идрисе же точно такая же система ленгвидж-прагм для расширений https://github.com/idris-lang/Idris-dev/blob/master/libs/prelude/Builtins.idr#L5

это не в счет

это не диалекты

может кто разъяснить?

фандепы для меня сложны чет

выглядит как какая-то магия

типа "в этой B точно есть где-то тип A, так что можно вывести B, зная A"

а как это работает хз

a -> b значит, что a определяет b

ну самая простая интуиция, наверное, это что-то вроде ассоциированных типов. Т.е. у нас есть MPTC и мы делаем что-то вроде Array IntArray Int раз для интаррея элемент всегда инт - мы можем улучшить вывод типов донеся это знание до компилятора

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

https://github.com/mmirman/ImperativeHaskell/blob/master/Main.hs с той же поисковой страницы нашёл императивный хаскель наверное хорошо сочитается с инлайн джавой

https://github.com/vincenthz/language-java/blob/master/Language/Java/Syntax.hs можно как-нибудь снаружи подключить линзы чтобы они нагенерили classTypeDecl . classDecl . ident . name

хотя там всё равно по кейзам придётся проходится. но вопрос всё равно интересен

это не в счет

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

в ghc в общем-то тоже не язык из кубиков, а фичи не включенные в древний стандарт

не понимаю как %total это экспериментальная фича

подскажите, пожалуйста, * либу для линейной алгебры с претензией на скорость (blas под капотом), здесь https://wiki.haskell.org/Libraries_and_tools/Mathematics#Linear_algebra целая россыпь, помимо этого в гугле еще либа Кметта попадалась. Спрашиваю, потому что актуальность, полноту и удобство каждой рассматривать самостоятельно может много времени потребовать. По функциональности хочется хотя бы многомерных матриц, вычисление обратной. * тот же вопрос по работе с изображениями.

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

Linear точно не про скорость

есть hmatrix

из того что Блас под капотом

ещё у FPC что-то было

FPC?

попытка вгуглить FPC

fp complete

не могу найти что-то репозиори

Из работающего только hmatrix

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

а про работу с изображениями знаете что-нибудь подходящее?

JuicyPixels? Сам не пробовал, но вроде хвалят

спасибо

не понимаю как %total это экспериментальная фича

я про %language, который действительно меняет язык (синтаксис и семантику). %access %default просто задают модификаторы по умолчанию, т.е. действуют в рамках существующего синтаксиса и семантики, т.е. не меняют язык, поэтому они таки не в счет. им можно было дать какую-нибудь другую нотацию, чтобы не пугать людей прагмами.

а про работу с изображениями знаете что-нибудь подходящее?

hip

я про %language, который действительно меняет язык (синтаксис и семантику). %access %default просто задают модификаторы по умолчанию, т.е. действуют в рамках существующего синтаксиса и семантики, т.е. не меняют язык, поэтому они таки не в счет. им можно было дать какую-нибудь другую нотацию, чтобы не пугать людей прагмами.

так он говорит не про аксесс, а про %total которая родственник "диалектов" вроде UndecidableInstances

тут разница в том, что можно всю жизнь пользоваться Идрисом и его библиотеками и ни разу не использовать %language самому и не увидеть его в библиотеке. и это нормально.

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

total без процента это штатный модификатор. в Идрисе система типов различает тотальные функции и нетотальные, они прекрасно сосуществуют.

ну так что? если UndecidableInstances "диалект" - то и это диалект

настоящая прагма одна - %language. для штатного пользования языком она не нужна, а только для попыток потрогать еще не реализованные фичи. остальное просто модификаторы, существующие в рамках языка.

причем тут UndecidableInstances?

она отключает проверки завершимости тайпчекера

настоящая прагма одна - %language. для штатного пользования языком она не нужна, а только для попыток потрогать еще не реализованные фичи. остальное просто модификаторы, существующие в рамках языка.

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

не совсем. проверки остаются на месте. просто в Идрисе два стрелочных типа - один тотальный, другой нетотальный, с боттомом. но отдельного синтаксиса для них не придумали (вроде -> `=>`), а сделали модификатор total. это часть единой системы типов. а что такой UndecidableInstances, Вы мне лучше сами объясните. имхо, это костыль.

Это отключение проверки завершимости для вывода инстансов. Безобиднейшая вещь.

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

лучшее определение костыля, конечно

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

hip

спасибо

костыль это быстрое неканоническое решение проблемы, ухудшающее maintenability продукта

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

или map через мутабельный список внутри спрятанный от пользователя это костыль

этим eager языки увлекаются

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

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

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

если делать это опциями компилятора, то будут в заголовке {-# OPTIONS_GHC -XAllowAmbigousTypes, #-} что тоже самое, но в профиль

а если опасное запретить, поломается код..

да даже если только безопасные сделать через --language=Haskell2020

вот будет там MagicHash какой

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

они увидят и убегут сразу

а новички это важно

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

А какие волшебные ошибки случаются с PolyKinds

На смотришь и думаешь: чаво?

ну и Haskell развивается благодаря исследованиям

если цена новой фичи + одно расширение и через полгода ты можешь пользоваться то это одно

а если надо собрать совет магов^W^W комитет и ждать 5 лет, то это другое

впрочем совет магов бы эффективнее был

Магов нету, вот в чём беда

беда в том, что при этом они эффективнее