Очень сложный вопрос

В любой FORTH-системе можно выделить 4 вида данных:
1. ПОТОК - FORTH-данные в текстово-файловой форме, читаемые интерпретатором и переводимые им во внутреннее представление.
2. СЛОВАРЬ - долговременная память, хранилище смыслов слов.
3. СТЕК - кратковременная память - служебная память интерпретатора и память универсального вычислителя.
4. ЗНАЧЕНИЕ - единица информации, передаваемая между ПОТОКОМ и СЛОВАРЕМ, при передаче между ими и СТЕКОМ существует, скорее, в ограниченной форме.
Это не обсуждается...

Вопрос в следующем: должна ли существовать некая "единица информации", которая служит единым "атомом" для построения всех 4-х видов, или, наоборот, все четыре типа должны быть полностью ортогональны, и речь должна идти не о преобразовании информации из одного вида в другой, а об обмене некими сигналами, информационная интерпретация которых полностью определяется своеобразием этих видов?

Пока пришел к следующему: FORTH, вообще не должен заморачиваться "типами данных". Есть только один тип - "действие". Данные в этом смысле - лишь внутренняя подробность реализации процедуры.
В случае, если требуется синхронизация по данным двух и более процедур возможны варианты:
1. Вы что-то делаете неправильно.
2. Нужен интерфейсный компонент (см. TF Броуди).
3. Данные передаются как адрес процедуры, их выдающей.

Например, в результате распознавания ПОТОКА я получаю ЗНАЧЕНИЕ, тип которого зависит от того, что распозналось: на стеке - адрес слова (если распознали слово) или значение (если распознали число), в словаре - само слово/число (если его не стерли в процессе распознавания), в переменных - флаг немедленного исполнения (для слова), положение десятичной точки (для числа)...
В случае слова все просто, настолько, что флаг немедленного исполнения не запихивается в переменную, а немедленно используется для ветвления.
А вот, в случае литерала, сложнее. Если число можно оставить на СТЕКЕ - ладно (оно уже и так там). А если его надо скомпилировать (передать в СЛОВАРЬ). Нужно анализировать ЗНАЧЕНИЕ, чтобы выбрать тип компилятора. Так, может, проще при распознавании передавать не составное значение, а слово, способное скомпилироваться само и это значение скомпилировать?
Сложность здесь только в том, что легко впасть в грех избыточной структурности/объектности и создать такой "конструктор слов", по сравнению с которым анализ значения будет меньшим злом, несмотря на потребность его переписывать для включения новых типов литералов.