gudleifr писал(а):
Без STATE...
Доводы против:
1. Есть много слов , использующих STATE, - значит придется каждый лексикон делить на три части: 0-STATE, 1-STATE И ПОФИГУ-STATE. Т.е. держать лишние переменные и связи в системе словарей.
2. Компиляция состоит не только из честных вызовов ":" и ";", но из ИСПОЛНЕНИЯ кучи компилирующих слов и макросов. Уберешь проверку STATE из основного цикла - добавишь лишние проверки IMMEDIATE в цикл компиляции.
3. В общем случае, значений STATE может быть любое потребное число. Причем, это число будет зависеть от типа машины. Применяя машины без STATE, придется размножать однотипные машины.
4. Forth-машина "сама себя пишет". Разделив ее на две, получим машину, которая "не пишет" и машину, которая пишет "и себя, и подругу". Т.е. новые проверки типа "куда пишем?" Тогда уж - три машины: "не пишет", "пишет себя", "пишет другую"... Но, пардон, кто будет "писать третью"?
1. Да, но каждое слово получится проще и возможно повторное использование некоторых.
2.
IMMEDIATE , как и проверка не нужна, т.к. состояние
STATE (проверка состояния) заменяется соответствующим кодом. Вместо if(STATE)A else B будет выполняться A или B, причем какое из них, определяется заранее соответствующим интерпретатором (устанавливающим порядок просмотра словарей). Т.е. проверки не в каждой точке, а заранее на все слова
3. Да. Да. Это плохо?
Они же будут проще и возможно повторное использование кода.
4. Не обязательно. Могут "писАть" друг в дружку. Это как раз больше похоже на вашу идею вторичных машин. В моей реализации со словарем работают обе машины, я специально не выискивал, кто пишет, а кто нет. Обе могут. И третья, если будет, тоже может. Хотя, есть примерчик, где 5 машин - одна запускающая и 2 пары Форт-системы с разнесенным циклом компиляция-интерпретация. Только памяти не хватило, чтоб словари разнести, пришлось накладывать, что и вызвало трудности. Когда в 64Кб размещены почти 3 Форт-системы с кодом x86 - места маловато...
Поэтому и захотелось вторую систему...