Реализация скриптового языка
> реализация должна работать по возможности очень быстро.
Что именно ты хочешь?
Встроенный DSL?
---
...Я работаю антинаучным аферистом...
Что именно ты хочешь?
Встроенный DSL?
---
...Я работаю антинаучным аферистом...
Вроде того. Есть текст, он обрабатывается определенным образом (например бьётся на слова, распознаются числа, имена людей, названия компаний). То есть на текст навешивается всякая доп информация (аннотации). Потом по этим структурам делается проход и по аннотациям строятся более сложые структуры. Например выделилось число 5 и и рядом выделилось "кг", у нас есть правило, которое создаст объект с полями "единица_измерения"="кг" и "значение"="5". Так вот хотелось бы такие правила задавать гибко, а не кодировать на основном языке разработки. Поэтому и недоязык нужен.
может, я не в кассу, но вроде, такие вещи были описаны у Ахо-Сети-Ульмана
Я не знаю, на кого вы рассчитываете, кто будет программировать,
и плохо понимаю уровень создаваемых правил.
Если опираться на "должен быстро выполняться",
я предложил бы Форт, для него можно написать быстрый
и компилятор в достаточно эффективный маш. код.
Если есть серьёзные требования по гибкости, лучше заморочиться
встраиванием какой-нибудь Схемы.
Если нет готовых встраиваемых решений, то по крайней мере
ты сможешь найти кучу литературы и полуготового для твоих нужд кода.
А так, смотри сам.
---
"Верь сводке погоды, но доверяй --- интуиции.
Будь особенно бдителен, когда всё хорошо и нет поводов для тревоги."
и плохо понимаю уровень создаваемых правил.
Если опираться на "должен быстро выполняться",
я предложил бы Форт, для него можно написать быстрый
и компилятор в достаточно эффективный маш. код.
Если есть серьёзные требования по гибкости, лучше заморочиться
встраиванием какой-нибудь Схемы.
Если нет готовых встраиваемых решений, то по крайней мере
ты сможешь найти кучу литературы и полуготового для твоих нужд кода.
А так, смотри сам.
---
"Верь сводке погоды, но доверяй --- интуиции.
Будь особенно бдителен, когда всё хорошо и нет поводов для тревоги."
Это "книга с драконом" что-ли? Листаю сейчас её. Вроде не оно. Мне бы что-нибудь именно по безтиповым скриптовым языкам, наподобие JavaScript.
На память приходят всякие S-lang, TCL.
---
"Верь сводке погоды, но доверяй --- интуиции.
Будь особенно бдителен, когда всё хорошо и нет поводов для тревоги."
---
"Верь сводке погоды, но доверяй --- интуиции.
Будь особенно бдителен, когда всё хорошо и нет поводов для тревоги."
Берёшь Parrot VM и пишешь транслятор своего языка в байт-код Parrot.
Я в курсе про то что есть готовые встраиваемые языки. Уже решено , что язык будет свой, с этим ничего не поделать. Замутить интерпритатор с использованием местных аналогов lex/yacc несложно. Но скорее всего его придется ускорять потом. В идеале скрипт должен работать не сильно медленнее, чем аналогичный скомпилированный явский код (да, мы любим кофе).
Спасибо, конечно, тогда уж в байткод JVM транслятор напишем. 
Как насчёт BeanShell?
www.beanshell.org
www.beanshell.org
Да, я видел биншелл.
Уже решено , что язык будет свой, с этим ничего не поделать.
В идеале скрипт должен работать не сильно медленнее, чем аналогичный скомпилированный явский код (да, мы любим кофе).Как же интерпретатор будет работать "не сильно медленнее", чем скомпилированный код? JIT'ы вполне неплохо в машинный код компилируют, и даже с оптимизацией. При интерпретации будет медленее работать раз в 5-10 минимум, если не в 20.
Да понимаю я это. Имелось в виду, что надо максимум выжать из этого дела.
> (да, мы любим кофе).
Тогда пишите кодогенератор для JVM.
С ней я не разбирался, но для реального процессора STC с частичным inline делается легко.
Можно заморочиться и на простейшую оптимизацию, если делать больше нечего.
---
...Я работаю антинаучным аферистом...
Тогда пишите кодогенератор для JVM.
С ней я не разбирался, но для реального процессора STC с частичным inline делается легко.
Можно заморочиться и на простейшую оптимизацию, если делать больше нечего.
---
...Я работаю антинаучным аферистом...
Да это я понял. Но у биншелла наверно открытый исходый код. А если нет в биншелле, то уж точно есть в Эклипсе. Если тебе нужна такая сложность.
Тут была ссылка на презентацию "DSL за один присест на camlp4", как раз делался упор на производительность.
Если вы хотите выжать из этого дела максимум, то тем более не стоит писать свой язык. Я более чем уверен, что своё вот так сразу получится медленнее во всех смыслах этого слова: дольше по времени разработки и хуже по производительности.
А зачем в байткод?
Преобразуйте прямо в жаву, тогда жавокомпилятор ещё чего-нибудь соптимизит нахаляву.
Преобразуйте прямо в жаву, тогда жавокомпилятор ещё чего-нибудь соптимизит нахаляву.
Да, была такая мысль. Попробуем, м. б.
Если упор на производительность, лучше не интерпретатор писать, а кодогенератор. Ну то есть компилятор в какой-то популярный язык = имеющий хорошо оптимизирующий компилятор.
а почему не взять готовый python?
он к яве хорошо прикручивается.
а интерфейстных, специализированных классов нафигачить не проблема.
он к яве хорошо прикручивается.
а интерфейстных, специализированных классов нафигачить не проблема.
>а почему не взять готовый python?
"проблема в том, что реализация должна работать по возможности очень быстро."
"проблема в том, что реализация должна работать по возможности очень быстро."
Например выделилось число 5 и и рядом выделилось "кг", у нас есть правило, которое создаст объект с полями "единица_измерения"="кг" и "значение"="5". Так вот хотелось бы такие правила задавать гибко, а не кодировать на основном языке разработки. Поэтому и недоязык нужен.т.е. на Java даже операции с килограммами не удобно записывать?
Оставить комментарий
psm-home
Посоветуйте книги/статьи по сабжу. Возникла потребность реализовать некий специализированный язычок . Как это делается вообще, я знаю. Но проблема в том, что реализация должна работать по возможности очень быстро. Соответственно интересуют всякие неочевидные сходу хитрости, которыми можно поднять скорость выполнения.