[quote="Victor__v"]А если при определении вложенного слова ставить на откат элемент списка поиска?[/quote]
Можно просто опускаться вглубь вложенных слов. Ведь по сути у каждого слова есть указатель на предыдущее слово в списке, и указатель на вход в список слов, определенных внутри него. И если мы еще не завершили текущее определение, то в процессе поиска просматриваем сначала именно его вложенные списки.

[quote="Hishnik"]
Если переменную STATE рассматривать не просто как переключатель режимов, а как счетчик уровня вложенности, ненулевое значение на входе в : позволяет понять, что мы имеем дело с объявлением вложенного определения. Это значит, что нужно скомпилировать переход вперед, и разрешить его ближайшим ; Таким способом можно вставлять вложенные определения, не нарушая этим последовательность команд.
[/quote]
Отличная идея со STATE.

[quote="Hishnik"]
Далее, проблема с поиском. NESTED должно быть видно внутри MYWORD и не видно снаружи. С другой стороны, раз уж оно есть, то можно попробовать искать его принудительно.
[/quote]
А если при определении вложенного слова ставить на откат элемент списка поиска?
Допустим верхний элемент списка находятся в VARIABLE X
Тогда условный код:
STATE @ 1 > IF X KEEP HEADER STATE 1+! THEN
Но тогда надо подумать над событием вызывающим откат.

ещё как вариант можно создать "мусорку" (временный словарь), где и будут хранится имена. И когда STATE будет равен 0 очищать временный словарь

Рассматриваем такой код

[code]: MYWORD
: NESTED
;
;[/code]

В целом оно не работает, потому что вложенное определение пытается встать в середину компилируемого кода. Кроме того, : должно быть IMMEDIATE и понимать, формирует оно верхний уровень или вложенный. Наконец, кто и как будет видеть NESTED? Хотя в целом локальные определения, в том числе с глубокой вложенностью - это нормальная практика в ЯВУ. В Форте ситуация слегка облегчается тем, что стековые манипуляции обходятся без явного именования объектов на стеке, однако при росте объема проекта иметь вложенные определения полезно.

Вложенные определения уже опробованы в кварке через механизм LOC[ ]LOC, который делает вставку новых определений, обеспечивая обход в коде сформированного куска. Возможен еще один вариант.

Если переменную STATE рассматривать не просто как переключатель режимов, а как счетчик уровня вложенности, ненулевое значение на входе в : позволяет понять, что мы имеем дело с объявлением вложенного определения. Это значит, что нужно скомпилировать переход вперед, и разрешить его ближайшим ; Таким способом можно вставлять вложенные определения, не нарушая этим последовательность команд.

Далее, проблема с поиском. NESTED должно быть видно внутри MYWORD и не видно снаружи. С другой стороны, раз уж оно есть, то можно попробовать искать его принудительно. Для этого можно посмотреть на конструкции Форта с более общей точки зрения. Например, словарь как таковой реализован как связанный список (linked list). Это не жестко привязанное к Форту понятие, а вполне независимая структура данных со своими свойствами. Связанный список удобен для Форта тем, что может хранить объекты разной длины, и поэтому заголовок слова + займет меньше места в словаре, чем заголовок слова THISISALMOSTMAXIMUMNAMEFORWORD. Тем не менее, нет принципиального запрета на использование для поиска, к примеру, обычной статической структуры, где для хранения имени будет выделяться максимально допустимое место. Это некоторая расточительность, но организовать поиск в таком массиве структур-описателей слов вполне можно, и даже чуть проще, чем в связанном списке.

Посмотрим теперь на структуры данных, которые "около" связанного списка. Например, может ли помочь дерево? В принципе, получается вполне красиво, потому что дерево, в котором каждый узел указывает на вышестоящий узел - это уже выглядит как просто связанный список. А если на узел указывает несколько дочерних узлов? Но тут намечаются проблемы с обходом этих дочерних узлов (сколько их? как до них добраться?), поэтому можно и чуть иначе - если на узлах основной ветке дерева имеются указатели на дочерние деревья? К примеру, если кроме LFA у заголовка словарной статьи есть еще дополнительное поле (хм, Nested Field Address и Child Field Address дают коллизии с NFA и CFA, так что надо подумать над именем), то у каждого слова появляется возможность держать указатель на вход в цепочку вложенных слов. Соответственно, эти слова игнорируются при поиске, если только они не принадлежат слову, компиляция которого идет в настоящее время. Кроме того, можно обеспечивать и принудительный просмотр вложенной цепочки - одной или даже всех. Например

:: MYWORD NESTED - здесь :: должно найти слово MYWORD и запомнить его в системной переменной словаря. Тогда при разборе NESTED будут просматриваться все имена "основной" цепочки словаря, плюс когда поиск дойдет до MYWORD он прихватит и его вложенные списки, потому что идентификатор слова, указанного для явного поиска его локальных слов, запомнен ранее.

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