Интерпретатор команд

[kuhtiov]

Долго искал, не нашел. Нужно написать нтерпретатор команд на vb. Если есть пример, поделитесь пожалуйста

[Хакер]

Каких команд? Интерпретатора, как интепретирующего? Что делающего?

[kuhtiov]

Будет подобие мастера установки, программа должна уметь выполнять скрипт, на "моем языке". Хочу обучить программу копировать файлы, вносить изменения в реестр и т.д. Объяснил, как мог

[Debugger]

Как в BAT-файлах?

[kuhtiov]

да, именно

[alibek]

Ну и используй BAT-файлы.

[Денис]

Ууу, ну это дело такое. Написать свой интерпретатор это первый шаг к написанию своего компилятора.

Вообще, задачу можно разбить на две задачи:
• парсер
• обработчик команд

Вот примерный код парсера

Код: Выделить всё

A1 = Split(InputFile, vbCrLf) 'Если для разделения строк используем новую строку. Или:
A1 = Split(InputFile, ";") ' Для паскалеподобного синтаксиса.

Затем, имея в массиве A1 ключевые слова нашего скрипта с параметрами, так?
Если с параметрами то дополнительно сплитуем каждый элемент массива по признаку, разделяющему параметры, тоесть, по пробелу.

Теперь код обработчика команд. Это простейший командный процессор из уроков информатики:
Для начала пример скрипта:

Поприветствовать_мир
Записать_в_реестр HKCU Software\MySoft\Main LastUser Вася
Сумма 2 + 3
Показать_итог
Вывести_сообщение Заголовок vbOKOnly "Не знаю как, но парсер должен уметь обрабатывать строки, содержащие пробелы"

Запустить Calc.exe

Код: Выделить всё

'Для второй строки скрипта в массиве A2 например, будет лежать:
' 0                    1       2                       3           4
'"Записать_в_реестр", "HKCU", "Software\MySoft\Main", "LastUser", "Вася"

Select Case A2(0)
    Case "Записать_в_реестр": Call Reeesr.Add(A2(1), A2(2), A2(3), A2(4)) 'делаем так
    Case "Поприветствовать_мир": MsgBox("Hello world!")
    Case "Вывести_сообщение": MsgBox A2(1), A2(2), A2(3)
    Case "Сумма": Ret = A2(1) + A2(3)
    case "Показать_итог": MsgBox Ret
    Case "Запустить": Shell A2(1), vbNormalFocus
end Select

Здесь я допускаю, что Reestr это класс, работающий с реестром и имеющий метод .Add(Key as string, Path as string, Name as String, Value as Variant), добавляющий запись в реестр; что парсер как-то реагирует на кавычки и воспринимает все до следующей кавычки (включая пробелы) как один параметр.

Вот как-то так.

[hclubmk]

А чем не устраивают существующие скриптовые интерпретаторы (VBScript, AutoIt и т.п.)?

[Денис]

А чем не устраивают существующие скриптовые интерпретаторы (VBScript, AutoIt и т.п.)?

Может с него требуют именно свой?
Или может он придумал какой-то свой сверх-юзабельный скриптовый язык, типа:

Код: Выделить всё

HAI
    GIV MI PWEASE Y SISTEM DIR
    IMMA IN Y SISTEM DELETIN Y FILES
BYE

[Хакер]

Денис, пиши правильные формулировки пожалуйста.

Не «примерный код парсера», а «пример того, как никогда не стоит писать парсер».

[FireFenix]

а «пример того, как никогда не стоит писать парсер».

Интересненько, а как правильнее?

1) Анализ и разбиение кода на список простых операций
2) Если используются модули - проверка их наличия
3) Выполнение команд из списка
?

[Хакер]

Никто не разбирает текст, код с помощью сплитов и лефт-стрингов. Это сродни пайки тонкой электронике раскалённым в костре гвоздём.

Или ещё одна шиза: использование регулярных выражений для этой цели.

[Andrey Fedorov]

А чем не устраивают существующие скриптовые интерпретаторы (VBScript, AutoIt и т.п.)?

Может с него требуют именно свой?

Вряд ли - скорей всего просто незнание. Того же Script-контрола за глаза хватит для его задачи.

[Debugger]

Никто не разбирает текст, код с помощью сплитов и лефт-стрингов. Это сродни пайки тонкой электронике раскалённым в костре гвоздём.

Или ещё одна шиза: использование регулярных выражений для этой цели.

А как делают настоящие гуру?

[Денис]

Никто не разбирает текст, код с помощью сплитов и лефт-стрингов. Это сродни пайки тонкой электронике раскалённым в костре гвоздём.

Или ещё одна шиза: использование регулярных выражений для этой цели.

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

Парсер по моему примеру, это пример как можно делать парсер. Остаюсь при своем мнении.

Кому не нравится, напишите свой пример как надо делать и как не надо делать.

[Хакер]

Денис, за свой троллизм ты, наверное, будешь скоро наказан.

[NashRus]

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

[Денис]

Денис, за свой троллизм ты, наверное, будешь скоро наказан.

Ты думаешь что я троллю? А тебе не приходило в голову, что я действительно так считаю? Или надо было явно добавить аббревиатуру "ИМХО"?

[Хакер]

Я думаю, что ты троллишь постоянно.

[Денис]

Это не так. Просто такая манера общения. Ладно, хорош флуд разводить. А то забанят нас...

[hclubmk]

А то забанят нас...

Хакер
самому себя: реальность или ахинея?

[Samsonov]

Пример того, как не стоит писать парсер.

Кстати, давно мучает любопытство: как стоит писать интерпретатор? А именно — как оптимизировать блоки ветвления, многократно выполняемые в циклах? Например, такие:

Код: Выделить всё

Do While тра-та-та
  Select Case A2(0)
    Case "Записать_в_реестр": Call Reeesr.Add(A2(1), A2(2), A2(3), A2(4)) 'делаем так
    Case "Поприветствовать_мир": MsgBox("Hello world!")
    Case "Вывести_сообщение": MsgBox A2(1), A2(2), A2(3)
    Case "Сумма": Ret = A2(1) + A2(3)
    Case "Показать_итог": MsgBox Ret
    Case "Запустить": Shell A2(1), vbNormalFocus
  End Select
Loop

Насколько я понимаю, сии штуки организуются с помощью таблицы переходов, и что некоторые компиляторы — например, C# — создают подобные конструкции автоматически, но в VB.Net и тем более в старых версиях VB этого не предусмотрено. Можно ли провернуть такой фокус вручную?

В голову приходит только идея использовать словарь [нечувствительный к регистру ключей], значениями которого будут адреса функций-обработчиков. Но возникает проблема, как обеспечить этим функциям доступ к внутренним данным текущей функции — ведь в каждом случае требуются разные переменные и разное их количество. Одно дело, когда всемогущий компилятор создаёт что-то вроде внутренних GoSub-конструкций, и совсем другое дело — уподобиться ему, не опускаясь до низкоуровневых операций.

[alibek]

Почитай сообщения tyomitch-а или Хакер-а.
Про оптимизацию можно думать потом, когда будут написаны КА.

[Денис]

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

Ну во-первых "разные переменные и разное их количество" не соответствуют принципу конечного автомата. А значит, задача уже неверно сформулирована.
Если я правильно понимаю описания (а это не факт)), то сначала в КА вводится список ключевых слов обрабатываемого языка, а значит, мы сразу определяем набор будущих переменных. Затем мы обрабатываем входные данные посимвольно (и каждый новый символ переводит нас по словарю от первой буквы искомого ключевого слова ко второй, третьей и т.д.) и каждый раз, когда мы встречаем признак конца слова (банально пробел), мы уже должны иметь в отдельной переменной либо индекс ключевого слова из словаря, либо значение, соответствующее ошибке синтаксиса (так как входное слово не найдено в словаре). Далее, главная фишка КА это режимы (конечные состояния), самый простой режим, это ошибка. в нем выполнение останавливается и сообщается номер строки. всё.
а теперь предположим, что наш автомат прочитал слово for. согласно своим определениям языка, он переходит в режим цикла и ожидает найти идентификатор переменной, затем знак равенства, затем первое число, с которого начинать цикл, и так далее, далее, аж до самого next. когда автомату удается найти все, что он искал, он вызывает у себя шаблон функции цикла и передает собранные данные
1. Начало и конец цикла, грубо говоря, число итераций;
2. Список функций, которые надо выполнять в цикле;
в отдельную функцию. Эта функция так же впоследствии может стать частью другого цикла. И вот это все выстраивается в дерево.

Так вот, передавать данные из одного узла дерева в другое бессмысленно и опасно. Но у КА может быть строго ограниченный набор переменных (стек, видимо), в который во-первых заносятся все обнаруженные автоматом в обрабатываемом тексте переменные, во-вторых, свои, служебные данные. Больше ничего не требуется при правильной постановке задачи и правильной реализации: Вопрос - ответ; ключ - реакция. И ничего более.

Вот что меня взбесило в ответах Хакера, так это то, что Автор топика попросил простой интерпретатор нескольких команд установки, копирования, распаковки. Линейный. Одноклеточный. Я ему дал такой алгоритм. Простой одноразовый проход по телу скрипта, со строго регламентированным синтаксисом (ключевое_слово параметр1 .. параметрN)

Но нет, давайте стрелять из пушки по воробьям! Давайте! Пусть Автор топика посвятит несколько лет проектированию своего тьюринг-полного языка программирования и компилятора к нему, пусть он обрастет бородой и свитером! Но заказчик откажется от его услуг уже через неделю.

[Хакер]

Вот что меня взбесило в ответах Хакера, так это то, что Автор топика попросил простой интерпретатор нескольких команд установки, копирования, распаковки. Линейный. Одноклеточный. Я ему дал такой алгоритм. Простой одноразовый проход по телу скрипта, со строго регламентированным синтаксисом (ключевое_слово параметр1 .. параметрN)

Вот для такого случая и был мой ответ. В этом случае использовать сплит и Left$ — идиотизм. Если ему нужен аналог BAT-файлов, то я точно скажу, что для обработки пакетного скрипта нужно то, что я сказал.

Потом, у тебя распространённая болезнь: «пахнет разбором чего-то и конечными автоматами — значит нужно имитировать бурную и сложную деятельность». Хотя надо просто решать задачу. Максимально простым и ленивым способом. Не для программиста-гадёныша, а для компьютера.

Вот например вб-шный сплит — это море ненужной работы по созданию копий фрагментов. Фрагментов может быть 100, значит и копий будет 100. Каждый фрагмент (копию) ты будешь потом обрабатывать опять подвергать сплиту, и создашь для каждого фрагмента ещё по 10 копий. Итого, будет входной код и 1100 копий его фрагментов. И это глупо и дико, потому что 1100 копий фрагментов никому не нужны: в них нет ничего нового (всё уже есть во входном коде), но они адаво фрагментируют строковую кучу. Это наверное как раз тот подход, в духе которого пишутся последние студии — поэтому они так дико виснут и медленно работают.

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

Но даже если сплит будет возвращать смещения, а не сами строки, мы подходим ко второму моменту: почти для всех современных языков сплит по одному и тому же разделителю бесполезен и ничего не даёт. VB-код не имеет смысла делить делителем CRLF, С, С++, Java, JavaScript, PHP и тому подобные коды — не имеет смысла делить как делителем CRLF, так и делителем ";". Кроме информации о том, где в строке находятся разделители, такая информация вообще ничем не полезна.

Вот например, при делении делителем ";" наверняка получится такой фрагмент:

Код: Выделить всё

// И выходим из функции FIRST, возвращая 0 } function SECOND() { while(bTruncated) { AsrLockThisItem()

Хороший фрагмент, да? Что такое умное ты с ним сделаешь, после того, как получишь его сплитом?

[Samsonov]

Как оптимизировать блоки ветвления, многократно выполняемые в циклах?

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

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

«Разные переменные и разное их количество» не соответствуют принципу конечного автомата.

Мой вопрос касался конкретно того, про что я писал, — как оптимизировать блок Select Case, если все условия имеют форму сравнения с константой. Ни про что другое я не спрашивал.

Попробую объяснить ещё раз. Проблема с Select Case состоит в том, что код:

Код: Выделить всё

Select Case strCmd
  Case "Записать_в_реестр": WriteReg
  Case "Поприветствовать_мир": MsgBox "Hello world!"
  Case "Вывести_сообщение": MsgBox A2(1), A2(2), A2(3)
  Case "Сумма": Ret = A2(1) + A2(3)
  Case "Показать_итог": MsgBox Ret
  Case "Запустить": Shell A2(1), vbNormalFocus
  Case Else: MsgBox "Неизвестная команда"
End Select

компилируется в нечто вроде такого:

Код: Выделить всё

If strCmd = "Записать_в_реестр" Then
  WriteReg
ElseIf strCmd = "Поприветствовать_мир" Then
  MsgBox "Hello world!"
ElseIf strCmd = "Вывести_сообщение" Then
  MsgBox A2(1), A2(2), A2(3)
ElseIf strCmd = "Сумма" Then
  Ret = A2(1) + A2(3)
ElseIf strCmd = "Показать_итог" Then
  MsgBox Ret
ElseIf strCmd = "Запустить" Then
  Shell A2(1), vbNormalFocus
Else
  MsgBox "Неизвестная команда"
End If

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

Однако в простейшем случае строгого сравнения с константами (точнее, со значениями, неизменными на протяжении всего блока Select Case), хотелось бы чего-то вроде такого:

Код: Выделить всё

Dim dicJumpTable As New Dictionary(Of String, Integer)
dicJumpTable.Add("Записать_в_реестр", 10)
dicJumpTable.Add("Поприветствовать_мир", 20)
dicJumpTable.Add("Вывести_сообщение", 30)
dicJumpTable.Add("Сумма", 40)
dicJumpTable.Add("Показать_итог", 50)
dicJumpTable.Add("Запустить", 60)

Do While тра-та-та

  If dicJumpTable.ContainsKey(strCmd) Then
    GoSub dicJumpTable.Item(strCmd)
  Else
    MsgBox "Неизвестная команда"
  End If

Loop

Exit Sub

10: WriteReg: Return
20: MsgBox "Hello world!": Return
30: MsgBox A2(1), A2(2), A2(3): Return
40: Ret = A2(1) + A2(3): Return
50: MsgBox Ret: Return
60: Shell A2(1), vbNormalFocus: Return

Если бы подобной оптимизацией занимался сам компилятор Бейсика, ему бы ничего не стоило создать такой машинный код, где бы каждому Case-блоку соответствовала маленькая GoSub-подпрограмма. Но если компилятор QB/VB/VB.Net такого не делает, есть ли шанс сделать это за него, не пускаясь во все тяжкие с буквальным использованием оператора GoSub?

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

[Debugger]

Вот для такого случая и был мой ответ. В этом случае использовать сплит и Left$ — идиотизм.

А как сделать правильно?

[SLIM]

компилируется в нечто вроде такого:

Ты думаешь это реально так?

[Хакер]

А как сделать правильно?

«Преобразователь» на вход получает одну последовательность, на выход вываливает вторую. Второй (если нужен) «преобразователь» получает на вход первую, на выходе выдаёт третью. И так, пока не получится «удобоваримая» последовательность.

Как делать такой преобразователь — дело ваше, лишь бы хорошо. Я уже давно сделал для себя технологию, в соответствии с которой динамически строится граф из кусочков кода, называющихся «роутерами», который на основании элементов выходной цепочки решает о том, по какому пути пойдёт выполнение кода в графе. В результате, входная последовательность получается не просто входной последовательностью, а маршрутом, который приводит выполнение к специальным роутерам так, что те записывают правильную выходную цеплочку.

[FireFenix]

компилируется в нечто вроде такого:

Ты думаешь это реально так?

А разве кейсы на самом деле не набор связок cmp/jxx (асм)?

Вот для такого случая и был мой ответ. В этом случае использовать сплит и Left$ — идиотизм

А как сделать правильно?

«Преобразователь» на вход получает одну последовательность, на выход вываливает вторую. Второй (если нужен) «преобразователь» получает на вход первую, на выходе выдаёт третью. И так, пока не получится «удобоваримая» последовательность.

Мне кажется это никак не связанно с тем что Left, Split и регулярки не подходят для этих целей...

Собсно если не использовать в VB Left, Split и регулярки, то остаётся только орудовать Mid и InStr? =)

Я уже давно сделал для себя технологию, в соответствии с которой динамически строится граф из кусочков кода

Возможно ли лицезреть это ПО? конечно желательно исходничег...