in4 писал(а):
Для решения этой проблемы есть еще один путь!
Ваше решение мы уже разбирали: избыточность получается больше - вместо согласования по переменным получаем необходимость согласования по словарям - нужно добавлять слова параллельно в оба словаря. Представьте, что имеется ряд слов, запускающихся в обоих режимах - подобных LITERAL, S", MAKE - и Вам постоянно надо помнить, что они имеют зеркального брата-близнеца.
Кроме того, перепрыг в режиме компиляции из IMMEDIATE словаря в компилирующий тоже нетривиален, а, в случае наследования словарей - и геморройный.
И, кстати, если Вы будете использовать унифицированный NUMBER и там, и там, компилирующая обвязка займет ровно столько же места:
Код:
стандартно:
NUMBER STATE @ IF НУЖНЫЙ-LTERAL THEN
у Вас:
исполнение:
NUMBER
компиляция:
NUMBER НУЖНЫЙ-LTERAL
Поиск НУЖНОГО-LITERAL все равно остается...
А если использовать разные NUMBER, то избыточность только увеличится. Как я писал, вершина словаря большую часть времени работы NUMBER занята и, все равно, все придется конвертировать на стеке...
P.S. В моей терминологии: если обычная FORTH-оптимизация - засовывание процедуры ВЫПОЛНИТЬ внутрь процедуры СИМВОЛ, то Ваше предложение - засунуть СИМВОЛ внутрь ВЫПОЛНИТЬ. Что в лоб, что по лбу.