Вот в результате работы над некими проектами получлся scripting engine.
Подумалось что может быть полезным кому-то еще.

http://terrainformatica.com/tiscript/

Основная идея engine — простота интегрируемости в чистый C/C++.
API это 10 plain C функций плюс обертка для C++.
Т.е. предпринята попытка сделать practical script engine — всего одна DLL и никаких внешних зависимостей.

Сам язык близок к JavaScript "as much as possible"

JavaScript фичи которые попали под нож:

1) упрощена вся эта скажем прямо ахинея вокруг prototype, __proto__ и иже с ними.
Классы и наследование стало прозрчнее и очевиднее. См. http://terrainformatica.com/tiscript/Syntax.whtm#classes

2) класс Number разделен на два — Integer и Float.

Все остальное в принципе должно быть близко к JavaScript. Во всяком случае есть такое намерение.
Это то что касается языка.

Что нового:

1) Появились потоки ввода вывода. File and socket Stream. Соответственно в скрипте определены stdin, stdout, stderr. Ну и printf и всякие штуки типа stdout << "Hi, world!";
Хост-приложение само определеяет что есть эти самые stdin, stdout, stderr.

2) Добавлен режим работы PHP — hypertext preprocessor — скрипты включаются в текст с пом. <% script %>. Примеры в SDK.

3) Компиляция в байткод и загрузка оного. Внутри движка — compiler, VM и copying GC.

4) Persistence. Binary и textual. Textual это когда данные предсталяют собой поток статических инициализаторв самого скрипта и загружаются с помощью eval. Textual имеет смысл для всякого рода config. Примеры в SDK/scripts/persistence/*.js

Ну вот примерно и все пока.

Философический вопрос вынесен в subject.

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

CS>Философический вопрос вынесен в subject.

А чем не устраивают существующие скриптовые языки, которые можно эмдеддить в исходники на С?
К примеру, в Цивилизации 4 вся логика AI, распределение ресурсов и т.п. будет реализована на Python (описание карт и т.п. — в XML)...

Велосипед — это интересно и познавательно, для саморазвития — опять же — ценно, но когда время ограничено, проще заюзать что-то проверенное.

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

CS>Вот в результате работы над некими проектами получлся scripting engine.
CS>Подумалось что может быть полезным кому-то еще.
Народу нужна скриптовая машина, не зависисящая от M$.

CS>http://terrainformatica.com/tiscript/

CS>Основная идея engine — простота интегрируемости в чистый C/C++.
CS>API это 10 plain C функций плюс обертка для C++.
CS>Т.е. предпринята попытка сделать practical script engine — всего одна DLL и никаких внешних зависимостей.
Что значит "никаких зависимостей"? А эта dll-ка и есть зависимость. Хорошо бы иметь реализацию на шаблонах, например, на boost::spirit. Тут некоторые уважаемые товарищи предлагали csv-файлы парсить спиритом, ну это IMHO уже перебор, а вот для разбора скрипта — в самый раз. Чтобы можно было легко расширить и настроить его под свои потребности и синтаксис. Есть задачи, где лучше подойдет именно другой, не -жабовский, синтаксис.



CS>... 2) класс Number разделен на два — Integer и Float.
Это почему? Не всем удобно такое деление в скрипте.


CS>3)... Компиляция в байткод и загрузка оного. Внутри движка — compiler, VM и copying GC.
Хотелось бы иметь JIT .


CS>4) Persistence. Binary и textual. Textual это когда данные предсталяют собой поток статических инициализаторв самого скрипта и загружаются с помощью eval. Textual имеет смысл для всякого рода config. Примеры в SDK/scripts/persistence/*.js
Это хорошо бы иметь реализованным в виде xml, чтобы уменьшить вероятность падений в случае, когда загружаются данные, сохраненные другой версией программы, т.е. когда что-то добавили/удалили.

CS>Ну вот примерно и все пока.

CS>Философический вопрос вынесен в subject.
= 2be | !2be

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

A>Здравствуйте, c-smile, Вы писали:

CS>>Философический вопрос вынесен в subject.

A>А чем не устраивают существующие скриптовые языки, которые можно эмдеддить в исходники на С?
A>К примеру, в Цивилизации 4 вся логика AI, распределение ресурсов и т.п. будет реализована на Python (описание карт и т.п. — в XML)...

A>Велосипед — это интересно и познавательно, для саморазвития — опять же — ценно, но когда время ограничено, проще заюзать что-то проверенное.

Во-во. Особенно непонятно зачем использовать куцую Java'у. Я лично взял бы интерпретатор Scheme, благо есть различные по размерам реализации на все случаи жизни. А как язык для скриптов Scheme'а Java'у оставляет далеко за бортом.

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

CS>>Основная идея engine — простота интегрируемости в чистый C/C++.
CS>>API это 10 plain C функций плюс обертка для C++.
CS>>Т.е. предпринята попытка сделать practical script engine — всего одна DLL и никаких внешних зависимостей.
AG>Что значит "никаких зависимостей"? А эта dll-ка и есть зависимость. Хорошо бы иметь реализацию на шаблонах, например, на boost::spirit. Тут некоторые уважаемые товарищи предлагали csv-файлы парсить спиритом, ну это IMHO уже перебор, а вот для разбора скрипта — в самый раз. Чтобы можно было легко расширить и настроить его под свои потребности и синтаксис. Есть задачи, где лучше подойдет именно другой, не -жабовский, синтаксис.

А boost::spirit потянет-то? На yacc, coco/r, antlr сделать разбор языка программирования с последующей генерацией AST или другого представления программы -- это и то не самое простое занятие. А ведь это специализированные инструменты со своими, годами отшлифованными DSL.

CS>>4) Persistence. Binary и textual. Textual это когда данные предсталяют собой поток статических инициализаторв самого скрипта и загружаются с помощью eval. Textual имеет смысл для всякого рода config. Примеры в SDK/scripts/persistence/*.js
AG>Это хорошо бы иметь реализованным в виде xml, чтобы уменьшить вероятность падений в случае, когда загружаются данные, сохраненные другой версией программы, т.е. когда что-то добавили/удалили.

Имхо, здесь нет совершенно никаких проблем. Просто в новой версии конфига нужно сохранить старый API и предоставить новый API для расширений.

Артем, раз ты такой сторонник XML-ных конфигов, можешь прокоментировать то, что я вот здесь нафантазировал: Re[23]: XML vs рукописный формат для конфигов

Автор: eao197
Дата: 09.09.05

(имеется в виду Ruby скрипт с конфигурацией, в котором возможна условная обработка). И насколько просто будет сделать подобное решение на XML?

Задумчиво так... а ну его на...

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

CS>>Философический вопрос вынесен в subject.

A>А чем не устраивают существующие скриптовые языки, которые можно эмдеддить в исходники на С?
A>К примеру, в Цивилизации 4 вся логика AI, распределение ресурсов и т.п. будет реализована на Python (описание карт и т.п. — в XML)...

Присоединяюсь к этому вопросу.

И еще один вопрос: а как же c-smile?

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

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

CS>>>Философический вопрос вынесен в subject.

A>>А чем не устраивают существующие скриптовые языки, которые можно эмдеддить в исходники на С?
A>>К примеру, в Цивилизации 4 вся логика AI, распределение ресурсов и т.п. будет реализована на Python (описание карт и т.п. — в XML)...

E>Присоединяюсь к этому вопросу.

E>И еще один вопрос: а как же c-smile?

Все в общем-то просто. Нужен именно JavaScript c его моделью (prototyped).
В c-smile настоящие классы.

Одна из задач где мне нужен именно JavaScript'ing —
HTMLayout. К сожалению карта в отрасли легла таким
образом что все ожидают в HTML JS.

Не Python, не Perl, не Scheme, а именно JavaScript.

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

CS>>... 2) класс Number разделен на два — Integer и Float.
AG>Это почему? Не всем удобно такое деление в скрипте.

По стандарту все числа в JavaScript c плавающей точкой.

Не всем удобно например в String.charCodeAt(idx) иметь float
как возвращаемое значение кода символа. Я уже не говорю об вычислительной
эффективности этого дела.


CS>>3)... Компиляция в байткод и загрузка оного. Внутри движка — compiler, VM и copying GC.
AG>Хотелось бы иметь JIT .

JIT не возможен в typeless языках. Или если даже возможен
то эффективность его примерно ноль.

CS>>4) Persistence. Binary и textual. Textual это когда данные предсталяют собой поток статических инициализаторв самого скрипта и загружаются с помощью eval. Textual имеет смысл для всякого рода config. Примеры в SDK/scripts/persistence/*.js
AG>Это хорошо бы иметь реализованным в виде xml, чтобы уменьшить вероятность падений в случае, когда загружаются данные, сохраненные другой версией программы, т.е. когда что-то добавили/удалили.

JavaScript, textual persistence:

data: {
  one: 1;
  two: "text";
}

То же но в XML:
<data type="map">
<one type="int">1</one>
<two type="string">text</two>
</data>

Т.е.
1) Как видишь XML немного "шумит".
2) Для использования внутри script его родная форма удобнее в разы. Загрузка готовых к использованию данных — вызов одной функции.

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

VD>Задумчиво так... а ну его на...

Вот и я о том.

Не хотел если честно этот лисапед делать.

Но заказчик...
Интересно люди оплачивают скажем год З/П
моей фирмы и хотят иметь scripting (в присыпку).
Вот я и задался вопросом а на кой им это надо?
И серьезные же люди...

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

LUA + Luabind = rulez forever

Не зависит от MS, основа -- эффективный сишный код. Биндинги к пользовательскому C++ коду -- удобные шаблоны.

Tuo_Bellas.

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

T_B>Здравствуйте, c-smile, Вы писали:

T_B>LUA + Luabind = rulez forever

T_B>Не зависит от MS, основа -- эффективный сишный код. Биндинги к пользовательскому C++ коду -- удобные шаблоны.

T_B>Tuo_Bellas.

Согласен.

Но к сожалению LUA популярна в основном в среде "дети Борланда"...

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


E>А boost::spirit потянет-то? На yacc, coco/r, antlr сделать разбор языка программирования с последующей генерацией AST или другого представления программы -- это и то не самое простое занятие. А ведь это специализированные инструменты со своими, годами отшлифованными DSL.

Не знаю . Но раз потянул парсинг XML-я и csv, которым и без него в общем-то хорошо, то тут уж сам бог велел


E>Имхо, здесь нет совершенно никаких проблем. Просто в новой версии конфига нужно сохранить старый API и предоставить новый API для расширений.
???!!!! И сколько же таких расширений накопится по мере расширения продукта? А ведь их еще придется потом поддерживать, баги править .

E>Артем, раз ты такой сторонник XML-ных конфигов, можешь прокоментировать то, что я вот здесь нафантазировал: Re[23]: XML vs рукописный формат для конфигов

Автор: eao197
Дата: 09.09.05

(имеется в виду Ruby скрипт с конфигурацией, в котором возможна условная обработка). И насколько просто будет сделать подобное решение на XML?

XML не для того придумали. IMHO если имеет место быть конфиг с условной обработкой, то это уже вопрос неправильной архитектуры.

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


CS>Не всем удобно например в String.charCodeAt(idx) иметь float
CS>как возвращаемое значение кода символа. Я уже не говорю об вычислительной
CS>эффективности этого дела.

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


CS>JIT не возможен в typeless языках. Или если даже возможен
CS>то эффективность его примерно ноль.
Почему невозможен? VARIANT и никаких проблем с приведением типов. Эффективность все же выше, как пример, код на C++, работающий с вариантами, быстрее аналогичного кода интерпретатора.


CS>>>4) Persistence. Binary и textual. Textual это когда данные предсталяют собой поток статических инициализаторв самого скрипта и загружаются с помощью eval. Textual имеет смысл для всякого рода config. Примеры в SDK/scripts/persistence/*.js
AG>>Это хорошо бы иметь реализованным в виде xml, чтобы уменьшить вероятность падений в случае, когда загружаются данные, сохраненные другой версией программы, т.е. когда что-то добавили/удалили.

CS>JavaScript, textual persistence:
CS>

CS>data: {
CS>  one: 1;
CS>  two: "text";
CS>}
CS>

CS>То же но в XML:
CS><data type="map">
CS> <one type="int">1</one>
CS> <two type="string">text</two>
CS></data>

CS>Т.е.
CS>1) Как видишь XML немного "шумит".
CS>2) Для использования внутри script его родная форма удобнее в разы. Загрузка готовых к использованию данных — вызов одной функции.

Ну и что, что "шумит". Зато если прибавилось новое поле в структуру, оно проинициализируется по дефолту а не грохнется.

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

CS>JIT не возможен в typeless языках. Или если даже возможен
CS>то эффективность его примерно ноль.

С чего бы это вдруг? "Ведь наши ученые доказали, что любая форма жизни, у которой нет щупальцев, не может обладать разумом"?

Термин typeless просто на удивление "удачен". Например, он совсем не означает, что типов в языке нет и что компилятор/рантайм их не может определить.

Впрочем, к примерам. Psyco — JIT для Python. Ускоряет численные рассчеты раз в 25. А для Смоллтока джиты появились раньше чем для явы. Один из таких Смоллтоковских движков лег в основу первой версии Sun-овской виртуальной машины HotSpot.

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

AG>Здравствуйте, c-smile, Вы писали:


CS>>Не всем удобно например в String.charCodeAt(idx) иметь float
CS>>как возвращаемое значение кода символа. Я уже не говорю об вычислительной
CS>>эффективности этого дела.

AG>Если в процессе вычислений получили дробное число — то придется отбросить дробную часть. А это нехорошо. Какой тут может идти разговор о вычислительной эффективности, если это интерпретатор? Все равно действия в float-ми быстрее интерпретирования.

Не понял высказывание если честно.

Как float "влезает" в нечто типа такого:

switch(String.charCodeAt(idx))
{
  case 'a': ....
  case 'b': ....
}

ИМХО, только путем нестандартного секса.

CS>>JIT не возможен в typeless языках. Или если даже возможен
CS>>то эффективность его примерно ноль.
AG>Почему невозможен? VARIANT и никаких проблем с приведением типов. Эффективность все же выше, как пример, код на C++, работающий с вариантами, быстрее аналогичного кода интерпретатора.

"Эффективность все же выше, как пример, код на C++,"

Не выше. Эффективность кода одна и та же. Во всяком случае у меня.

JIT есть компиляция байткода в машинные команды.
О каких машинных командах идет речь в случае VARIANT данных?

Что можно сделать в JIT в случае с var a = b + c; если типы b и с неизвестны в момент JITа.
По моему проблема очевидна. Нет?


CS>>>>4) Persistence. Binary и textual. Textual это когда данные предсталяют собой поток статических инициализаторв самого скрипта и загружаются с помощью eval. Textual имеет смысл для всякого рода config. Примеры в SDK/scripts/persistence/*.js
AG>>>Это хорошо бы иметь реализованным в виде xml, чтобы уменьшить вероятность падений в случае, когда загружаются данные, сохраненные другой версией программы, т.е. когда что-то добавили/удалили.

CS>>JavaScript, textual persistence:
CS>>

CS>>data: {
CS>>  one: 1;
CS>>  two: "text";
CS>>}
CS>>

CS>>То же но в XML:
CS>><data type="map">
CS>> <one type="int">1</one>
CS>> <two type="string">text</two>
CS>></data>

CS>>Т.е.
CS>>1) Как видишь XML немного "шумит".
CS>>2) Для использования внутри script его родная форма удобнее в разы. Загрузка готовых к использованию данных — вызов одной функции.

AG>Ну и что, что "шумит". Зато если прибавилось новое поле в структуру, оно проинициализируется по дефолту а не грохнется.

А почему оно должно "грохаться" в моем случае?

Добавляем (или убираем) поле и ничего в принципе не меняется (не "грохается").

data: 
{
  one: 1,
  two: "text",
  three: new Date( 2005, 9, 12 ),
  four: ["Masha", "Vova", "Vasya" ]
}

Или я не понял проблему?
Абсолютно та же flexibility что и в случае с XML.

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

G>Здравствуйте, c-smile, Вы писали:

CS>>JIT не возможен в typeless языках. Или если даже возможен
CS>>то эффективность его примерно ноль.

G>С чего бы это вдруг? "Ведь наши ученые доказали, что любая форма жизни, у которой нет щупальцев, не может обладать разумом"?

G>Термин typeless просто на удивление "удачен". Например, он совсем не означает, что типов в языке нет и что компилятор/рантайм их не может определить.

Еще раз повторю вопрос:

Что можно сделать в JIT в случае с var a = b + c; если типы b и с не известны в момент JITа?

Что наверное можно но имхо выигрыш не будет стоить усилий затраченных на a) разработку JIT b)
увеличение объемов требуемых ресурсов.

G>Впрочем, к примерам. Psyco — JIT для Python. Ускоряет численные рассчеты раз в 25. А для Смоллтока джиты появились раньше чем для явы. Один из таких Смоллтоковских движков лег в основу первой версии Sun-овской виртуальной машины HotSpot.

Я не считаю что Psyco это решение (src: http://psyco.sourceforge.net/introduction.html) :
Причины выделены мной:

Think of Psyco as a kind of just-in-time (JIT) compiler, a little bit like Java's, that emit machine code on the fly instead of interpreting your Python program step by step. The difference is that Psyco writes several version of the same blocks (a block is a bit of a function), which are optimized by being specialized to some kinds of variables (a "kind" can mean a type, but it is more general). The result is that your unmodified Python programs run faster.

Benefits

2x to 100x speed-ups, typically 4x, with an unmodified Python interpreter and unmodified source code, just a dynamically loadable C extension module.

Drawbacks

Psyco currently uses a lot of memory. It only runs on Intel 386-compatible processors (under any OS) right now. There are some subtle semantic differences (i.e. bugs) with the way Python works; they should not be apparent in most programs.

Назначение scripting языков в "склеивании" эффективных "native" компонент между собой.
В итоге получаемая система выигрывает не скоростью а в разы увеличиваемым качеством
возможных суперпозиций/сочетаний.

Имхо как всегда.

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

G>>Термин typeless просто на удивление "удачен". Например, он совсем не означает, что типов в языке нет и что компилятор/рантайм их не может определить.

CS>Еще раз повторю вопрос:

CS>Что можно сделать в JIT в случае с var a = b + c; если типы b и с не известны в момент JITа?

Джиттить имеет смысл цыклы — от этого основной выигрышь. В телах циклов типы var a = b + c обычно выводятся без проблем — типы и значения переменных за пределами циклов уже известны. Плюс, для функций применяется техника сходная с тем, как джиттятся generics в .НЕТ (JIT генерит разный машинный код для аргумента различного типа). Учитывая то, что нам наиболее важно определить числовые типы (от этого основной прирост скорости), все не так страшно.

CS>Что наверное можно но имхо выигрыш не будет стоить усилий затраченных на a) разработку JIT b)
CS>увеличение объемов требуемых ресурсов.

G>>Впрочем, к примерам. Psyco — JIT для Python. Ускоряет численные рассчеты раз в 25. А для Смоллтока джиты появились раньше чем для явы. Один из таких Смоллтоковских движков лег в основу первой версии Sun-овской виртуальной машины HotSpot.

CS>Я не считаю что Psyco это решение (src: http://psyco.sourceforge.net/introduction.html) :
CS>Причины выделены мной:

CS>

CS>Think of Psyco as a kind of just-in-time (JIT) compiler, a little bit like Java's, that emit machine code on the fly instead of interpreting your Python program step by step. The difference is that Psyco writes several version of the same blocks (a block is a bit of a function), which are optimized by being specialized to some kinds of variables (a "kind" can mean a type, but it is more general). The result is that your unmodified Python programs run faster.

Зря выделяете "a kind of". Это самый настоящий джит, как бы авторы не прибеднялись. То, что вы выделяете "several version of the same blocks" — спокойно, господа, это не проблема, а просто одна из техник JIT компиляции параметрически полиморфных функций , которую я выше уже упоминал. Дотнет подобным образом компилирует женерики, и это считается "решением".

Теперь я повыделяю, почему я считаю это решением, ок?

CS>Benefits

CS>2x to 100x speed-ups, typically 4x, with an unmodified Python interpreter and unmodified source code, just a dynamically loadable C extension module.

Спидап видели? Вот так. Комментируем далее:

CS>Drawbacks

CS>Psyco currently uses a lot of memory.
Слово currently заметили? Свойство реализации, а не принципиальная проблема. Во-первых, надо память подбирать периодически, что там пока не делается, во вторых главное заджитить версию функции для скалярных типов. В третьих, полиморфного кода в реальности не так много — процентов 25 может быть. Так что реальный оверхэд по памяти из-за хранения многочисленных скомпилированных версий одной функции я бы оценил в 2х, что терпимо.

CS>It only runs on Intel 386-compatible processors (under any OS) right now. There are some subtle semantic differences (i.e. bugs) with the way Python works; they should not be apparent in most programs.
Semantic differences — выделяете, а пояснение, что имеются в виду ошибки (i.e. bugs) — нет. Проблема текущей реализации.

CS>Назначение scripting языков в "склеивании" эффективных "native" компонент между собой.
CS>В итоге получаемая система выигрывает не скоростью а в разы увеличиваемым качеством
CS>возможных суперпозиций/сочетаний.
+25. С этим я, собственно, согласен целиком. Я не согласен с тем, что "джыт невозможен для "бестиповых" языков". Как мы видим, возможен. И вопрос, нужно ли это в скриптовых языках — несколько другой.

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

G>+25. С этим я, собственно, согласен целиком. Я не согласен с тем, что "джыт невозможен для "бестиповых" языков". Как мы видим, возможен. И вопрос, нужно ли это в скриптовых языках — несколько другой.

[поскипано].

Я не спорю с нужностью JIT. Само собой он нужен на определнных задачах.
Я лишь хочу обратить внимание на то что JIT это "неуловимый Джо" в большинстве случаев применения скриптовых языков.

Например TIScript использует компиляцию в bytecode и исполнение оного.
Это относитлельно дешевое (протзводительность) и эффективное решение.
Утверждаю что для 90% случаев использования scripting это оптимальное или суб-оптимальное решение.

Те задачи которые действительно требуют того что дает JIT очень легко и максимально эффективно решаются в native коде. Нормальный script engine должен лишь предоставить простой и прозрачный способ встраивания native code в script. Все. Больше ничего не надо.

Еще раз JIT нужен тем системам которые претендуют на звание "универсальный язык программирования". Java, .NET и пр.
Для скриптовых языков JIT это ... ну даже не знаю как сказать...
пятая нога псу Мухтару наверное.

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

CS>Не хотел если честно этот лисапед делать.

CS>Но заказчик...
CS>Интересно люди оплачивают скажем год З/П
CS>моей фирмы и хотят иметь scripting (в присыпку).

Тогда это уже превращается в святое дело и творческий процесс проедания денег заказчика.

CS>Вот я и задался вопросом а на кой им это надо?
CS>И серьезные же люди...

Ну, не всем же Челси скупать? Есть у людей и другие причуды.