Новое сообщение в форум Философия программирования

Форум	Философия программирования
Тема	Как правильно задавать вопросы

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

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

O>>> Я просто пытаюсь понять, как компилятор позволяет определить макру в модуле, и тут же ее использовать, не скомпилировав ее и все, что в модуле было выше в динамический модуль (прошу прощения за тавтологию, тут два разных модуля - исходный файл и модуль в assembly).
WH>>Ты просто пытаешься понять, основываясь на модели лиспа.

O> Лисп не при чем. Я пытаюсь понять, основываясь на идее построения иерархии DSL.

WH>>Но у меня другая модель.
WH>>Не менее мощная просто другая.
WH>>Почитай код моих генераторов парсеров.
WH>>Там в одной сборке описаны функции, которые занимаются переписыванием кусков АСТ.
WH>>И они вызывают друг друга, в том числе рекурсивно.
WH>>Этот подход позволяет сделать все, что ты хочешь. Но немного другим методом.

O> И вот в этом подходе никакой иерархии я не вижу. Хотелось бы, чтобы можно было каждый следующий крошечный DSL писать в терминах предыдущего. Делать по dll на каждый из них просто глупо и неудобно.

O> Причем, абсолютно ничего такого в Nemerle нет, что помешало бы сделать это правильно - например, добавить аттрибут функциям, определяющий, пойдут они в "runtime" модуль или только в "macro module". И последний делать динамическим (это легко средствами Reflection.Emit делается). Получится вся статическая прелесть Nemerle, со всей его раздельной компиляцией, и при этом некий аналог image из Лиспов и Смоллтолков. Ничем за это платить не надо, никаких дополнительных накладных расходов, а вот возможностей это даст невообразимое количество.

O> Не стоит так вот запросто отмахиваться от опыта Лиспа только за то, что там скобочки и он динамический. У него всем остальным еще учиться и учиться.

O>>> Я правильно понимаю, что в { ... } может быть произвольный императивный код?
WH>>Нет. Зачем?

O> На всякий случай. Потому как assert это только малая часть того, что можно (и нужно) делать с типами. Надо не только проверять корректность входных типов (они могут быть и неизвестными, быть привязанными к неотрезолвленной еще переменной), а уметь выводить новые уравнения для вывода типов, как минимум. И делать это только декларативно может оказаться неоправданно сложным.

WH>>assert'ов и еще кое-чего достаточно. На их основе будет построен алгоритм вывода типов.
WH>>А в случае если вывод не удался, будет выдано соответствующее сообщение.

O> Еще одно проблемное место - такие сообщения очень непросто сделать понятными и разумными. Тот же Haskell ругается как портовый грузчик, так что сами разработчики его не всегда понимают. А если тут еще и макры со своей специфичной руганью влезут, то все, тушите свет, приплыли.

WH>>Подход V8 круче. Он может больше вывести. Но всё равно до нормальной статики не дотягивает.

O> Для этого ему приходится делать чуть ли не полноценную абстрактную интерпретацию. С другой стороны, не так уж это и дорого.

O>>> Да и не стоит забывать, что в .NET от RTTI все равно не избавишься, так почему бы им не пользоваться тогда?
WH>>Если его не трогать, то оно почти ничего не просит.
WH>>А если тронуть получишь просадку производительности в десятки раз.

O> Каким образом? Компилятору от RTTI много не надо. Узнать типы, сравнить типы на приводимость, и т.д.

WH>>>>Ну так я и планирую ввести предметно ориентированные системы типов.
O>>> Для чего нужна самая базовая система типов, которая никаких ограничений не накладывает вообще.
WH>>Зачем?

O> Чтобы на нее можно было наложить любую возможную систему типов.

O>>> А есть возражения?
WH>>Есть. Мне не известны компиляторы динамически типизированных языков, которые всегда могут вывести типы. Они все рано или поздно сваливаются в динамическую типизацию.

O> А для таких редких случаев можно опциональную статическую типизацию применять. Главное, чтобы она не была насильственной.

WH>>Он может дать по рукам только когда код будет переписан в язык более низкого уровня.
WH>>Но эти ошибки я считаю ошибками разработчика макроса.

O> А он может дать по рукам за корректный, но нетипизируемый код. И именно этого и хотелось бы избежать.

WH>>Те internal macro error.
WH>>И при обнаружении такой ошибки нужно чинить макрос. А не код, который его использует.

O> В том и фокус, что несовпадение типов далеко не всегда является ошибкой.

O>>> Ну да, конечно же, SSA эквивалентен CPS. Только вот в SSA все намного короче и проще получается.
WH>>Да я не про CPS, а про обычные хвостовые вызовы.

O> Я про общий случай. В общем случае любую лапшу из goto элементарно привести к cps (через ssa).

O>>> И зачем? С goto оптимизировать не надо, оно уже и так оптимально.
WH>>В него переписывать сложнее.

O> Да ну? Что вообще может быть проще чем метки и переходы?

WH>>Особенно если иногда нужны не хвостовые вызовы и передача параметров.

O> Ну, необходимости хорошей оптимизации хвостовых вызовов наличие goto конечно же не отменяет.

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

O> А если у нас и так уже достаточно низкоуровневая семантика? Зачем уровень поднимать?

Теги:

Введите теги разделенные пробелами. Обрамляйте в кавычки словосочетания с пробелами внутри, например: "Visual Studio" .NET

Имя, пароль: Загрузить Нравится наш сайт? Помогите его развитию!
Отключить смайлики Получать ответы по e-mail