Могут наследоваться в будущем от грамматических классов "глагол", "местоимение", "существительное" и т.п.
Сейчас такого наследования нет. Но список для слов действительно нужен отдельный, и рассчитывая на будущее, можно сразу сделать его в виде дерева.

все идентификаторы в коде делятся на 2 типа:
1. называемые словами;
2. не называемые словами.
Все объекты и переменные 1 типа могут упоминаться игроком в командах ЕЯ.
Все служебные и вспомогательные объекты и переменные должны называться именами 2 типа.

К идентификаторам 2-го типа однозначно можно отнести всё, начинающееся со знаков "_" и "@".
Все остальные идентификаторы потенциально могут быть названы словом или словосочетанием.
Составные идентификаторы, образованные с помощью знаков "_" и ":" относятся к 1 типу, если все части идентификатора до первого ":" совпадают c каким-либо словом или любой его словоформой.

Вот такое сложное правило =)

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

Да, в данном случае "cls" лучше заменить на "value"
Сделаю в следующей выгрузке.

Да, <arg> здесь действительно не нужен, остался в базе от предыдущего варианта как рудимент.
Я сейчас не делаю какого-либо анализа данных при формировании XML, в выгрузку попадает всё что есть в базе.

тут <act> видимо, а не <arg>?

Объекты типа <act> игнорируются в том смысле, что от них сейчас не образуется никакого кода, и в файле tom.dic их нет.
А на дереве объектов это вполне себе полноценный узел.

Теги <cls> (<cls>перемещение</cls>) внутри функций, тоже игнорируются в коде, и нужны только для построения дерева.
Иначе все функции были бы в одном плоском списке.
Нет такого понятия как наследование функций.

<act_sin> это отдельный вопрос. Там с тегом <cls> такая же ерунда как у <variable>.

Не сложно, сделаю конечно. Но не раньше понедельника =)

Атрибут (признак), это грубо говоря класс для логических свойств.
Объект типа attribute больше всего похож на class, только для класса экземпляром является объект, а для атрибута - логическое свойство объекта.
Если объекту присваивается свойство и имя свойства присутствует в списке атрибутов, это свойство обрабатывается как экземпляр атрибута.
Значение атрибута объекта может быть только логического типа.

Есть несколько операций с атрибутами:
<obj>.attribute //возвращает список истинных признаков объекта <obj>
<list> / <attr> //отбирает из списка <list> объекты с истинным значением признака <attr>

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

Наследоваться attribute может от class или от другого attribute.
Может содержать свойства и методы.

Отображать в общем дереве вместе с классами.

Свежая выгрузка с исправлениями!
https://cloud.mail.ru/public/790c87d40252/tomdic.xml

Это ошибка выгрузки.
С базе есть объект с именем "факт", выгрузку исправлю.

Свежая выгрузка с исправлениями:
https://cloud.mail.ru/public/790c87d40252/tomdic.xml

Добавил привязку к словам, вернул факт на место.

Угу, завтра поправлю.

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

перегружаться, а не наследоваться - так правильно =)

class A1{ var P = 5 } //тут P - свойство

class A2
{ is A1 
  -- P -- //тут P - метод
  10 + 5
}

class A3
{ is A2 
  var P = 66 //тут P - опять свойство
}

A3 B{} //объект B

%{B.P} //а тут нам безразлично, P свойство или P метод.

class предмет
{ ...
  action(_взятие, предмет Обж)
  {
     ...
  }
  ...
}

абсолютно эквивалентно

class предмет
{
  ...
}

action(_взятие, предмет Обж)
{
  ...
}

И да, такое вложение функций больше не будет нужно, т.к. появивись нормальные методы/секции.
Стандартную библиотеку я от них почищу.

мб, секция объекта это просто новый тип свойства?