Успех языка программирования определяется не только его возможностями, но и экосистемой — наличием хороших IDE, отладчиков, библиотек и других инструментов разработки. На этом фоне Forth стал терять свои позиции даже в традиционно родной сфере embedded.

Я вижу проблему не только в технологической революции, но и в деградации стандарта Форта, когда с 2012 года комитет не продвинулся в улучшении архитектуры, тем самым язык для потенциальных программистов стал менее привлекательным.

Под псевдонимом AbstractionFirst я предложил ряд изменений комитету по стандартизации, но они даже не поняли, о чем идет речь. Давайте разберем тему по шагам.

У русских есть удачное выражение “кишками наружу”. Вот Форт сейчас как раз выглядит в таком неприглядном виде.

Во-первых, слово BASE.

API у BASE — неудачный: он выражен через адрес переменной. Почему стандарт по-прежнему раскрывает представление основания системы счисления как адрес изменяемой ячейки памяти, вместо того чтобы стандартизировать операции чтения и изменения этого свойства?

Стандарт стандартизировал реализацию, а не контракт. А как должно было быть в идеале? Стандарт должен был пойти по известному принципу проектирования API: описывать наблюдаемое поведение, а не внутреннее представление состояния.

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

Сейчас не обязательно сводить обсуждение к вопросу, каким словом заменить BASE. Важнее другая мысль: стандарт не должен раскрывать представление свойства через адрес переменной; он должен стандартизировать операции над этим свойством, оставляя форму их реализации свободной.

Хотя конкретные предложения у меня тоже есть. Например, использовать VALUE и TO.

На мое предложение на сайте forth-standard.org первым ответил пользователь под псевдонимом ruv. Вроде бы сперва он сделал дельное предложение использовать слова RADIX и SET-RADIX, но затем завершил свой комментарий странным примечанием, что через TO сложно сгенерировать исключение. Это очень странное заявление.

Применительно к BASE, когда мы просто заменяем одно число другим, предложение отлавливать исключение выглядит неуместно. Создается впечатление, что пользователь ruv либо недостаточно продумал свой ответ, либо намеренно ведет спор ради спора.

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

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

Кстати, Ertl, как и ruv, тоже не понял, о чем идет речь. Мое предложение было не только про implementation mechanisms, а про правильную архитектуру Форта в целом. Но если говорить о деталях, то мне его аргумент “инициаторы не могут показать, почему это действительно проблема” видится странным. Даже сразу возникает вопрос: Anton Ertl написал ли сам хоть одну строчку кода на ассемблере или он в проекте gforth просто руководит?

Сейчас слово BASE никогда не используется само по себе, оно всегда используется в связке BASE ! или BASE @. В шитом коде это две операции вместо одной, то есть использование BASE в два раза медленнее по скорости и в два раза больше по размеру кода. Мне как разработчику своей реализации Форта это хорошо известно. Слово BASE является не только пользовательской переменной, но еще используется в слове >NUMBER, которое в свою очередь крутится в “движке” Форта. Иначе говоря, слово BASE сейчас тормоз языка.

Вместо использования слова VALUE, можно слить связки BASE ! и BASE @ в единые слова: BASE! и BASE@. Переносимость кода сильно не пострадает — была бы разумная воля. А еще лучше зафиксировать принцип:

“Обратная совместимость не является абсолютной ценностью, если она мешает улучшению архитектуры”.

Возражения, что вместо одного BASE мы получаем два слова, не являются предметом серьезного обсуждения, потому что в нынешнем стандарте есть слова, которые можно смело объявить устаревшими, как когда-то было сделано со словами TIB, #TIB, QUERY, EXPECT, SPAN и CONVERT.

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

Во-вторых, слова CMOVE> и CMOVE. Им нечего делать даже в наборе слов STRING. Оба слова являются небезопасными в работе. Есть надежный аналог MOVE, который лишен их недостатков.

Использование слов CMOVE> и CMOVE может быть оправдано только в embedded-системах, где на счету каждый байт. Поэтому предлагаю в новом стандарте создать новый набор слов под названием EMBEDDED и переместить туда все слова, чье существование оправдано только компактной реализацией, хотя для современных микросхем с их объемами памяти наличие набора слов EMBEDDED остается вопросом обсуждения.

В-третьих, слова SAVE-INPUT и RESTORE-INPUT из набора слов CORE EXT.

Стандарт свалил в кучу два уровня слов Форта — для разработчика и для пользователя. Пользователь должен видеть только те абстракции, которые естественны для его предметной области. Для большинства программистов на Форте предметная область — это стек, словарь, числа, строки, файлы, а не внутреннее состояние текстового интерпретатора. Поэтому возникает вопрос: а почему вообще SAVE-INPUT и RESTORE-INPUT оказались в одном пространстве имен с обычными словами? Еще раз повторю, что стандарт свалил в кучу два уровня:
- API для написания прикладных программ;
- API для написания самого Форта и инструментов, тесно интегрированных с интерпретатором.

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

Объясню подробнее для тех, кто плохо понимает, о чем идет речь. Есть пользователи языка. И есть разработчики компилятора. Это разные роли. Исторически Форт их объединял, но из этого еще не следует, что все внутренние механизмы нужно стандартизировать. Пользователю нужны EVALUATE, POSTPONE, IMMEDIATE, INCLUDE-FILE. А вот существование SAVE-INPUT и RESTORE-INPUT — это уже описание одной конкретной модели интерпретатора. Я бы уточнил: не всякое внутреннее слово является навязыванием. Например, слово POSTPONE тоже сильно влияет на устройство компилятора, но оно описывает семантику языка, то есть без него невозможно переносимо выразить определенный класс программ. А вот слово SAVE-INPUT не описывает новую семантику языка, оно описывает способ организации внутреннего состояния интерпретатора, и вот это принципиальная разница.

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

То же самое можно сформулировать через вопрос: если механизм нужен главным образом автору реализации, то почему он вообще стандартизуется как часть пользовательского интерфейса языка?

На тему двух обсуждаемых слов на сайте forth-standard.org первым снова ответил ruv. Из его ответа видно, что он вообще не понял, в чем суть моих вопросов. Моя тема — не про качество API, а про уровень абстракции. А его ответ почти не касается архитектурного вопроса, который был поставлен мной, поэтому его ответ идет мимо главной мысли.

Следом за ruv снова ответил Anton Ertl, который тоже не понял суть моих предложений, выраженных в поставленных вопросах. Я говорю о форме публичного интерфейса, а он — о множестве возможных внутренних алгоритмов. Ну и дополнительно снова не могу не отметить, что ответ председателя комитета далек от профессионального, потому что если вы внимательно перечитаете его ответ, то увидите, как он пренебрежительно отозвался о некоторых реализациях Форта, записав их в условную группу бесполезных. С его стороны это — высокомерное высказывание в отношении фортеров, которые трудились над своими реализациями.

Забегая вперед, скажу, что если не обсуждать эмоциональную сторону темы, то у меня создается впечатление, что мои оппоненты на сайте forth-standard.org не владеют необходимой терминологией для обсуждения поставленных вопросов, поэтому просто не понимают меня.

Позже Ertl дал еще один ответ, и в его ответе происходит подмена предмета обсуждения. Я не спрашивал, хорошо ли реализовано слово SAVE-INPUT. Я спрашивал: по каким принципам вообще следует решать, какие слова должны входить в стандартный интерфейс? Это вопрос архитектуры стандарта, а не вопрос качества отдельных слов.

Самым слабым местом его ответа является отсутствие общего принципа. Он предлагает оценивать слова по отдельности:
- удобно ли;
- эффективно ли;
- переносимо ли;
- легко ли реализовать.

Но он не отвечает на вопрос “Должно ли обсуждаемое слово вообще быть частью публичного интерфейса стандарта?”. Этот вопрос на их сайте я задал в нескольких своих комментариях подряд.

Ловлю себя на мысли, что я всё время пытаюсь говорить о правиле, а большинство отвечающих обсуждают исключения из правил. Я говорю: “Давайте сначала определим принцип”. Они отвечают: “А вот конкретно SAVE-INPUT можно использовать вот так...”. Мда... У меня такое чувство, что я веду разговор с детьми, и члены комитета не способны мыслить на уровне архитектуры языка. Просто это не их уровень мышления.

Чуть позже там же ответил пользователь под ником pda. С его стороны — очередной детский аргумент, в котором происходит подмена двух понятий. Ответить на его комментарий я могу так: Forth действительно никогда не запрещал программисту работать на низком уровне, но стандарт языка — это уже совершенно другой вопрос, его задача — определить, что должно быть переносимым. В общем, это разные плоскости. То есть философия “ничего не скрывать” относится к возможностям языка, а не к обязанностям стандарта.

Слова SAVE-INPUT и RESTORE-INPUT на самом деле являются началом большого разговора о введении в стандарт нового набора слов, и здесь мы плавно переходим к четвертой части статьи.

В-четвертых, некоторые слова, такие как >IN, SOURCE, REFILL, а также SAVE-INPUT и RESTORE-INPUT, должны быть перемещены в новый набор слов только для разработчиков. Варианты для названия: INTERPRETER, IMPLEMENTATION, SYSTEM, ENGINE.

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

Это вопрос структуры стандарта. Он вообще не затрагивает семантику слов.

Вторую идею, архитектурную, можно сформулировать так:
Даже если такие слова стандартизируются, их семантика должна определять только наблюдаемое поведение, а не вынуждать автора реализации использовать определенную внутреннюю модель.

Причем она вовсе не относится только к SAVE-INPUT, она относится к любому слову.

На мой комментарий на их сайте сразу ответил Anton Ert, который откровенно опустился до уровня лукавства, заявив, что перечисленные слова используются прикладными программами. Пусть он приведет хотя бы один пример — будет интересно посмотреть, какую заковыристую программу он откопает. Мне как не только разработчику, но пользователю, пишущему программы на Форте, трудно представить, что моя прикладная программа зачем-то полезет парсить входной поток Форта.

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

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

Как разработчик Форта скажу больше: некоторые слова вроде >IN, SOURCE и SOURCE-ID оказались ненужными интерфейсами. Разработчики их не используют, потому что сам стандарт подтолкнул их к реализации входного потока в виде отдельного стека, к полям которого обращаются напрямую. А пользователи Форта не используют те слова, потому что это не их уровень прикладного программирования. То есть те слова оказались ненужной прослойкой, не востребованной никем. Но при этом стандарт их навязывает. О, какая архитектурная ошибка! Если идти правильным путем, то слова >IN, SOURCE и SOURCE-ID должны последовать на выход следом за словами TIB, #TIB, QUERY, EXPECT, SPAN и CONVERT. В свою очередь стандарт не должен навязывать разработчикам, через какие переменные реализовывать слова вроде REFILL. Это и есть правильный уровень абстракции.

Заканчивая статью, подведу итог.

Я вовсе не предлагаю лишить программиста доступа к внутренним механизмам Forth. Я предлагаю не прятать инструменты, а правильно их организовать. Все инструменты должны оставаться доступными, но каждый должен лежать в своем ящике. А уже качество самих инструментов — отдельный вопрос. Например, BASE, на мой взгляд, демонстрирует неудачный уровень абстракции, но это уже другая тема.

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

Сейчас язык Форт выглядит как непричёсанный, неряшливый ребенок, да еще “кишками наружу”. Это неудивительно, ведь его родители выглядят великовозрастными детьми, которых в детстве не научили порядку — убирать (складывать) игрушки за собой в коробки. Если в комнате годами складывать инструменты, игрушки и посуду в один шкаф, то через некоторое время беспорядок начинает казаться естественным. Так что, ребята, не ждите, что EuroForth в ближайшие годы родит что-то достойное. Вся надежда только на себя.

Ссылки на английскую версию статьи:
https://forth203x.hashnode.dev/changes- ... rder-forth
https://dev.to/pureforth/changes-to-the ... forth-1ok9

О, внезапно! Надо вчитаться, пока пробежал глазами.

В целом посылы в статье правильные но, как мне видется не сильно меняющие сложившееся представление о возможностях и реалиях Форт языка как инструментария, а отчасти и лишающие его уникальности. Поэтому, вероятно, у Вас не получился диалог с комитетом.

P.S. Мне, к примеру, полезны слова для разбора входного потока.

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

Посылы не просто правильные, а из другого мира. Разработчик-практик спорит с любителями-пиарщиками, чего ж удивляться отсутствию адекватной реакции. Я еще в Вене в 2011 году в компании именно что разработчиков вспомнил про Эртла, когда нам австрийцы показали "а вон то здание - это университет". Мне и пришла в голову мысль, что можно ведь взять ту австрийскую компанию, которая нас всех собирала, отдать им форт-процессор и Эртла консультантом - всем хорошо. Но выяснилось, что университет там в технической среде вообще никак не котируется, чем занимаются - непонятно, и для людей, выпускающих продукцию, они неинтересны. А на онлайн-вопрос "мистер Эртл, тут вот такой проект возможен, можем ли мы обсудить перспективы, ну и заодно расскажите, как у вас там вообще дело построено" был получен ответ "you are troll!" Деревенские трактористы? Ну да, где-то так. Копаются в куче хлама, обсуждают формат установки пентода с косвенным накалом в радио и положение проволочной подставки, чтобы карта не падала. Но не трожь трактор, в нем зеркало заднего вида стоит то самое, от Того Самого Телескопа Вопрос в том, что они слегка дискредитируют людей, которые вообще в принципе под капот лезут, но это больше их проблемы. Волну критики "а, вы те самые ненормальные фортеры, которые свое барахло хотят везде засунуть", можно как-то и демпфировать.

Текст глобально правильный. Вопрос не в нюансах, а в самом принципе. Дело в том, что при отсутствии практических критериев любая деятельность начинает выхолащиваться и превращаться в сектантство со своими лидерами, течениями и обрядами на уровне "клади на стек строки в формате c-addr, u, а печатай через <# # # # # #>". Аргумент - "дух Форта", "Forth way", "авторитет Мура", "уважайте комитет, а то будет несовместимо" и наподобие. Основной результат при таком подходе - разодрать на лоскуты остатки былых заслуг, чтобы отойти от дел с блаженной улыбкой "да я, я когда-то в языке Forth был ого-го! В комитете сидел, меня весь мир слушал!" Вот оно такое надо? А это ведь точка риска для практически любых редких технологий. Очень просто переключиться к накачиванию своей элитарности и объяснять отсутствие результатов тем, что "в мире косные, непонимающие люди".

Альтернатива - берем и пользуемся на практике. Ну а что тут такого, удачно подобранное сочетание алгоритмов - связанный список для лексем, парсер на основе простейшей грамматики, ну и стековая машина, которая органично с этим всем сочетается. Можно посмотреть, что такое REPL. Можно посмотреть на "шаблон проектирования Интерпретатор". Есть же куда всем это девать. По мере использования появятся и списки улучшений, а также моменты "давайте вот это уберем внутрь, а вот насчет этого договоримся, потому что вразнобой пошло". Оно когда-то и в SPF было разумно, потому что был eServ у Черезова и nnCron. Люди писали, а значит были объективные возможности сформулировать запрос на изменение языка. Когда условный коллективный SPF-devel перестал практиковать - тоже все ушло в никуда. Поэтому полезные результаты получаются только при наличии реальных проектов.

Честно говоря, всё как-то очень странно.


А-таки что в этом слове проблемного? Системное, используется нечасто. Хочется передалать в VALUE? Тут процитирую классика "Можно, а зачем?" Хочется добавить, например, BASE! BASE@ – не вижу проблем. Однако ж, ИМХО, польза сомнительна. Ну если только BASE у вас хранится не где-то в памяти, а в регистре/сегменте.



Тут вопрос реализации MOVE. Если слово учитывает ситуации, когда начальный и конечные адреса могут пересекаться, то да CMOVE> и CMOVE не нужны. Если же слово MOVE тупо переносит строку из A1 в A2 без проверок, то слова CMOVE> и CMOVE нужны для пограничных случаев.


Кста, а чё они делают? В моём форте их нету или есть аналоги я хз)


Вот на этом моменте я запутался с контекстом) Что конкретно предлагается?
Перенести эти слова/аналоги в другой раздел стандарта? Если да, то на здоровье.
Создать в форте отдельный словарь для программистких штучек-дрючек? Если да, то не вижу особого смысла. Только лишние операции при разработке.



С учётом того, что "входной поток" может быть файлом, то прикладная программа может использовать фортовский парсер для чтения файлов конфигураций, инструкций на прикладных DSL. Но тут, да, парсер должен быть чуточку сложнее, чем WORD.


>IN чем не угодил? Постоянно им пользуюсь)



Здрасьте-приехали. Написать короткий скрипт на форте, скормить его через командную строку и в конце поставить QUIT / BYE, чтобы скрипт закончился. Простейший пример.

В целом, идея стандарта для форта как по мне очень сомнительна. Гораздо продуктивнее сделать список слов и заметок на полях из разряда "Как, что и почему", чтобы новым разработчикам форта было проще делать свою реализацию с учётом находок и ошибок предшественников.

Странное заявление. Вот есть, к примеру, такая абстракция как стек (который присутствует в любом форте). И для работы с ним есть стандартные слова DUP SWAP и иже с ними. И здесь идея стандартизировать эти слова не выглядит сомнительной.

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

Вот по поводу переносимости, тут вопросы. Если исходники используют потоки, то какой именно стандарт им нужен? Какого-то механизма определения, какой стандарт определённой абстракции реализован в данном конкретном форте, нет. Как вариант, в начале основного файла описывать нужные стандарты:

.FILES LEGACY
.GRAPHIC TURTLE

или

.FILES POSIX
.GRAPHIC IRBIS

Я к тому, что можно опять мурыжить тему создания стандарта для форта с нулевым результатом. Лучше сосредоточиться на реальных задачах.

Ну вот да. Если в стандарте регламентируется поведение каких-то слов, то это вполне разумно, а вот когда начинает регламентироваться реализация, то это выглядит немного дико.

Ну и как определять, какие слова - это (кого надо) слова, а какие - часть реализации?

Тема стандартов сильно связана с темой переносимости исходников. Не потому ли у нас слабо переносимые исходники, что стандарты такие - какие есть?

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



CMOVE> CMOVE - слова нижнего уровня относительно MOVE, они все равно появляются после проверки на перекрытие областей. И тут опять вопрос "зачем делаем". Если этот раздел про работу с памятью - можно оставить низкоуровневые слова. Если это про строки - тут программист уже и не очень хочет думать, что там где лежит, тут как раз лучше обеспечить корректное выполнение операции при любых условиях.



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



Вот!

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


Или наоборот. Потому что практически задачи разные, и те, кто этими практическими задачами занимается, делает так, чтобы было удобно работать. Если исходник взять просто неоткуда, то зачем вообще думать, как его переносить? В программе может быть абсолютно уникальное слово InitPlatform, потому что сама платформа уникальная, и что там куда писать, может разбираться попросту один человек. И, к примеру, Форт с консолью совместить с графическим движком - ну никак не получится. Тут уже вылезает прикладной уровень.