morale [was: parascriptum: release v0.2]

Я не думаю, что функции API быстрее ищут функции в PE бинарнике, чем ты 
бы их нашёл в уже чётко структурированном массиве.  Функции API 
используют точно такой же перебор и строковые операции, другого способа 
у них нет.  Тебе же никто не мешает слегка оптимизировать поиск 
задействовав какое-нибудь хэширование (например, как я задействовал 
CRC32 для поиска сообщений в paracore (оптимизация приветствуется)).

Бинарный поиск с требованием сортировки массива по алфавиту -- 
потенциальные грабли, система не должна зависеть от таких вещей.

Номера версий тебе как отслеживать -- очень просто: руками.  Сменил 
структуру таблицы функций так, что потерялась совместимость -- увеличил 
версию интерфейса на единицу.  Модуль же возвращает таблицу для нужной 
версии (если модуьл поддерживает их несколько, и если такая ситуация 
вообще возникнет (но быть к ней заранее готовым -- скорее хорошо)).

Идея с использованием машинного стэка в качестве стэка парсера понятна. 
  Работать будет, безусловно, но уровень вложенности придётся 
ограничить.  Плохо, что приходится отказывать пользователю в 
удовольствии рисовать фракталы конфигурационными файлами, но всё же. 
Парсер конфигов в парабеллуме (пра-лэйн) тоже был рекурсивным, и даже 
без ограничения на глубину.  Однако представляя на сколько придётся всё 
усложнить, я даже не знаю, стоит ли.  Пока из идей по превращению 
рекурсивного парсера в линейный есть одна: выделять в обычной памяти 
(динамический) массив структур, хранящих всю нужную информацию, и 
использовать его, собственно, как стэк.  Собственно, ничего такого, до 
чего ты сам не смог бы дойти.

На счёт регистра, отвечающего за выполнение блока.  В самом начале 
работы с файлом он установлен, и возможно с ним сделать только одно: 
сбросить.  При входе в новый блок он копируется (не инициализируется), и 
если он сброшен -- все команды выполняются вхолостую.  Есть два способа 
его снова установить: закрыть фрэйм, в котором регистр был сброшен, или 
else-подобным оператором.

Одно замечание на счёт блоков: не хочется допускать сишных вольностей, 
вроде "если в блоке лишь одна команда, то не обязательно его выделять 
скобками".  Это приводит либо к ошибкам при использовании ветвящихся 
else, либо к необходимости их отслеживать и кричать "рекомендуем явный 
блок", т.е. лишний код.

> текущие планы, после внедрения всех выше указанных замечаний -
> реализация переменных. и сразу за ними функций.

Джет, давай ещё раз определимся с задачей?  Ты, кажется, пишешь 
скриптинг для парабеллума.  Зачем он нужен -- загружать модули и 
запускать их?  Кажется именно для этого.  Однако в некоторых случаях он 
мог бы помочь строить системы с жизненным циклом, отличным от "старт, 
работа, стоп".  В частности, это подразумевает комплексную инициализацию 
подсистем (задействовав функции отправки и получения сообщений [1]).  По 
этому поводу несколько концептуальных замечаний.

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

Мораль: парсер должен быть модулем.  Модуль загружается стандартным 
стабом (коих будет несколько: консольный, графический итд) и начинает 
работу: читает конфигурационный файл (дефолтный; способ передачи имени 
конкретного файла ещё предстоит обдумать).

Во-вторых, чем больше побочных библиотек тянет за собой парсер, тем 
меньше шансов, что кому-то захочется его использовать.  Пусть даже эти 
библиотеки -- ни что иное, как непосредственно исполнители команд. 
Следовательно, сама идея внешних парсеров ставится под сомнение.

В-третьих: интерактивная консоль будет совершенно отдельным модулем.

[1] Получение сообщений -- с возможностью указания времени ожидания, и 
если сообщение не получено -- функция возвращает false, в противном 
случае -- true.



-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
Discussions in this list are held in two languages: English and Russian.
When replying, please use the language that the sender of the original
message is guaranteed to understand, or use English.