О чем "на самом деле" говорил Мур?
Сначала, о словах-паразитах. Можно заметить, что, если в первой части книги Мур употреблял термин "проблемно-ориентированный язык", то во второй он обсуждает больше "виртуальную машину". В принципе, отличие только в том, что "язык" связан с выполнением слов из входного потока, а "машина" - с выполнением слов шитого кода. Т.е. в терминах самого Мура - вся разница в замене подпрограммы NEXTW на NEXTI. Причем, большинство полезных идей Мура связано именно с "языком", а "машина" лишь позволила ему более "программистски" обсуждать некоторые частные проблемы. Поэтому термин "виртуальная машина" предлагаю более не употреблять, тем более, что его всяк понимает по-своему. Второй паразит - слово "контекст". Сам Мур его не употребляет, но искушение при помощи этого слова объяснить то, что сам плохо понимаешь, очень велико: контекст исполнения против контекста компиляции, контекст цикла, контекст порождаемый словарем... Бесполезность этого слова явно следует из того простого факта, что сам Forth ни о чем подобном не догадывается. "Контекст", влияющий на выполнение подпрограммы, это отражение того факта, что подпрограмма может быть вызвана из разных мест и/или некоторая переменная-флаг имеет разные значения. Сам же термин, подобно "машине" слишком уж многозначен, поэтому его тоже предлагаю избегать.
Так, что же изобрел Мур? Главная идея - написать простую программу, которая будет сложно работать, т.к. оператор сможет вводить сколь угодно сложные последовательности команд. Как калькулятор. Какими качествами должна обладать такая программа? 1. Язык команд оператора должен быть ориентирован на проблемную область, чтобы оператор мог, действительно, сделать что-то полезное. Мур назвал такой язык языком управления. 2. Чтобы оператор не повторял ввод длинных команд, язык команд должен содержать команды, при помощи которых он мог бы расширяться новыми командами, составленными из уже имеющихся. Такой язык Мур и назвал проблемно-ориентированным. 3. Очевидные программистские порадигмы: операторы присваивания, переменные, параметры подпрограмм совершенно не нужны ни оператору, ни интерпретатору. И гораздо проще оставить их лишь в потенции, разрешив оператору создавать их самому. Вот, собственно и все. Всякие стеки и шитые коды - это лишь частное решение проблемы. Общего решения Мур так и не представил, начав радостно экспериментировать с моделью, как только она заработала. Нерешенными Муром остались, по крайней мере, две проблемы. 1. Насколько принципы построения пользовательских программ-макросов могут быть расширены "внутрь" для построения внутренних Forth структур. 2. Насколько Forth может быть самодостаточным? Например, Мур рассматривал создание слов в кодах компьютера как крайнее средство ублажить оператора-извращенца. Гораздо легче, по его мнению было расширить нужными машинными кодами изначальный язык управления и перекомпилировать программу.
Откуда взялись стек и шитый код, предложенные Муром в качестве "самого простого решения", совершенно непонятно. Очевидно, эти идеи витали в воздухе. Более того, Мур так и "не заметил", что эти структуры очень схожи, хотя пару раз этим сходством и воспользовался.
Сравним с другими системами программирования: 1. BASIC. Здесь явный перекос в сторону языка управления. Реализован набор операций, практически полностью удовлетворяющий потребности пользователя по управлению компьютером. Язык же определения новых подпрограмм очень убогий. Вложение одних подпрограмм в другие реализовать практически невозможно. 2. C. Язык создания подпрограмм прекрасно сбалансирован с элементарным языком управления. Все нужные расширения языка сгруппированы в библиотеки. Но возможность оператора писать свои программы и развивать язык отсутствует. Все поведение программы определяется программистом. 3. LISP. Язык является саморасширяющимся в гораздо большей степени, чем Forth. Он сам на себе и написан. Но его атомарные команды очень сложны и ресурсоемки. Доступ к возможностям машины практически исключен: ограничен возможностями виртуальной машины (вот здесь этот термин применим в полной мере).
Реалии сегодняшнего дня. 1. Во многом устарели выводы Мура, основанные на возможностях тогдашних компьютеров. Сейчас желание вместить ядро системы в 4k слов может посетить только редкого ПЛИС-оведа. Тоже можно сказать о желании сэкономить пару-другую инструкций в основном цикле программы. Поэтому так и надеются фортеры на свою востребованность в мире маленьких электронных фигулек, вместо того, чтобы развивать Forth-принципы, применимые в большом мире. 2. Отвращение современных программистов к машинам с хранимой программой еще больше, чем у Мура. Если тогда это было трудно технически, то теперь - психологически. 3. Самой страшный удар по концепции проблемно-ориентированного языка нанес переход к оконным приложениям. Если в те времена консоль была естественным средством общения оператора с машиной, и наличие языка управления считалось облегчением операторского труда, то теперь консоль надо эмулировать, а оператора приучать набивать слова вместо нажимания на красивые кнопочки. Расширение входного потока до управляемого событиями асинхронного монстра никем из фортеров серьезно не рассматривается. 4. Появление "новых" парадигм программирования - ООП, процессов, управляемых данными, многопоточных, генетически модифицируемых... время от времени подвигает фортеров на какие-то телодвижения, но, вместо новых Forth-решений, мы видим написанные на Forth эмуляторы чужеродных механизмов. Впрочем, пусть меня поправит тот, кто читал свежие статьи Мура.
Выводы. Если сравнить описанную Муром систему с моим определением Forth, можно видеть: 1а. Возможность построения языка сколь угодно высокого уровня имеет место и там, и там. 1б. Возможность прямого доступа к железу Муром допускается только в случае крайней необходимости. 1в. Простота и там, и там во главе угла. 2. Окончательность какой-либо версии Forth Муром тоже отрицается, но до целевой компиляции он, вроде бы, не дошел. 3. Ни о каком стандартном наборе слов Мур не говорил, считая, что все, что не нужно в процессе функционирования ядра, должно добавляться только по желанию оператора.
Т.о. Общее устройство Forth можно представить следующими блоками: 1. Интерпретатор 1.1. Цикл управления 1.1.1. Получение слова 1.1.1.1. Организация входного потока 1.1.1.2. Парсирование входного потока 1.1.1.3. Ввод слова из шитого кода 1.1.1.4. Другие источники 1.1.2. Поиск кода 1.1.2.1. Алгоритм поиска 1.1.2.2. Распознавание литералов. 1.1.3. Обработка кода 1.1.3.1. Исполнение 1.1.3.2. Компиляция 1.1.3.3. Другое 1.1.4. Другие контрольные точки цикла управления 1.2. Слова необходимые для интерпретатора, вызываемые не им, но на общих основаниях. 1.2.1. Управление словарными статьями 1.2.2. Компилирующие слова 1.2.3. Обмен данными 1.3. Интерфейс с ОС 2. Стандартный набор слов 2.1. ANSI94 2.2. Ассемблер 2.3. Консоль 2.4. Элементы ОС 3. Полезные алгоритмы 4. Полезные концепции
Последний раз редактировалось gudleifr Пн мар 19, 2012 22:48, всего редактировалось 2 раз(а).
|