Самая чистая структура данных для использования при интерпретации данных из аккуратно структурированных пользовательских команд (на C++)

Ваш вопрос не ясен. И ваши цели сложнее, чем то, во что вы верите.

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

Или вы считаете, что хотите интерпретировать какой-то формальный язык программирования или скриптов. Затем вы хотите изучить интерпретаторы и компиляторы. Кстати, в этом случае вы можете просто встроить существующий интерпретатор (например, Lua, Guile, Python и т. д. ...) в вашей программе.

Вы также можете представить себе экспертные системы с база знаний, состоящая из правил (этот подход можно рассматривать как нечто среднее между НЛП и языком сценариев). ">механизм вывода (возможно, CLIPS). См. также блог Дж. Питрата.

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

Кстати, все NLP, экспертные системы, а также разработка и реализация интерпретаторов - сложные области. Вы можете получить докторскую степень во всех трех областях (но вам нужно выбрать, в какой).

Если вы пойдете по пути встроенного интерпретатора: изучите интерпретаторы, о которых я упоминал (Guile, Lua, Python, Neko и т. д.). ) и выберите, какой из них вы хотите встроить.

Если по какой-либо причине вы хотите создать интерпретатор с нуля: сначала изучите несколько языков программирования (включая языки сценариев, такие как Ruby, Python, Ocaml, Scheme, Lua, Neko, ...). Прочтите книги по Прагматика языка программирования (автор М. Скотт) и Маленькие фрагменты Lisp (от Queinnec). Прочтите также учебники по компиляции и разбору, а также по сборке мусора и формальным (например, денотативный) семантика. На все это может потребоваться дюжина лет работы.

Обратите внимание, что по опыту встраивание программного обеспечения в интерпретатор является очень структурным проектом. Если вы не подумали об этом в начале, вам, вероятно, потребуется много перепроектировать и реорганизовать существующее приложение. Например, при встраивании программного обеспечения в интерпретатор вы не можете допустить, чтобы неверный ввод привел к сбою программы. Таким образом, обработка ошибок и управление памятью (взаимодействие с GC интерпретатора) сложны и накладывают новые ограничения. Следовательно, вам нужно переосмыслить свое приложение.

Если все это ново (и даже если вы не выбираете, например, Guile в качестве встроенного интерпретатора): изучите и попрактикуйтесь немного в Scheme - например. с Guile или PltScheme- (например, прочитав SICP), прочитайте немного о λ-исчисление и замыкания, затем прочитайте книгу Queinnec Lisp In Small Pieces. Вспомните проблему с остановкой (отчасти поэтому интерпретаторы трудно программировать).

Кстати, предлагаемый вами синтаксис (например, rotate mat 1 by x 90) не очень удобочитаем и выглядит как COBOL. Если возможно, используйте язык, который выглядит знакомым существующим. Сделайте так, чтобы его читали легко!

^{Начните с чтения всех вики-страниц, на которые я здесь ссылаюсь.}

FWIW, я являюсь основным автором MELT, язык домена (во многом вдохновленный Scheme) для расширения компилятор GCC. Некоторые из статей/документаций, которые я написал, могут вдохновить вас (и содержать ценные ссылки).

Дополнения (после переформулировки вопроса)

Кажется, вы изобретаете какой-то формальный синтаксис, например

add material 1 to layer 1
rotate layer 1 about x-axis by 90 degrees
translate layer 1 in x-axis by 10 inches

Я не могу понять, что это за язык? Вы реализуете 3D-принтер? Если да, вам следует придерживаться какого-либо существующего стандартного формального языка в этой области.

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

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

Ваш DSL по Тьюрингу завершен? (Я предполагаю, что да, потому что полнота по Тьюрингу достигается очень быстро - например, с переменными и циклами....). Если да, вы изобретаете язык сценариев. Пожалуйста, не изобретайте язык сценариев, не зная нескольких языков программирования и сценариев (затем прочитайте Программирование Прагматика языка...). Дело в том, что если ваш скриптовый язык станет успешным, продвинутые пользователи рано или поздно напишут на нем важные программы (например, многие тысячи строк). Затем эти продвинутые пользователи станут программистами. В этом случае очень важно (по социальным и экономическим причинам) иметь хорошо обоснованный и знакомый DSL (если возможно, расширение какого-либо существующего языка сценариев).

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

В нескольких отраслях появились специальные DSL, которые стали широко использоваться, но были плохо спроектированы (например, во французской атомной промышленности DSL Gibiane был разработан в 1970-х годах физиками-ядерщиками, а не учеными-компьютерщиками; американская компания Boeing ходят слухи, что корпорация совершала подобные ошибки). Тогда поддержка и улучшение многих сотен тысяч строк сценариев DSL становится кошмаром (и может означать потерю миллионов долларов или евро). Так что вам лучше придерживаться какого-нибудь существующего языка сценариев. Плюсы в том, что в нем существует некоторая культура (например, вы можете найти десятки книг по Python или Lua и многие обученные инженеры знакомы с ними), что интерпретатор широко используется и тестируется, что сообщество, работающее над ним, улучшает интерпретаторы, поэтому в нем довольно мало неисправленных ошибок.

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

В качестве контрпримера J.Ousterhout изобрел широко используемый Tcl язык сценариев с утверждением, что сценарии всегда малы (например, только сотни строк) и не разрастутся до большой базы кода ; к сожалению, некоторые из них это сделали, и Tcl известен как плохой язык для кодирования многих десятков тысяч строк (даже если Tcl — простой и удобный язык для крошечных скриптов). Мораль этой истории заключается в том, что если скриптовый язык (полный по Тьюрингу) станет успешным, какой-нибудь «сумасшедший» продвинутый пользователь напишет сотни тысяч кодов скриптов. Поэтому вам нужно, чтобы язык сценариев был хорошо разработан с самого начала. Следовательно, вам следует принять и адаптировать хороший существующий язык сценариев (и избегать изобретения незнакомого синтаксиса без хорошего знания нескольких существующих языков сценариев).

более поздние дополнения

^{PS: моя критика Tcl не совсем субъективна: дело в том, что Tcl был разработан для небольших скриптов (прочитайте первые статьи J.Ousterhout о Tcl), но я хочу сказать, что когда вы предлагаете язык сценариев, полный по Тьюрингу, какой-нибудь «сумасшедший» пользователь в конечном итоге напишет для него огромные сценарии. Следовательно, вам нужно предвидеть такое «сумасшедшее» использование, предлагая язык сценариев, который «расширяется» до больших сценариев, поэтому он построен в соответствии с методами разработки программного обеспечения для большой базы кода программного обеспечения.}

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

РЕДАКТИРОВАТЬ: Чтобы быть более ясным, я хотел бы иметь краткий список ключевых слов (‹15). Порядок/наличие которого будет определять, какая функция будет запущена.

Вы можете создать небольшой механизм набора правил (например, что-то, что обрабатывает списки слов). Вы пишете этот движок/функцию один раз и просто передаете ему структуры данных.

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

Вы можете построить таблицу ключевых слов и указателей функций:

typedef void (*Function_Pointer)(void);

struct table_entry
{
  const char * keyword;
  Function_Pointer p_function;
};

table_entry function_table[] =
{
  {"car", Process_Car},
  {"bike", Process_Bike},
};

Найдите в таблице ключевое слово. Если ключевое слово найдено, разыменуйте указатель на функцию.
Следующий фрагмент кода выполнит функцию для обработки слова "автомобиль":

(function_table[0].p_function)();

Существует известная программа Eliza, которая анализирует предложения по ключевым словам.
Примеры можно найти по адресу: примеры Eliza C++