Вдруг будет в скале рассвет всяких линтеров, как в жс

Вдруг будет в скале рассвет всяких линтеров, как в жс

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

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

Но не все

Можно кастомные штуки какие-нибудь делать

Можно кастомные штуки какие-нибудь делать

плагином к компилятору

если в скале будет "рассвет линтеров", то это невероятный фейл так называемой "сильной" системы типов ведь если линтеры (отделенные от компилятора) все равно есть везде, то зачем эти понты с типами?

плагином к компилятору

Можно и плагином. Но тогда ты будешь завязан на кишки компилятора (а их ещё и изучить надо, что в целом нетривиальная задача). С semanticdb можно сделать тулзу, которая не зависит от внутренней реализации компилятора, и может работать как со скалой, так и с дотти. В этом собственно одна из ее целей

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

транспайлеры на этом не сделать?

транспайлеры на этом не сделать?

Откуда куда?

из скалки в нечто прочее

если в скале будет "рассвет линтеров", то это невероятный фейл так называемой "сильной" системы типов ведь если линтеры (отделенные от компилятора) все равно есть везде, то зачем эти понты с типами?

https://ru.wikipedia.org/wiki/Lint

из скалки в нечто прочее

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

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

https://ru.wikipedia.org/wiki/Lint

ага, я именно о анализирует статический исходный код

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

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

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

ну или как вариант иметь единое представление, в которое можно конвертить другие япы и из которого можно конвертить другие яп. такой вариант flume или kafka-connector для кода

ага, я именно о анализирует статический исходный код

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

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

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

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

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

это коммерческая хотелка, которая к компилятору как раз никакого отношения иметь не должна) (максимум как плагин к компилятору, но проще и нагляднее как линтер)

ну или как вариант иметь единое представление, в которое можно конвертить другие япы и из которого можно конвертить другие яп. такой вариант flume или kafka-connector для кода

Tasty. Только по последней инфе от Бурмако, судьба tasty туманна

это коммерческая хотелка, которая к компилятору как раз никакого отношения иметь не должна) (максимум как плагин к компилятору, но проще и нагляднее как линтер)

но ряд таких кейсов (например, игнор не-Unit значений) можно флагами зафигачить

или я не понял, о каком именно уровне мозговитости линтеров идет речь :)

ну или как вариант иметь единое представление, в которое можно конвертить другие япы и из которого можно конвертить другие яп. такой вариант flume или kafka-connector для кода

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

Нада Амин вроде пилила транспайлер в си но подозреваю сейчас заброшено

@odomontois ты там в скаламете вопрос задал, можешь пояснить какую строчку ты в итоге хочешь получить? может тебе и не нужен стор.кол)

@odomontois ты там в скаламете вопрос задал, можешь пояснить какую строчку ты в итоге хочешь получить? может тебе и не нужен стор.кол)

object XXX extends ..parents with Enum[XXX]{ ... }

object XXX extends ..parents with Enum[XXX]{ ... }

и тут в парентах ты хочешь стор.кол воткнуть?

Type.Apply

мне нужно к уже имеющимся парентам добавить Enum[XXX]

ты там что-то копаешь, или можно не ждать ответа?

ты там что-то копаешь, или можно не ждать ответа?

да. сейчас гляну

Term.ApplyType(Ctor.Ref.Name("Enum"), Seq(Type.Name("A")) говорит парс

Term.ApplyType(Ctor.Ref.Name("Enum"), Seq(Type.Name("A")) говорит парс

ну да. так и должно вроде быть. т.е. нашел решение?

ну копаюсь пока, но возможно

ну копаюсь пока, но возможно

не забывай про https://astexplorer.net/ неплохо помогает. просто пишешь конечный вариант который хочешь получить и потом по кирпичикам у себя собираешь

Пока сложно понять, как он может быть полезен

Проще квазиквотами

оно как раз и показывает все что должно в конце получится по аст

а аст уже строишь как хочешь - хочешь эксплисит, хочешь квазиквотами

так вроде же можно и без этого распарсить

q"object xxxx extends enumeratum.Enum[A]".structure

q"object xxxx extends enumeratum.Enum[A]".structure

можно. но мне деревом больше нравится смотреть. в сложной конструкции можно только небольшую часть глянуть - сразу вычленяется.

Tasty. Только по последней инфе от Бурмако, судьба tasty туманна

а что говорят?

а что говорят?

Послушай подкаст с Бурмако

это которому уже несколько месяцев?

Да

в двух словах можешь резюмировать?

в двух словах можешь резюмировать?

Судьба tasty туманна

почему? :)

Судьба tasty туманна

вроде как не особо туманна — tasty как таковой все, а наследником является semanticdb

почему? :)

Я не помню уже, слушай подкаст :)

ясно спасибо

А как вы дебагаете вашу мету?

А как вы дебагаете вашу мету?

println

println

println где?

println где?

внутри meta {}. если оно не скомпилируется - ты и так узнаешь. а если скомпилируется то во время раскрытия мета аннотации все принтлн внутри мета{} уйдут в messages

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

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

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

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

не компилится результат

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

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

Да, кнопка не работает

Страшные ошибки пишет

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

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

Не вижу

Какими ручками?

У меня sbt всё компилит

Это считается ручками?

Это считается ручками?

нет. но в сбт тоже бывает подклинивает и надо явно клин для макроса сделать. ну и напомню на всякий, что мета макрос должен быть в отдельном (под-)-проекте

В идее это всё ещё так себе работает

тогда что такое ручками?

TDD реально спасает

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

всё билдится в sbt

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

clean compile сделать?

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

Если все норм, то идея и без этого сработает

lazy val macro-project = project lazy val target-project = project macro-project/clean target-project/compile

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

Если все норм, то идея и без этого сработает

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

В общем, пока что отлажиываю только через ручное применение

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

для чего?

для чего?

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

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

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

принтлн - наше все

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

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

где же оно успешно, если экспаншн фейлд?

Оно на самом деле успешно

sbt даже скомпилил уже

а до этого выдавал ошибки в сгенерированном коде

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

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

с этим уже ничего не сделать

Ну т.е. отлаживать только запуская эту трансформацию на распарсенном вручную коде