KPG писал(а):
За остальных не скажу.
Минус Форума - в вынужденной фиксации позиции по отношению к FORTH. Кого-то к этому вынудили практические соображения, кого-то - финансовые, кого-то, даже, честолюбивые... Не будем ворошить.
В любом случае это мешает восприятию FORTH, как метода:
Цитата:
В некотором смысле, наша программа превратилась в метаязык, описывающий язык, на котором написано приложение. Но метаязык термин для нас неподходящий. Мы тут не философией занимаемся. Для точного описания нашей ситуации двух уровней - язык и метаязык - не хватит, нужно не меньше четырех. Разделить их очень трудно. Кроме того, в различных случаях, встречающихся на практике, уровни могут перепутываться очень замысловато. /Мур/
Для понимания того, что я тут понаписал нужно принять два тезиса:
1. FORTH - лишь метод построения P-языка из A-языка, причем, самым простым способом.
2. В силу простоты и промежуточности существует некоторая "аксиоматика", требующая использования 4-х "источников" и 5-и "составных частей" [марксизма].
Т.о. в верной с узкой позиции "привычного FORTH" фразе:
Хищник писал(а):
Можно играть с Фортом в игру "удаляй привычные вещи, пока он не перестанет работать". Можно удалить стек данных - реализовать виртуальную регистровую машину. Останется ПОЛИЗ, останется интерпретатор, только числа придется сразу распределять по фиксированным регистрам. Можно удалить словарь как связанный список - заменить, к примеру, на деревья, массив слов или вообще произвольную разновидность БД.
- с точки зрения FORTH-метода все поставлено с ног на голову: не "удаляй привычные вещи", а "можешь добавить привычную реализацию".
Зачем так смотреть на FORTH-метод? Почему нельзя просто писать на FORTH?
Потому, что FORTH-языку противопоказано существование в окончательной форме (1) и "аксиоматика" FORTH, если ее не применять разумно приводит к отставанию от других языков (2).
Если же делать "все правильно", то можно получить достаточно большой выигрыш. Как в структурировании и управлении программой, так и в накоплении некоторого программистского опыта.
Например, притягивание задним числом "аксиоматики" FORTH к Лунолето-подобным задачам показало:
1. При наличии достаточно развитого A-языка, P-язык может писаться прямо на нем, с использованием от FORTH только "аксиоматики", но не "привычных решений". (Т.е. я еще раз убедился в том, что написание FORTH-систем под Linux - лишняя трата времени, в лучшем случае - дань привычке).
2. "Аксиоматика" FORTH, разумеется, практически изоморфна простым диалоговым программам (как никак, Мур для этого FORTH и изобретал), что требует дальнейшей ее формализации для достижения автоматизации проектирования.
3. В случае считывания ПОТОКА одной порцией СТЕК и ЗНАЧЕНИЕ становятся неразличимы.
4. Наличие в P-словарях не одного значения для слова, но объекта с несколькими точками входа (методами) требует не усложнения F-словарей, а упрощения (сведения словарей вторичных машин к таблицам).
5. В задачах такого рода потребность в способности КОМПИЛИРОВАТЬ практически устраняется компилирующими способностями процедуры ВЫПОЛНИТЬ. Что опять ставит вопрос о критической массе FORTH-машины, требующей выделения из нее вторичных машин. Что проще: КОМПИЛИРОВАТЬ СТЕКОВЫЕ структуры в словарь, или втюхать на это место еще одну FORTH-машину, ВЫПОЛНЯЮЩУЮ компиляцию?
6. Т.к. P-язык, в силу своей окончательности, достаточно плохо управляем, важной ролью F-языка является упрощение анализа и отладки. Это приводит к наличию второго временного P-языка - отладочного.
...