Толочь воду в ступе

[swizard]

Пост навеян свежим ПФП. Статья про circumflex, вот этим вот:

// Выбрать все города Швейцарии, вернуть Seq[City]:
SELECT (ci.*) FROM (ci JOIN co) WHERE (co.code LIKE ”ch”)
ORDER_BY (ci.name ASC) listСтоило ли огород городить, если на выходе всё равно получается нечто, что

Comments

[nivanych]

> С динамикой так не выйдет -
> здесь надо забуриваться глубоко в кодогенератор/рантайм.

Гм. Мне так кажется, что надо совершенствовать вывод типов и компилировать в какое-нибудь GRIN-подобное.
Ну можно и попроще backend.
Сам я не делал вывод типов для динамики, но по словам "очевидцев" (тех, кто пробовал), даже минимально получившийся вывод уже очень неплохо работает. И скажем, обогнать даже современный GHC не так и сложно (у него там других проблем при оптимизации навалом).
То есть, упрощённо - делается любой примитивный вывод типов, и он уже неплохо работает.
Самому время тратить и проверять совершенно неохота, да и нет оснований не доверять тому товарищу.
Это не так?

>> А придумать хорошую систему типов всегда сложно
> А зачем придумывать?

Затем, что для данной задачи существующие чем-то не устраивают и надо их обработать напильником, специализировать, чтобы устраивали. Но обычно DSL'и, конечно, очень примитивные и таких раздумий не требуют.
Например, делаю я DSL для всякого IO и даже распределённого.
Но я не беру уже существующие всякие \pi, у меня своя идея (семантика пучков).
Под эту идею надо свою логику, то есть, свою систему типов.
В зависимых типах оно нормально описывается, в хаскеле уже надо Template Haskell либо воротить в динамике.

>> И не настолько уж сильно бОльшие сложности,
>> по кравнению с классическим выводом типов.
> А какие сложности с классическим выводом типов?

Никаких, конечно.
Это давно и хорошо изученная тема с кучей готовых исходников.
Собственно, и в выводе типов для динамики сложностей немногим больше, что и хотел сказать.
Где-то, наверное, одинаковая сложность вывода типов для динамики и зависимых типов.

> фулл тайп инференс вообще не нужен.

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

> При помощи лиспо-макросов можно реализовать
> любую статику в виде компайл-тайм чекера

Может быть, я и не прав.
Как во время компиляции отличить в конкретном листочке, скажем, плавучку от целого?
Тип, определённый по написанию, уже много, на что влияет дальше. Это неявное определение типа.
Впрочем, это только маленький практический момент.