Зарание прошу прощения, у меня получился очень длиннопост. Прошу понять и простить - кроме всего прочего, это попытка осмыслить и структурировать сведенья о технологии форт, и найти её место в моей программной практике.

Первое что хочу отметить, что "FORTH 2k-32" скорее всего сильно бы отличался от того, классического форта, о котором писал Мур в своих "*ing forth".

Дальнейший текст сугубо субъективен, и основан на моём личном виденьи форт-подхода и форт-системы, которое, в свою очередь, сформировалось при прочтении книжки Баранова и Ноздрунова "Язык Форт и его реализации" и непродолжительного лурка по этому форому и некоторым смежным ресурсам. С другой стороны - я был бы рад выслушать мнение бывалых фортеров на счёт этого мнения.

Defining Forth
Что же такое форт?

1. Это подход к проектированию приложений, который заключается в организации систем как совокупности довольно независимых компонентов взаимодействующих через простую и достаточно мощную структуру данных. Это обстоятельство роднит его с другим семейством языков - лиспом.

Можно сравнить мелькающее на этом форуме мнение "что-то строили, строили, оп: форт получился" с крылатым среди лиспером десятым правилом Гриспена: "Любая достаточно сложная программа на Си или Фортране содержит заново написанную, неспецифицированную, глючную и медленную реализацию половины языка Common Lisp." (К которой частенько добавляют строчку вроде "В том числе и каждая реализация Common Lisp".

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

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

Кроме того, форт, своей диалоговостью позволяет очень просто отлаживать, тестировать и профилировать только что написанные подсистемы как в контексте всей системы, так и отдельно от неё.

3. Открытая реализация. Если уж писать стандарт на форт, то первая его строка должна гласить: "каждая реализация языка форт должна сопровождаться предельно чёткой документацией описывающей все детали реализации системы". Свобода изменения системы под конкретную задачу, причём на лету: это невозможно назвать иначе, нежели Killer feature.

4. Форт - это живое воплощение принципа Кисс, или бритвы Окама, если хотите. Минимум телодвижений, направленные на максисмум достижения результата.

Treading Forth

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

Causing Forth

Мур писал программы для 16битных систем. Ну небыло у него даже самого завалящего атома, не говоря уже о каких нибудь кор-ай-семь. Мур писл программы, которые должны работать без операционной системы. Ну не нужна была ему ось: его программы не делили жизненное пространство с другими. Мур писал, придерживаясь простоты кода. Писал, писал, и... получился форт. И от того, древнего, Муровского форта система наследует кучку детских болезней.

1. Нечитаемые слова. Да, я понимаю, что команды вроде '@', ',', '!', '/mod' и прочие 2dup легко вводить, и, если словить систему, их в принципе можно запомнить, но... есть способ понять отличие roll от rot при чтении исходного кода, не заглядывая в справочники? А как же преславутая самодокументируемость кода?

2. Хитрые трюки. Да мне тоже нравиться форт за открытость и простоту реализации. Да, я ненавижу, когда кто-то решает за меня, что мне делать с компьютером. В конце концов - программирование, эт интимный процесс. Да, я тоже считаю, что язык, программами на котором не возможно наглухо повесить систему двумя десятками разных способов - недостаточно мощный. Но, блин, форт - это же просто рассадник хитрых трюков. Если в других языках понимание глубинных принципов реализации и способность к хитрым хакам - это показатель нетривиального уровня программиста, то для фортера - это воздух и, часто, единственная возможность наростить функционал

3. Отсутствие локальных переменных из коробки. С нормальными локальными словариками. Нуф саид.

4. Странная-странная область видимости относитально словарика. Пока слово есть в словаре, изменение этого слова должно затрагивать все его вхождения.

5. Ориентированность на статическое распределение памяти. Да, когда то это было нормой. в отличае от динамической памяти. Но сейчас с реализацией 'HERE','ALLOT' и ',' могут возникнуть проблемы.

Styling Forth

Что у нас в сухом остатке?

1. "FORTH 2k-32" должен быть в первую очередь методическим пособием по программированию масштабируемых и относительно переносимых систем. Книжечкой, вроде упомянутой выше Баранова и Ноздрунова. И уже во вторую - програмным обеспечением.

2. Система "FORTH 2k-32" должа быть модульной в плане реализации - при необходимости допускающей изменение реализации любых компанент - словоря, стеков, интерпретатора. (По крайней мере стремиться к этому)

3. Ядро системы - компилятор-интерпретатор, словарь, стек должны быть в тревиальной реализации предельно простыми и допускающими реализацию на целевой системе за считанные дни. При этом должны быть достаточны, для расширения до полноценной системы за счёт кода на языке форт. Как бонус - реализация такой форт-системы на произвольном языке программирования фактичкски сразу сделает возможность наращивание мощности форт-системы средствами этого языка.

Т.е. сборка форт системы имея в наличие только книжку и ассемблер целевой платформы должна быть доступна в четыре этапа:

а. Создание на ассемблере целевой системы ядра форт-системы.
б. Расширение созданной системы форт-текстом из книжки
в. Написание оптимизирующей системы сборки форта для целевой платформы
г. Пересборка форт-системы средствами форт.

4. Интерфейсы памяти внутри форт-системы должны скрывать механизм реализации соответствующих модулей (статическое выделение или динамическое распределение памяти). Сдесь кроеться самая большая засада для меня. Опишу её наверное в сноске. *

5. Словарная статья должна иметь представление о типе хранимых в ней данных. При этом хранение адреса собственного интерпретатора строго говоря не обязательно.

6. Словарная система вообще должна быть заметно переработана. Механизм текущий словарь/контекстный словарь должен быть ликвидирован как неочевидный. Должна быть реализована система глобальный словарь/стек локальных словарей/оверлейные словари-пространства имён. Словарные записи должны иметь произвольный доступ, а не стековый (forget не должен забывать одну запись а не всё, определенное после)

7. Все словарные статьи для исполняемых слов форта (мы помним, что новый словарь может хранить константы и переменные, а не только исполняемые слова) должны быть векторизованы. И должна быть возможность (не связанная с гениальнымструктурным хаком системы) строить цепочки обработчиков. Например - выделить часть функционала интерпретатора (обработка/вырезание комментариев, построение документации по типу Doxygen, удаление переносов сторк) в препроцессор. Не знаю как у вас, а я с момента первого прочтения о работе слова '(' мечтаю о комментариях, которым не нужен пробел после скобки.

Вот, что то вроде того.

*. В общем, я могу представить реализацию словарей и стеков с одинаковым интерфейсом как для динамической так и для статической модели памяти.

Однако, подходящий интерфейс для получения блоков памяти на замену 'here'-'allot'-',' я пока, к сожалению, представить не могу. Использование динамического интерфейса типа alloc-free (или, если хотите new-delete) фактически обяжет реализовать heap для любой системы, кроме того - возникают проблемы с компиляцией тел слов программ, ведь в начале компиляции неизвестно, сколько памяти займёт результирующий код. Применение классического, стекоподобного интерфеса наоборот - сложно в реализации через хип.

Трюками форт дышит.
Форт он, ведь как, позволяет вся лишь бы было понимание.
Нестандартные структуры управления? Не вопрос, имеется стек потока-управления ( стек данных в режиме компиляции)
Стек для хранения данных. Хорошее решение. При этом данных-то надо не так много.
Редко когда доходит до пяти-шести. А все dup swap over pick применяются не так часто.

Кстати, просто интересно
Допустим надо сравнить часть строки со строкой длинной 4 байта
Вместо того, чтобы писать 2dup s" xxxx" compare
Можно написать так over @ [ s" xxxx" drop @ lit, ] =
В каком языке ещё можно так "преобразовать" типы?
Ест-но ассемблер не считается

На си же =).



На самом деле язык Си более мощный, чем язык Форт. Любой трюк на Форте можно тем или иным спососбом реализовать на си, за исключением разве что динамического изменения синтаксиса языка.

А ещё - на самом деле любая программа на си содержит хорошо документированную, быструю и отработанную, но неспецифицированную треть языка форт =). В любой программе на си существует стек возвратов. Параметры в функции (аналоги слов) передаются в стеке возвратов. Локальные переменные хранятся в стеке возвратов. Если ошибиться с рекурсией стек возвратов пробьёт небеса и программа вывалиться в валхаллу.

Даже на паскале, в принципе такое возможно, но там придёться обходить встроенную защиту указателей. Ненавижу за это строго типизированные языки.

На little-endian не будет работать.

Зато будет работать из коробки на 16-битных big-endian системах.

Я думаю обсуждение вопроса переносимости отдельных хаков, тем более выполненых не на форте, несколько неуместно в данной теме.


Я тут подумал, и пришел к выводу, что в, общем случае, типизация словарика нужна форту как собаке пятая нога. Прошу исключить этот пункт из стандарта FORTH2k-16.

Просто подобный механизм нужен мне. Вот и просочилось. Извините.


Ну, я же не предлагал забрать у программиста хитрые трюки. Даже более того: предложил разнообразь механизмы, с помощью которых можно их реализовывать. Это позволило бы сделать хитрые трюки проще и понятнее.

Открою всем секрет
Стек возвратов есть только в форте.
Во всех остальных языках программирования есть просто стек Ибо он один ( для архитектуры х86).
В расчёт не берётся стек для чисел с плавающей точкой
Это вот в форте придумали исчо стек данных. По факту, массив, на последний эл-т которого указывает регистр.
EBP, EAX и т.д.
Без всяких специальных слов для стека ( pop push), короче какой-то неполноценный стек
Хотя на Сетуни форт был бы ого-го


Что плохого в переключении контекста? Даже стандартные слова [ ] переключают контекст
А так, допустим, увеличим кол-во возможный операций над стеком возвратов. Напишем слова-переключатели словарей
R[ ]R

Это легко устроить.
Пишешь обработчик
Типа:
: (???) ( addr u -- adrr u 0| -1 )
over c@ [char] ( =
if
2drop
begin
nextword
dup 0= if \ пустая строка?
[ 2swap 2dup ]
2drop
refill
again
then
dup 1 = >r over c@ [char] ) = r> and invert while \ пора заканчивать?
2drop
repeat
2drop
-1
else 0
then
;
Вставляешь полученный обработчик в notfound и радуешься жизни

Это специфичное для SPF решение, если я правильно понимаю. При построении собственной реализации форта придётся либо копировать такую реализацию, либо явно указать считать все слова, начинающиеся на '(' синонимами слова '('. На какой либо третьей реализации подобное решение вообще может не сработать.



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


По факту - специальная область памяти с определенными методами доступа. Кроме стека и массива такая структура может содержать хэш-таблицу или очередь (в виде кольцевого буффера). Строго говоря тот самый, основной стек 80x86 тоже массив, на верхний элемент которого указывает SP (ESP).


Собственно говоря ничего. Я предложил на замену более развитый механизм, с большим разнообразием контекстов. Просто реализация этого механизма в форт неочевидная. Вот в чем разница между "контекстным словарём", и "текущим словарем"? Как можно уловить эту разницу из смысла слов "контекстный" и "текущий"?

Notfound полезная вещь. Если в словаре ничего не найдено, то вызывается нотфоунд. В СПФ на него возлагается работа с литералами
Относительно стеков.
Их может быть уйма.
Только сколько надо?
Можно верхушку каждого стека зарегистрить.
А в дальнейшем кой в этом смысл размножать стеки для исполнения программ?
Интерпретация ладно, это святое
Но когда слово уже скомпилировано, это стековое многообразие явно лишнее
Да и вопрос не в реализации, допустим, 3-х стеков на Сях. Вопрос, как её там, в аппаратной поддержке стека.
Ну в х86 один стек, ничего с этим не поделать ( float не считается).
В Сетуни-70 2 стека. Там бы форт работал быстрее за счёт двух-стековой модели



Короче, по факту просто массив

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

Если рассматривать вообще систему в целом, то у каждого процесса в рамках операционной системы как минимум один стек реализуется через этот аппаратный механизм, а ядро ОС переключает эти стеки в рамках переключения процессов. Да и в ядре собственно, наверняка есть собственный. Так что тут бабушка надвое сказала, сколько стеков в x86.

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

Если мне придётся на си парсить по очереди два файла в формате html, xml, json etc. То я организую отдельный стек для каждого файла. В котором буду хранить текущую позицию во внутренней структуре. Вот как то так.

О каком лиспе идет речь? Т.к. начиная с лисп 1.5 (с 1962) чистые интерпретаторы практически не используются. В общем, любая реализация лиспа содержит множество разнообразных стеков, большинство из которых скрыто от пользователя.

О лиспе, как обстрактной математической модели, скорее всего =).

Те три-четыре реализации лиспа, которые я копал в исходных кодх, были в той степени вариации на тему металиспа описнного в sicp: входной поток синтаксическим анализатором преобразуется в бинарное дерево, построенное из пар (cons), которое итеративно упращается.

Так устроены например Mini- и TinyScheme, Ksi, picolisp.

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

sicp - скорее сборник рецептов для скаутов, т.е. она сгодится только для изучения основ. Вам же я могу рекомендовать "Lisp in Small Pieces" (есть перевод на русском), пусть она будет вашим источником вдохновения, а не руководством к действию. Могу еще что-нибудь подкинуть по интересующим вас темам.

ИМНИП, picolisp только в 90-е был "чистым" интерпретатором, сейчас же он содержит компилятор в машкод. Да, и тогда он имел компилятор, только в промежуточный код, который представлял собой список с командами виртуальной машины.

К лисп процессорам я отношусь скептически, т.к. овчинка выделки не стоит.

Кстати, я еще в прошлом году реализовал свою старую идею фикс - конкатенативный лисп с полноценным сборщиком мусора. Лисперам и фортерам он навряд ли окажется интересным, т.к. эти два лагеря уж больно консервативны. Но лиспостроителям, как и всяким любителям эзотерики, я думаю, он придется по вкусу. Так что если кому интересно, то можете спрашивать.

Вот это "еще" вызывает улыбку Вы знакомы с другими работами (в т. ч. теоретическими) в этой области? Пробовали ли получившийся инструмент в деле? Чего не хватило на практике?

А что именно вас рассмешило? Сам интерпретатор изначально был реализован мною на схеме, но затем был переписан на Си. У меня дома еще куча программ требующих переписывания с лиспа на языки мейнстрима.

Да, я в курсе дела.

Каждая попытка применения его на практике у меня вызывает желание что-то поменять, изменить. Если раньше он был похож на joy, cat, то сейчас он представляет что-то более самобытное. Может примеры кода?