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

Здравствуйте, Аноним, Вы писали:

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

Интерпретатор всегда делать проще. Просто придется отказаться от сервисов которы предоставляет Н2 в области трансформации и делать рантайм интерпретатора самому.

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

VD>Интерпретатор всегда делать проще. Просто придется отказаться от сервисов которы предоставляет Н2 в области трансформации и делать рантайм интерпретатора самому.

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

Здравствуйте, Аноним, Вы писали:

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

Если скорость выполнения не критична — не слишком сложно. Надо взять компилятор, догнать его до стадии генерации кода и воспользоваться деревом, которое получилось. Конечных операций совсем не много, сделать матч по ним и выполнить каждую не проблема.

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

Z>Не первый раз cлышу это. Почему проще?

Простейшая интерпретация достигается пробеганием по синтактическому дереву кода.

Z>Интерпретатор в лоб делается примерно так же как и компилятор, и там и там генерируем код для выполнения (сейчас все интерпретаторы генерируют байткод).

Генерировать байткод — это уже компиляция.

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

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

если нужен байт-код, то достаточно будет воспользоваться компилятором (compilier as service) и выполнить этот байт-код
(скомпилировать новую сборку в памяти или же на прямую создать байт-код через SRE)

но автору поста это сделать(загрузить байт код) не позволяет политика безопасности — тогда надо именно интерпретировать и без особых оптимизаций:
в простейшем случае это парсер+рефлексия.

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

P>если нужен байт-код, то достаточно будет воспользоваться компилятором (compilier as service) и выполнить этот байт-код
P>(скомпилировать новую сборку в памяти или же на прямую создать байт-код через SRE)

P>но автору поста это сделать(загрузить байт код) не позволяет политика безопасности — тогда надо именно интерпретировать и без особых оптимизаций:
P>в простейшем случае это парсер+рефлексия.

байткод это не обязательно CLR. Но да, если быстродействие не критично — парсер + рефлексия.

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

Z>>Интерпретатор в лоб делается примерно так же как и компилятор, и там и там генерируем код для выполнения (сейчас все интерпретаторы генерируют байткод).

C>Генерировать байткод — это уже компиляция.

Да нету сейчас интерпретаторов без генерации промежуточного байткода.

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

Z>Да нету сейчас интерпретаторов без генерации промежуточного байткода.
ruby?

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

Z>Да нету сейчас интерпретаторов без генерации промежуточного байткода.

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

Интерпретатор с байткодом все равно писать проще, потому что вы полностью контролируете вашу "виртуальную машину", и не нужно выкручиваться для поддержки фич языка, которые сложно выразить в примитивах процессора.

Здравствуйте, Аноним, Вы писали:

Z>>Да нету сейчас интерпретаторов без генерации промежуточного байткода.
А>ruby?

И перл. Оба активно страдают от этого и надеются на паррот или еще что.

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

Z>И перл. Оба активно страдают от этого и надеются на паррот или еще что.
Они динамически типизированные. Им надеяться не на что.

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

C>Интерпретатор с байткодом все равно писать проще, потому что вы полностью контролируете вашу "виртуальную машину", и не нужно выкручиваться для поддержки фич языка, которые сложно выразить в примитивах процессора.

Все равно все приходится выразить в примитивах процессора. Интерпретатор в лоб написать проще, да. Но нормальные интерпретаторы имеют сложность не меньше чем компиляторы. Просто там проблемы другие. Возьмем lua, python или v8 и сравним, например, с D/OCaml/Coffeescript (дада, последний тоже компилятор).

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

Z>Не первый раз cлышу это. Почему проще?

Потому что не нужна сложная стадия типизации и генерации низкоуровневого пушистого кода, ваш КО.

Z> Интерпретатор в лоб делается примерно так же как и компилятор, и там и там генерируем код для выполнения (сейчас все интерпретаторы генерируют байткод).

Интерпретаторы еще обычно динамически типизируется делают. Это резко упрощает рабту.

К тому же не обязательно промежуточный код создавать. Можно и по АСТ интепретировать. Руби так и делает, вроде.
Уж для доморощенного языка это точно приемлемо.

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

Интерпретаторы динамики в разы проще в реализации. Потому их столько и наклепано.

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

C>Простейшая интерпретация достигается пробеганием по синтактическому дереву кода.

И обычно это намного сложнее чем компиляция. Потому как надо заботиться о контексте (переменные, стек вызовов, и т.п.), тогда как при компиляции это все получаем бесплатно.

Здравствуйте, Аноним, Вы писали:

C>>Простейшая интерпретация достигается пробеганием по синтактическому дереву кода.

А> И обычно это намного сложнее чем компиляция. Потому как надо заботиться о контексте (переменные, стек вызовов, и т.п.), тогда как при компиляции это все получаем бесплатно.

Это смотря во что компилировать. Если в код немерла (макросы), то возможно. Если речь идет о генерации IL-а, или не дай Бог, машкодов, то иньтерпретация многократно проще.

Кроме того для интерпретации ДСЛ-я не обязательно писать полный по тьюрингу движок. Достаточно придумать модель, а из ДСЛ-я "заполнить" ее. Написать же интерпретатор по этой модели задача довольно плевая.

Скажем, вместо того чтобы генерировать код парсера, можно сделать интерпретатор его модели (по которой код и генерируется). Это будет в разы проще. Как минимум уже будет плевать на скорость. Ее ведь все равно загубили .

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

Z>>И перл. Оба активно страдают от этого и надеются на паррот или еще что.

Если чуть точнее, то в руби вплоть до 1.8 был чистый интерпретатор с проходом по АСТ, а в 1.9 уже компиляция в байткод и его выполнение. И этой версии не один год уже.

WH>Они динамически типизированные. Им надеяться не на что.

Руби переход на ВМ с байткодом дал все же заметное ускорение. Конечно, до статических нативных языков еще очень далеко, но задача их догонять и не стоит.

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

VD>Это смотря во что компилировать. Если в код немерла (макросы), то возможно. Если речь идет о генерации IL-а, или не дай Бог, машкодов, то иньтерпретация многократно проще.

Генерация IL все еще существенно проще чем интерпретация (по той же причине — не надо заниматься контекстом, все VM сделает сама), IL все еще очень высокоуровневый. Компиляция в нейтив сложна только в двух местах — register scheduling и instruction selection. Если компилировать по тупой схеме (например, все переменные сразу на стеке, а регистры только для специальных случаев), наплевав на оптимизации, то все равно выходит на порядок проще чем интерпретация.

VD>Кроме того для интерпретации ДСЛ-я не обязательно писать полный по тьюрингу движок. Достаточно придумать модель, а из ДСЛ-я "заполнить" ее. Написать же интерпретатор по этой модели задача довольно плевая.

Опять же ровно до того момента, когда для DSL потребуется какой либо сложный контекст. Наличие переменных и функций этот контекст неизбежно предполагает.

VD>Скажем, вместо того чтобы генерировать код парсера, можно сделать интерпретатор его модели (по которой код и генерируется). Это будет в разы проще.

Не. Генерировать код намного проще.

Здравствуйте, Аноним, Вы писали:

А> Не. Генерировать код намного проще.

Ну, мне проще писать интерпретаторы По крайней мере, игрушечный интерпретатор написать проще, чем игрушечный компилятор.

Здравствуйте, Аноним, Вы писали:

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

VD>>Это смотря во что компилировать. Если в код немерла (макросы), то возможно. Если речь идет о генерации IL-а, или не дай Бог, машкодов, то иньтерпретация многократно проще.

А> Генерация IL все еще существенно проще чем интерпретация

Это заблуждение. Попробуй сам и поймешь, что это не так.

А>(по той же причине — не надо заниматься контекстом, все VM сделает сама), IL все еще очень высокоуровневый.

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

А>Компиляция в нейтив сложна только в двух местах — register scheduling и instruction selection.

Она вообще сложна. А качественная компиляция, да еще и под разные платформы — это вообще отдельная наука. В разных GCC бэкэнды составляют основной объем кода.

А>Если компилировать по тупой схеме (например, все переменные сразу на стеке, а регистры только для специальных случаев), наплевав на оптимизации, то все равно выходит на порядок проще чем интерпретация.

Не фига не выходит. Интерпретировать можно прямо сразу. Для компиляции в низкоуровневый язык вроде ассемблера по любому нужно городить огород с преобразованием древесной формы в линейную и т.п.

VD>>Кроме того для интерпретации ДСЛ-я не обязательно писать полный по тьюрингу движок. Достаточно придумать модель, а из ДСЛ-я "заполнить" ее. Написать же интерпретатор по этой модели задача довольно плевая.

А> Опять же ровно до того момента, когда для DSL потребуется какой либо сложный контекст. Наличие переменных и функций этот контекст неизбежно предполагает.

У тебя какой-то пунктик с этим контекстом. Модель полностью определяет весь контекст ДСЛ-я. Если есть модель, то написание ее интерпретатора — это примитивнешая задача. Может стать и так, что будет достаточно просто вызвать метод модели — это и будет интерпретацией.

VD>>Скажем, вместо того чтобы генерировать код парсера, можно сделать интерпретатор его модели (по которой код и генерируется). Это будет в разы проще.

А> Не. Генерировать код намного проще.

Для тех кто этого не делал — да. Займись этим на практике и увидишь, что это отнюдь не просто. Это не просто даже при генерации высокоуровневого языка.

Потом от компилируемого кода все ожидают быстрой работы. А сделать генерацию оптимального кода в разы сложней.

Вот погляди. Это (включая все вложенные подкаталоги и файлы) — код связанный с генерацией кода для парсера. И он еще очень компактен, так как сделан с помощью весьма выскороуровневых средств (квази-цитирования и паттерн-матчинга). Аналогичный код на C# будет раз в 5-10 больше.

А это код модели. Он существенно проще. Можно написать интерпретатор по нему всего лишь добавив по одной функции в каждый тип из этого списка. Объем кода интерпретатора получится в разы меньше. Но и в разы (точнее в десятки раз) понизится скорость работы парсера.