О вторичных FORTH-машинах

Из старых записей:

Можно ли как-то классифицировать? Можно встретить толкования FORTH как:
- метода программирования - путем построения проблемно ориентированного языка;
- языка программирования, имеющего ценность самого по себе;
- системы программирования, делающей FORTH единственным инструментом пользователя компьютера;
- виртуальной машины, что бы это ни значило;
- "транслятора" (видимо, некоторые фортеры считают, что FORTH - не FORTH, если он не создает исполняемые файлы);
- философию (чем она отличается от "метода", я не понимаю).

С точки зрения реализации вариантов тоже много:
- создание специального FORTH-железа и написание FORTH на нем;
- написание FORTH на голом железе - вместо ОС;
- написание FORTH в рамках существующей ОС;
- написание FORTH на языках высокого уровня;
- использование FORTH-методов в программировании на других языках.

Я, как мог, открестился от большинства этих "уклонов", но вдруг..?
Не могу же я отрицать того факта, что FORTH-идеи могут благополучно существовать (реализовываться) и на других языках/системах.
Это Мур был вынужден писать свой "создатель языков" на голом железе. Теперь мы можем с комфортом использовать для этого, например, создатели лексических анализаторов и компиляторы компиляторов.

И еще: ТЕМА #30, АБЗАЦ #517, ТЕМА #11, АБЗАЦ #2234

Потом я перефразировал так: в единую FORTH-систему можно и часто нужно (см. ТЕМА #64) объединять несколько FORTH-машин, отличающихся реализацией своих компонентов.

Кстати, применение механизма вторичных FORTH-машин позволяет обходится вообще без "стандартного FORTH". Ведь, то, что не может сделать одна FORTH-машина, вполне может восполнить другая...

Тут, на днях, опять всплыла старая задачка о перелопачивании GIF-файлов под мои потребности. Достал свои старые исходники и понял, что строить в голове полную модель GIF-библиотек, чтобы найти ту пару-другую функций, что мне тут нужны, будет стрельбой из пушек по воробьям. Решил быстренько переписать, разве что, подсматривая в старые таблички.

Писал на C.
Минусы программирования по Forth-овски на C очевидны:
1. Цикл диалога с программой включает перекомпиляцию.
2. Использование нетривиальных программных конструкций (например, сопрограмм) требует лишних переменных.
3. И с точки зрения С это часто выглядит неопрятно. Многие "углы" хочется "спрямить".
Зато, нет необходимости в поддержке стека и шитого кода.

Итак, первая подзадача - считывание GIF-файла в память. Как все знают, внутри этот файл разбит на фрагменты, каждый из которых начинается с буквы, обозначающий тип (от типа зависит размер обязательных заголовков фрагмента и способ хранения данных).

FORTH-машина считывания gif-ов должна начать работу в состоянии, когда из файла удается выдернуть "знакомые буквы", а закончить, когда я вспомню все форматы и смогу распознать все, что нужно:

ОК - чтение из файла
СИМВОЛ - первая литера фрагмента определяет его тип
ВЫПОЛНИТЬ - нахождение нужного распознавателя по первой букве
КОМПИЛИРОВАТЬ - развернуть фрагмент в словарь блоков
СЛЕДУЮЩИЙ - цикл вокруг чтения из файла

Достаточно быстро удалось вспомнить, что эта машина должна знать всего четыре слова - ЗАГОЛОВОК, КАРТИНКА, РАСШИРЕНИЕ, КОНЕЦ. Причем, способы хранения информации в этих фрагментах достаточно универсальны. Скормив этой машине несколько разных GIF-ов, быстро разобрался, что каждый "гиф-редактор", добавляет в них мусорные РАСШИРЕНИЯ по своему вкусу. На радостях выкинул из машины весь диагностический вывод.

Однако, дерево разбора получилось сложноватым и я для него зафигачил вторую машину:

ОК - выбор строки команд-букв
СИМВОЛ - буква-операция (цифра - параметр следующей команды)
ВЫПОЛНИТЬ - перемещение указателя блоков и сбор данных из них
КОМПИЛИРОВАТЬ - пока хватит букв
СЛЕДУЮЩИЙ - перебор букв в строке

Теперь, например, я могу добраться к палитре второго рисунка в GIF-е, введя что-то вроде: "RC,N,B". Правда, останавливаться на возможности присваивать новым буквам последовательность старых (этакая кривенькая реализация "двоеточия") было уже некогда.

Тогда посмотрел на первую машину и, т.к. все цифры были уже налицо, понял, что операция обратной записи в файл описывается простенькой таблицей (ведь, способы хранения данных, как я писал выше, для разных фрагментов достаточно универсальны). И команда печати блока получилась сама собой. Гордо послав последовательность команд "RPCPNP;", получил копию простого GIF-а в новом файле.

Кстати, зародыш стека во второй машине, все-таки, присутствовал - в виде числового префикса повтора команд.

Т.о. без всяких ВФМ, за пару часов, я получил методом постепенного приближения и борьбы со склерозом, программу разборки/сборки файлов. Кстати, если бы начал писать на C честно, то, наверняка, еще бы потерял время на LZW. Но. т.к. тупо, по сути, отвечал на вопросы программы, то вовремя вспомнил, что оно мне пока без надобности...

Как-то так...

Были еще какие-то наметки про FORTH-образную работу на уровне диалога с ОС, но их пожую позже - во втором томе "заметок о простых играх".

Еще из старого:

Наверное, все-таки, если мы хотим понять, зачем все это надо, надо показать отношение FORTH к вечным программистским ценностям. Попробуем, например, перечитать самую, пожалуй, судьбоносную для программирования работу Дейкстры:

СТРУКТУРНОЕ ПРОГРАММИРОВАНИЕ И FORTH

Полностью статью "Заметки о структурном программировании" приводить не буду. Либо вы программист и ее читали, либо - вы не программист...

В первых главах Дейкстра формулирует проблему, которая, подобно учению Маркса, успешно отрицается обществом, и, тем не менее, служит определяющим законом нашей вселенной. Проблема эта - в безусловном росте сложности (и падении надежности) программы с увеличением ее размеров.

Поэтому и возникло понятие "структурного программирования" - как попытка писать/анализировать/управлять программой "по частям" - а не как единым, обычно необозримым, целым.

При чем тут FORTH?

Он, во-первых, немного отодвигает границу сложности - сводя к минимуму обязательную избыточность языков программирования. Ни одна синтаксическая конструкция в FORTH-языке не является необходимой. Никакие требования что-то заранее определить, ограничить скобками, строго указать тип, использовать стандартные заголовки - ничего. За счет этого программа, содержащая только "путь решения задачи, как мы его понимаем" потенциально может быть короче, а значит, проще.

Во-вторых, FORTH предлагает программисту самому изобрести язык на котором он будет решать задачу, что, если и уменьшит сложность программы, то, возможно, улучшит ее понимание и/или структурность.

В-третьих, не надо забывать, что Мур изначально предлагал убрать из программы логику, которая будет думать за пользователя - программист только дает тому "управляющий язык", а управляет и, соответственно, принимает решения сам пользователь. Такой подход, разумеется, сокращает программу. (Надо отметить, что втихаря этот метоод используется в визуальном программировании - "вот тебе окно с кнопочками - сам думай, что нажимать", но, т.к. визуальные "программисты" не умеют писать языки, ничего хорошего из этого не выходит).

Самое популярное структурное предложение Дейкстры - разбить программу на блоки с одним входом и одним выходом, казалось бы, в FORTH принимается без проблем - слово является идеальным блоком. Однако, здесь мы сталкиваемся с непониманием идеи Дейкстры. Разбиение на блоки - не самоцель, но необходимое средство для того, чтобы "позиция в листинге программы полностью определяла состояние программы" (см. подробнее в работе Дейкстры "Дисциплина программирования"). С этой точки зрения FORTH так же беспомощен, как и все "языки высокого уровня".

Возможно, для понимания того, как научить свой FORTH быть структурным, надо немного вернуться - от "машины Мура 1970-го" до "машины Дейкстры 1962-го".

Мое самое любимое место этой статьи - представление программы в виде бус из машин-жемчужин. Красиво и очень похоже на FORTH.

Надо только помнить, что эти бусы растут не "вдоль", а "вглубь". Не как слова в определении, а как FORTH-лексиконы.

Мы видим, что именно FORTH может позволить сделать машины-жемчужины воистину "машинами", а не "уровнями абстракции, подчиняющимися все тем же правилам одного и того же языка". Сколько бы мы не писали на C++ проблемно-ориентированных языков, мы все равно можем написать только C++. На FORTH же это могут быть практически независимые друг от друга машины. Машины в полном смысле этого слова.
Возникает даже вопрос: насколько эти машины должны быть FORTH-подобными - самостоятельными (т.е. нужна ли им процедура СИМВОЛ, Цикл Управления...)?

Наконец, приведенный в конце статьи пример "про ферзей", показывает как то, что какие-то FORTH-концепции ложатся на псевдокод идеально (например, именование отдельных конструкций), а какие-то - не очень. Так, концепции массивов (хотя, как показано в примере, массивы тоже надо использовать с умом) FORTH-языку чужды, и чем тупо писать лексикон, оборачивающий обращения к массиву в слова, проще добавить, если нужно, машину массивов (выделение памяти, адресные и базовые регистры...) к FORTH на уровне A-машины.