Compile-time reflection in D

[thedeemon]

Хорошее выступление с недавно прошедшей конференции:

Watch on YouTube

Компайл-тайм интроспекция + компайл-тайм кодогенерация = big win. Я правильно понимаю, что в Rust (а также С++, Go, Swift) ничего подобного нет и не предвидится?

Comments

ocaml ftw

[ygrek (from livejournal.com)]

JFYI, в новом камле есть ppx - упрощённый вариант camlp4

Re: ocaml ftw

[thedeemon.livejournal.com]

Я краем уха о нем слышал, но подробностей не знаю. Там доступна информация о типах и их устройстве, или только синтаксические манипуляции с AST?

Re: ocaml ftw

[ygrek (from livejournal.com)]

parsetree -> parsetree, на самом деле упрощённый camlp4 в нужную сторону. Про typedtree -> parsetree думают думу, но пока нет.

[stepancheg.livejournal.com]

К сожалению, не предвидится.

Моё понимание Rust такое: Rust — это язык, в котором в отличие от D и C++ тайпчекинг функции происходит до инстанциации с типовыми параметрами. Условно говоря, вот так можно написать в D, но нельзя написать в Rust:

fn foo<T>(a: T) { a.foo(); }

(в Rust надо обязательно писать T : Foo или что-то такое)

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

И ещё одна проблема Rust в том, что в Rust ещё не сделали, и пока нет планов на compile-time-function-evaluation.

P. S. В Rust сейчас делают плагины к компилятору, но КМК это ошибочное направление деятельности, потому что практически пользоваться этим очень тяжело, нужно знать внутренности компилятора, нужно отдельно компилировать плагин и т. п.

[thedeemon.livejournal.com]

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

[xeno-by.livejournal.com]

Как насчет тайпклассов, чьи инстансы материализируют макросы? И компайл-таймово, и рефлективно.

[stepancheg.livejournal.com]

Ты можешь простым языком сказать?

[some41.livejournal.com]

Можно как в GHC generics: www.haskell .org/haskellwiki/GHC.Generics
В терминах Rust, шаблон становится специальным trait с generic implementation, с методами под разные варианты конструкторов типа. Для каждого instance этого impl компилятор вызывает нужные методы автоматически. Можно и без trait, обычными generic functions. Итерация по полям делается через HOF, которая принимает generic function (или несколько функций/объект с методами на разные варианты конструкторов, если так удобнее). Как и с обычными Rust generics это можно реализовать через run-time dispatch, а можно специализировать все в compile time.

xeno_by, думаю, имел в виду trait, в котором метод реализован через макрос, который компилятор раскрывает для каждого требуемого instance. Т.е. практически C++ template.

[xeno-by.livejournal.com]

Я имел ввиду вот это: http://scalamacros.org/paperstalks/2013-06-13-AppliedMaterialization.pdf. Прошу прощения, пока что занят, поэтому вынужден коротко отвечать. Потом постараюсь написать подробнее.

[some41.livejournal.com]

Это тоже, что я написал в первом параграфе, только в Скале.

[stepancheg.livejournal.com]

Давай я попробую сказать другими словами, что ты описал.

Нужно что-то типа частичной специализации traits. Есть trait Aaa. Есть дефолтная реализация, которая подходит для любого типа. И пользователь, если хочет, может определить для некоторого своего типа реализацию Aaa.

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

Правильно?

[some41.livejournal.com]

Не совсем -- не обязательно, чтобы работало для всех типов. Основная идея в том, что 1) есть trait, для которого компилятор может вывести impl сам, по некоторому шаблону 2) шаблон представлен в виде одного или нескольких generic методов. За счет того, что методы generic, мы получаем типы полей. (В презентации про Скалу по ссылке от xeno_by шаблон сделан макросом, но это просто ручная compile-time специализация.) Эти методы в основном или вызываются рекурсивно для компонент, либо вызывают методы для примитивных типов. Если можно делать частичную специализацию с ручными реализациями, то это получается само собой.

Для примера, если этот trait называется Foo, то видя fn foo<T: Foo>(x: T) компилятор знает, что ему нужен impl Foo для данного типа. Он попробует его сгенерировать. Если получилось -- OK, если нет -- ошибка. В остальном как с обычными traits.

[justy-tylor.livejournal.com]

В качестве замены плюсикам совсем вин. На D и Scala сейчас интереснее всего смотреть в плане развития. Что характерно, у себя решаю ту же проблему, для описания которой авторы D нашли новое применение старому термину race condition. Вывод имён и вывод типов приходится осуществлять сильно out of order, сложно подобрать для этого хорошие правила, но ещё сложнее в таких условиях выдать правильную диагностику на неправильные сорцы.

[sharpc.livejournal.com]

C++ SG7 же

[thedeemon.livejournal.com]

Задумались и собирают proposal'ы? И то хорошо.

[migmit.livejournal.com]

deriving (Data, Typeable) and I don't give a shit.