Рассматриваем такой код
Код:
: MYWORD
: NESTED
;
;
В целом оно не работает, потому что вложенное определение пытается встать в середину компилируемого кода. Кроме того, : должно быть IMMEDIATE и понимать, формирует оно верхний уровень или вложенный. Наконец, кто и как будет видеть NESTED? Хотя в целом локальные определения, в том числе с глубокой вложенностью - это нормальная практика в ЯВУ. В Форте ситуация слегка облегчается тем, что стековые манипуляции обходятся без явного именования объектов на стеке, однако при росте объема проекта иметь вложенные определения полезно.
Вложенные определения уже опробованы в кварке через механизм LOC[ ]LOC, который делает вставку новых определений, обеспечивая обход в коде сформированного куска. Возможен еще один вариант.
Если переменную STATE рассматривать не просто как переключатель режимов, а как счетчик уровня вложенности, ненулевое значение на входе в : позволяет понять, что мы имеем дело с объявлением вложенного определения. Это значит, что нужно скомпилировать переход вперед, и разрешить его ближайшим ; Таким способом можно вставлять вложенные определения, не нарушая этим последовательность команд.
Далее, проблема с поиском. NESTED должно быть видно внутри MYWORD и не видно снаружи. С другой стороны, раз уж оно есть, то можно попробовать искать его принудительно. Для этого можно посмотреть на конструкции Форта с более общей точки зрения. Например, словарь как таковой реализован как связанный список (linked list). Это не жестко привязанное к Форту понятие, а вполне независимая структура данных со своими свойствами. Связанный список удобен для Форта тем, что может хранить объекты разной длины, и поэтому заголовок слова + займет меньше места в словаре, чем заголовок слова THISISALMOSTMAXIMUMNAMEFORWORD. Тем не менее, нет принципиального запрета на использование для поиска, к примеру, обычной статической структуры, где для хранения имени будет выделяться максимально допустимое место. Это некоторая расточительность, но организовать поиск в таком массиве структур-описателей слов вполне можно, и даже чуть проще, чем в связанном списке.
Посмотрим теперь на структуры данных, которые "около" связанного списка. Например, может ли помочь дерево? В принципе, получается вполне красиво, потому что дерево, в котором каждый узел указывает на вышестоящий узел - это уже выглядит как просто связанный список. А если на узел указывает несколько дочерних узлов? Но тут намечаются проблемы с обходом этих дочерних узлов (сколько их? как до них добраться?), поэтому можно и чуть иначе - если на узлах основной ветке дерева имеются указатели на дочерние деревья? К примеру, если кроме LFA у заголовка словарной статьи есть еще дополнительное поле (хм, Nested Field Address и Child Field Address дают коллизии с NFA и CFA, так что надо подумать над именем), то у каждого слова появляется возможность держать указатель на вход в цепочку вложенных слов. Соответственно, эти слова игнорируются при поиске, если только они не принадлежат слову, компиляция которого идет в настоящее время. Кроме того, можно обеспечивать и принудительный просмотр вложенной цепочки - одной или даже всех. Например
:: MYWORD NESTED - здесь :: должно найти слово MYWORD и запомнить его в системной переменной словаря. Тогда при разборе NESTED будут просматриваться все имена "основной" цепочки словаря, плюс когда поиск дойдет до MYWORD он прихватит и его вложенные списки, потому что идентификатор слова, указанного для явного поиска его локальных слов, запомнен ранее.
В целом изложенное не столько предложение "давайте срочно сделаем так", сколько приглашение посмотреть на словарь с точки зрения общих соображений об организации структур данных. Вполне возможно, что и еще что-то интересное найдется.