<pre>
RuFIG Russia, 2008-2009
MultiStandard Forth (MSF)
Вольному Воля!
</pre>
1. Концепция-Манифест (KМ)
Свобода неистребима. Стремление писать по-своему было, есть и никуда не денется.
А по сему, данный Стандарт на Форт описывает не сам язык, а свободу программиста,
и рамки, в которых РЕКОМЕНДОВАНО ДЕЙСТВОВАТЬ, чтобы труд не пропадал впустую
и мог быть использован коллегами и будущим поколением.
По отношению к старым стандартам Форта, данный документ объявляет, что они никуда
не пропадают и становятся частями мультистандарта, о чем будет более подробно сказано
ниже. Программист имеет никем не ограниченное право использовать любой из имеющихся
"старых" стандартов.
Единственный требуемый шаг - соответствующее оформление программ, о чем
будет сказано в 4-м разделе.
Разумеется, в соответствии с главной концепцией свободы, программист может оформлять
свои программы ровно так, как ему хочется, писать хоть на папирусе, однако, в этом случае
он рискует остаться в одиночестве и забытьи со своими работами, чего мы никому не желаем.
Сложившееся на момент написания данного документа положение нас удручает,
поэтому мы и взялись за его написание, дабы не навести порядок, но указать возможную
дорогу к порядку и призвать программистов следовать рекомендуемому пути.
Форт, как и любой другой язык программирования, является инструментом программиста,
и содержание его в порядке является необходимостью.
Мы, форт-програмисты, нижеподписавшиеся, объявляем, что данный документ
может свободно распространяться, копироваться и изменяться с уведомлением об изменениях.
Подпись не обязывает программиста ни к чему, а всего лишь обозначает его согласие с данной концепцией.
Присоединиться (и подписаться) к данной концепции может каждый желающий. Присоединяясь и
подписываясь он всего лишь высказывает свое положительное мнение, но не берет на себя каких-либо
обязательств. Следование рекомендациям данного стандарта является делом сугубо личным и добровольным.
подписи:
WingLion 
1.1. Соглашения.
1.1.1. Документ изначально пишется на русском языке и может быть переведен на любой иной язык, в том числе с подходящим переводом терминов. Использование английского (а не русского) алфавита для написания программ, используемое в данном документе является лишь признанием исторически сложившегося стандарта de facto и ничуть не мешает программисту использовать свой родной алфавит для написания своих программ.
Английский алфавит (и язык) рекомендуется использовать только для достижения взаимопонимания в международной среде.
Форт бесконечно-расширяем, поэтому и стандарт для него должен быть расширяем, а не застывшим. Это значит, что стандарт должен предусматривать возможность добавления к самому себе дополнительных секций с описанием появляющихся в процессе развития вычислительной техники и программирования возможностей. Принципы добавления секций в стандарт - подобны принципам добавления новых слов в Форт. Секции добавляются в конец документа в соответствии с добавляемыми возможностями. Вклинивание добавлений в центр документа считать недопустимым, пока для этого не появится объективная необходимость.
2. Рекомендации по способам сборки Форта (ССФ)
Здесь будет рассказано, как с помощью этого документа и минимального ядра, описанного в следующем разделе, построить (скомпилировать) нужный программисту Форт-инструмент.
на данный момент еще не все ясно, поэтому здесь остается некоторый вакуум
3. "Минимальное" Ядро Форта (МЯФ)
Вопрос о самозарождении МЯФ-а оставим философам будущего,
а здесь просто опишем его и способ работы с ним.
3.1. реализация МЯФ
может быть любой.
Главное, чтобы оно исполняла свое предназначение - а именно быть первым инструментом,
с помощью которого строится все остальные инструменты и программы.
3.2. МЯФ является консольным приложением (или его имитацией в графическом интерфейсе), которое по своей сути должно быть целевым компилятором, целевая система которого совпадает или не совпадает с системой, на которой работает ядро. В случае совпадения - МЯФ является простейшим Фортом для этой системы с возможностью сохранения своего текущего состояния под новым именем. Исходный текст ядра должен компилироваться на самом ядре (и на его расширеных версиях за исключением особых случаев, когда расширение ядра превращается в новую программу и перестает исполнять первоначальную функцию МЯФ)
3.4. МЯФ должен уметь следующее:
a. компилировать самого себя по шестнадцатеричному (двоичному, десятичному) дампу (представление дампа - самое простое - последовательность чисел, соответствующих ячейкам целевой системы, разделенных пробелом);
b. сохранять скомпилированный код в виде отдельной программы (.exe файла или иного исполняемого в целевой системе файла);
c. работать подобно Форту с сокращенным набором слов (стандартов F83 и ANSI94) используемым для построения целевого Форта - Форта на целевой системе;
3.5. Сокращенный набор слов (слова надо еще четко описать, чтобы не было двусмысленностей и недопонимания):
<pre>
а. работа со стеком DUP, DROP, NIP, OVER, SWAP, ROT, -ROT и их аналоги для данных двойной ширины
b. работа с памятью @ ! MOVE <MOVE
c. работа с портами ввода/вывода (IN), (OUT) безотносительно к организации портов
d. ввод/вывод на консоль KEY, ?KEY, EMIT, TYPE
e. операции на стеке + - * / mod and or xor
f. комментарии ( .( //
g. строки и символы " ." C" S, C,
h. определение новых слов и компиляция : ; , C, S, CREATE DOES> VARIABLE CONSTANT VALUE TO IMMEDIATE
i. структуры управления IF THEN ELSE EXECUTE DO LOOP +LOOP BEGIN WHILE UNTIL REPEAT EXIT QUIT
j. работа со стеком возвратов >R R@ R>
k. работа с входным потоком INTERPRET - интерпретирует поданную на вход строку со счетчиком
(блоки из F83 отправляются в соответствующий модуль расширения)
l. минимальная работа с файлами
INCLUDE - переключение входного потока интерпретатора на файл
LOAD - загрузка в память файла в бинарном виде
SAVE - бинарное сохранение блока памяти в файле
более сложную работу с файлами следует делать через модуль расширения, зависимый от целевой системы.
m. вспомогательные и специальные слова слова INFO RESTART BYE
</pre>
Надо отметить, что в сокращенный набор могут войти и иные слова. Здесь указаны лишь те, что необходимы для дальнейшего построения данного документа и для сборки Форта по рекомендациям 2-го раздела. Возможно, некоторые слова и лишние. Иные могут быть выражены через друг друга и т.п. Здесь не обсуждается и не утверждается минимальная необходимость данного набора. Можно сказать, что этот набор - есть "реальность, данная нам в ощущениях" - кирпичики, из которых строится все остальное.
Опять же, никто не запрещает построить из этих кирпичиков нечто свое и использовать полученный набор вместо первоначального. Надо только, чтобы это построение было явным. Либо непосредственно в исходном тексте программы, либо в виде Модуля Расширения Форта, о которых будет сказано в 5-м разделе.
Форт бесконечно-расширяем, поэтому и стандарт для него должен быть расширяем, а не застывшим. Это значит, что стандарт должен предусматривать возможность добавления к самому себе дополнительных секций с описанием появляющихся в процессе развития вычислительной техники и программирования возможностей. Принципы добавления секций в стандарт - подобны принципам добавления новых слов в Форт. Секции добавляются в конец документа в соответствии с добавляемыми возможностями. Вклинивание добавлений в центр документа следует считать недопустимым, пока для этого не появится объективная необходимость.
Каждый Модуль Расширения Форта должен сопровождаться дополнительной секцией к стандарту или указателем на секцию (секции), реализацию которой он представляет.
Добавления секций к стандарту производится для каждой конкретной реализации Форта соответственно с реализованными в нем функциями. Если же в некой реализации Форта нет реализации функций некой секции стандарта, в документации для этого Форта должно быть указано, какие секции не реализованы и по какой причине.
В дальнейшем, в общий стандарт могут быть включены некоторые новые секции, которые станут стандартны "де факто".
Действительно, разбиение форт-системы на разумно-максимальное количество независимых модулей резко повысит привлекательность выполнения стандартов для отдельных разработчиков. Кстати, такому подходу и не противоречат альтернативные реализации одного и того же набора (например, словари, обработка исключений и прочие "проблемные" вещи могут подразумевать несколько реализаций). Стандартизованностью в Форте является скорее единообразность документирования возможностей, чем единообразность слов в словаре. В самом деле, сколько можно повторять, что в Форте легко делается что угодно, но тут же заставлять всенепременно называть слово так-то и так-то, и уж если появилось одно из набора, описанного в подпункте 123, то обязательно надо реализовать и все остальные.
