Здравствуйте, VladD2, Вы писали:

EP>>Какие гигабайты выхлопа?
VD>Обычные. В выхлопных каталогах. Там формирвется море промежуточного говна. Мы в этот вопрос еще лет 10 назад разбирали.

Вот именно, слышал звон и не знаешь где он. Ты со Spirit небось перепутал.
Metaparse парсит строки в compile-time, результатом является compile-time значение/тип и никакого лишнего кода в объектных файлах. Можешь сам убедится — скопируй код примера калькулятора в coliru и посмотри что в .o файлах.

VD>Это делается страшными побочным эффектами. А в промежутке там формируются тонны шаблонных классов, которые порождают гигабайты временных файлов даже на примитвной грамматике, а компиляция идет неприлично долго.

Те ужасы о которых ты говоришь были лет десять назад, пока ещё не было variadic и constexpr.

EP>>Ну я уже выше привёл пример — там for — он по строке, и в compile-time.
VD>Это слишком простой пример. Он не показывает достижим ли результат. Нужно чтобы на вход было нечто вроде:
VD>...
VD>Ну, то есть, чтобы код содержал разбор грамматики и построение по ней некоторого, заранее не определенного, кода зависящего от этой грамматики.

Ну видимо ты опять переводишь тему к задачам решаемым Spirit'ом — ну да, теперь его можно расширить и задавать грамматику в compile-time — только как это к примеру ТС относится?

EP>>В какой строке? Ты о чём? Metaparse пораждает парсеры compile-time строк, а не его граматика задаётся в compile-time строке, хотя если нужно, можно и граматику в строке задать
VD>В строке переданной в качестве параметра. Пример я выше привел.

Ещё раз, Metaparse позволяет создавать compile-time парсеры, которые обрабатывают compile-time строки.
Откуда взялось требование что грамматика должна задаваться строкой? (да, это возможно, но что ты пытаешься конкретно показать?)

EP>>Кому должна?
VD>Программисту. Вот макры так могут за милую душу. При этом код их реализации простой и эффективный. В результате порождается только код парсера, без гигабайт промежуточных классов, которые еще должен переварить оптимизатор.

Возьми пример калькулятора Metaprase, отключи оптимизацию -O0, сгенерируй объектник -c и посмотри на размер main.o, нет там никаких гигабайтов, как и нет никакого побочного кода.

VD>Я хочу иметь грамматические правила вроде:
VD>

VD>| Add        = Expr sm '+' sm Expr 
VD>

VD>а не вот этотот вот говнокод:
VD>

VD>typedef
VD>  foldl_reject_incomplete_start_with_parser<
VD>    sequence<one_of<plus_token, minus_token>, prod_exp>,
VD>    prod_exp,
VD>    eval_plus
VD>  >
VD>  plus_exp;
VD>

В коде metarpse задаётся семантическое действие, а у тебя и этого нет

EP>>>>Ну в примере TS выше, как я понял — вся база данных, включая все данные, задаётся в compile-time, что действительно не очень-то и нужно — так как если все данные уже есть в compile-time, к ним доступ через sql, да ещё и в compile-time не особо-то нужен.
EP>>>>А вот приспособить это для типизированного доступа к БД а-ля SQL-macros — должно быть вполне реализуемо.
VD>>>Вот обычно на этом и начинаются трудности, так как системы типов не особо приспособлены для доступа к внешним источникам данных. Для макры это не проблема, так она не не более чем программа запускаемая во время компиляции. А для приседания на типах — проблема.
EP>>Речь не идёт о хождении в базу compile-time, речь идёт о генерации о проверки запросов compile-time, которые ходят в базу в runtime. Как linq2db, только, только без runtime-оверхеда.
VD>Так нет никаких проверок в компалйтайм. И базы нет. Есть самопальная БД на типах и хождение к ней. Ты хотя бы в коде разобрался бы. Нам на входе списки описанные на типах, а на выходе типы описывающие списки. Чистый сфероконо, который не применим на практике. Там в типах обрабатываются данные.

Ты читать видимо не умеешь, или контекст не удерживаешь, так как я выше тебе уже выше объяснил что именно делает пример ТС.
А типобезопасный доступ к БД — это как пример где это могло бы реально быть применимо. Забавно что в следующем

Автор: VladD2
Дата: 27.10.20

своём сообщении ты ровно это и предлагаешь

EP>>>>Ну в примере TS выше, как я понял — вся база данных, включая все данные, задаётся в compile-time, что действительно не очень-то и нужно — так как если все данные уже есть в compile-time, к ним доступ через sql, да ещё и в compile-time не особо-то нужен.
EP>>>>А вот приспособить это для типизированного доступа к БД а-ля SQL-macros — должно быть вполне реализуемо.

EP>>Первое — давно возможно. Доступ к строкам в compile-time есть, полный по-тьюрингу язык для их обработки тоже есть, причём не один.
VD>Ну, значит покажи примитивный пример (я не прошу полный парсер-генератор), который бы разобрал строку и построил по ней функцию разбирающую грамматику в этой строке.

Я не пойму откуда взялось требование о том что грамматика должна задаваться строкой.
Разбор compile-time строк ты уже увидел. О тьюринг полноте шаблонов ты знаешь. О тьюринг-полноте constexpr функий можешь загуглить в один клик. Что конкретно интересует-то?

EP>>Второе — нет, так как нет API для доступа к DB, чтению файлов и т.п. Но для таких редких use-case'ов внешнюю кодогенерацию не в лом использовать. Ну то есть например нормальный макросы — да, хотелось бы. Доступ к DB в compile-time — не особо
VD>Ага. Это как в классическом: Не дает, ну и не очень то и хотелось! (ц)
VD>Нормальные макры тупо не имеют таких ограничений. Это просто код — плагин к компилятору, который может читать любые данные (включая код проекта) и порождать новый. При этом у него нет проблем прочитать и метаданные из внешней БД, например.
VD>Вот представь себе, что вместо:
VD>...
VD>expr — это твой литерал. Вот это и есть макрос о котором я говорю. В другом макросе в строке может быть передан URI БД. И мы просто сходим туда во время компиляции и прочтем от туда метаданные, по которым скомпилируем функции доступа к ней.

Макросы в Лиспе использую постоянно. Нормальные макросы в C++ очень хотелось бы, да. Даже хотелось бы макросов в Python'е, именно поэтому смотрю на Hylang.
Доступ к БД во время компиляции — как-то без энтузиазма — конкретно для этой задачи не в лом добавить правило кодогенерации в систему сборки Причём если ходить в базу из макросов, то всё равно придётся информировать систему сборки о том что результат компиляции вот этого TU зависит не только от кода
Твои многочасовые презентации по Nemerle я смотрел — представляю как он работает, знаю что умеет, многим впечатлён Убеждать меня в его преимуществах не нужно, я уже убеждён.
По моему мнению вы промахнулись с целевой платформой и аудиторией. Вот если бы вместо .NET вы генерировали C++, или даже C (как Страуструп когда-то), то получили бы охват всех платформ, и целевую аудиторию которой не в лом создавать и использовать штуки типа Spirit, MetaParse, Hana и т.п., несмотря на все трудности сопряжённые с этим.