?

Log in

No account? Create an account

Зачем нужны имплисит макросы? - Excelsior — LiveJournal

May. 7th, 2013

11:06 pm - Зачем нужны имплисит макросы?

Previous Entry Share Next Entry

Comments:

[User Picture]
From:akuklev
Date:May 8th, 2013 12:08 pm (UTC)
(Link)
Type families (на самом деле, конечно, inductuve types) это из другой оперы, на самом деле. Соотносится с тайпмакросами точно так же, как Scala Virtualized с обычными макросами. Есть небольшое пересечение в области применимости того и другого, например те самые Tuple(n) vs. Vec(n) = List фиксированного размера. Inductive Types не хватает и никогда не хватит для syntactic sugar stuff вроде tableProduct и typeProvider'ов, которые генерят из внешних источников.
(Reply) (Parent) (Thread)
[User Picture]
From:xeno_by
Date:May 8th, 2013 12:12 pm (UTC)
(Link)
Если включить -XUndecidableInstances, то, насколько я понимаю, type families становятся очень даже ничего по мощности. Насчет того, чтобы генерировать что-то из внешних источников, тоже можно будет обсуждать. Сейчас решается более глобальный вопрос о дальнейшей судьбе макросов в Скале, потом станет понятнее насчет частностей вроде вычислений на типах.

Edited at 2013-05-08 12:12 pm (UTC)
(Reply) (Parent) (Thread)
[User Picture]
From:akuklev
Date:May 8th, 2013 12:34 pm (UTC)
(Link)
Проблема с type families, как я уже сказал, в том, что работать с конкретными именами (а не абстрактными идентификаторами) невозможно. Они по построению супергигиеничные, а для хорошего синтаксического сахара этого недостаточно.
(Reply) (Parent) (Thread)
[User Picture]
From:xeno_by
Date:May 9th, 2013 08:29 am (UTC)
(Link)
Можешь, пожалуйста, привести пример?
(Reply) (Parent) (Thread)
[User Picture]
From:akuklev
Date:May 9th, 2013 08:36 am (UTC)
(Link)
Тайпмакрос для создания именованного произведения, который я привёл выше.
(Reply) (Parent) (Thread)
[User Picture]
From:xeno_by
Date:May 9th, 2013 08:39 am (UTC)
(Link)
Т.е. ты хочешь взять два типа на входе и на выходе выдать ссылку на сгенерированный на основе этих типов класс?
(Reply) (Parent) (Thread)
[User Picture]
From:akuklev
Date:May 9th, 2013 09:15 am (UTC)
(Link)
Ну смотри, когда мы в SQLе делаем запрос из двух или более таблиц (или их джоина), нам именно это и нужно делать. Классический пример — есть таблица phones с полями name: String и phone: String и addresses с полями name: String и address: String. Мы делаем запрос
select * from phones, addresses where phones.name == addresses.name.

Что транслируется как (phones tableProduct addresses) filter {_.phones.name == _.addresses.name}.

tableProduct не только сам по себе макрос (потому что считывает не только значения своих аргументов, но и их имена), но и типизируется только макротипом, у которого поля называются как аргументы tableProduct.
(Reply) (Parent) (Thread)
[User Picture]
From:akuklev
Date:May 9th, 2013 09:26 am (UTC)
(Link)
Мне кажется, у тайппровайдеров и индуктивных типов всё-тки совсем разные области применения. Если макротипы ограничить до тайппровайдеров*, то с индуктивными типами они полностью перестанут пересекаться.

Тогда и разница между туплом и вектором понятна: одно зависимо от рантайм-значения, другое чисто от компайл-тайм.

* т.е. запретить возвращаемым типам зависить от рантайм значений.

Upd: можно оставить зависимость в смысле PDT, пересечений с ITF всё ещё не будет.

Edited at 2013-05-09 09:33 am (UTC)
(Reply) (Parent) (Thread)
[User Picture]
From:akuklev
Date:May 9th, 2013 09:43 am (UTC)
(Link)
А вот например такое уже даёт Clash с ITF:

(pseudocode)
type Wrap(x) = {val v = x}
(Reply) (Parent) (Thread)