Добрый день, коллеги. Пару-тройку недель уже читаю спецификации и форумы по Forth. Опробовал несколько вариантов реализаций на питоне. И в конце концов понял, что всё же надо спрашивать людей.
Итак. Имеется необходимость реализации скриптового языка, который будет исполняться как на сервере, с бэком на питоне, так и на контроллере ESP32, с бэком на С++. Поскольку у меня есть опыт работы с использованием forth в таком виде (жаль, что Balancer от нас ушел так рано), то я решил его и использовать.
Вариантов реализации на С++ масса. Есть даже для ESP. На питон поменьше, но тоже немало.
Однако всё усложняется тем, что реализации должны быть идентичными по словарным базам. Поэтому, прошу помощи в выборе минимального набора словаря и вариантах реализации специальных слов.
Функционально можно слова разделить на 4 части.
1 - базовый набор - тот самый базовый набор слов
2 - общие слова - работа со строками, числами с плавающей запятой, REST запросы
3 - слова серверной части - обращение к состоянию объектов на сервере, и истории состояний
4 - слова контроллерной части - обращение к железу и отправка событий на сервер.

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

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

Собственно, это в последнее время получило определенное развитие в виде процедурного подхода к проектированию. Это не имеет отношения к процедурным языкам, а предлагает посмотреть на разработку с точки зрения типовых сценариев использования и последовательностей действий со стороны "исполнителей" (в данном случае - слов Форта). То есть можно писать просто "как хотелось бы видеть", считая, что все написанное будет потом реализовано. И таким образом получится ТЗ на разработку слов.

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

P.S. Интересней, к примеру, какая ОС, железо предполагается к использованию на стороне ПК, контроллера и общая постановка
вопросов к решению предполагаемой задачи в рамках выбранныз решений.
Чем обусловлен выбор Python для интеграции с Форт, а не более распространённых вариантов, и.т.д.
Список слов, в использовании и реализации слов может быть выбран из общего своего знания Форт и при необходимости
дополнен по ходу реализации предполагаемого ПО.

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

К, примеру, для gForth сделана и своя реализация Swig для экспорта мнтерфейса функций (констант) тех или иных библиотек
в gForth без ручного их набора для состыковки с Си библиотеками.
Примеры использования дополненной утилиты Swig для связеи с Форт
Forth Posix C-Interface,
gforth-sdl2

Вопросы "что мешает" часто вызывают забавное недоумение. Для начала, а что помогает так делать? Тем более что я подозреваю о попытке разворота в сторону огромной кучи недоделанных Фортов, когда замах огромный, а в результате на очередной микроконтроллерной плате можно помигать светодиодом и сделать DUP на стеке. Дальше туман и призывы присоединяться всем пресловутым открытым сообществом и все дописать.


А какая разница? Сейчас большая тенденция к абстрагированию от платформы. Тем более упомянуты REST-запросы - ни на какие мысли не наводит?


Более распространенных, чем Python?


Эх, как вспомню..
- Мистер Эртл, а мы могли бы обсудить особенности внедрения Форта в практические проекты? Я думаю, в европейских условиях, при учете Вашего опыта в разработке Форта, у вас достаточно примеров...
- Ты тролль!

Желаемые сценарии - они понятны. Есть просто вопрос удобства написания скриптов.
К примеру вариант создания словаря и заполнения вложенных словарей с передачей получившегося объекта dict в requests реализуется вроде очевидно, но чрезвычайно громоздко. И клиент, который будет потом писать данный код в браузере, 100 раз проклянет что связался. И потом еще 200 раз при отладке. Именно поэтому я спрашиваю совета. Возможно кто-то уже сталкивался и нашел если не золотую, то хоть бронзовую середину

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

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

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

Конечно, будет именно "реализация исходя из своего понимания". А как иначе можно встроить сторонний продукт в свой? Тем более, с учетом того, что функциональные требования весьма ограничены. Для работы с "Устройством сбора данных" нет необходимости реализовывать работу с OpenGL, но есть необходимость работы допустим с температурными датчиками. Причем даже не столько с датчиками, сколько со значениями от них. Или управлять состоянием внешних устройств путем запросов по REST. Или просто логические конструкции -


Такие конструкции очень необходимы в повседневной жизни обычных людей. И вместо изобретения велосипеда с, допустим, графической реализацией (flow) всех возможных вариантов использования, я предпочту взять простой, максимально быстро осваиваемый в небольших объемах язык.
Во всяком случае в вышеописанной конструкции моя дочь (16 лет, скрипачка) разобралась за 2 минуты. А вот в изучаемом в школе паскале не может разобраться до сих пор

Это характеризует то, что её мышление и восприятие Форт программ со стороны накопленного опыта как скрипачки оказалось
более естественным. (нотная нотация, в своём построении, ближе к Форт, чем к Паскаль)

О, это уже интересно. В принципе, лет 20 назад было довольно запомнившееся применение с активным использованием CREATE DOES> для определения, собственно, создающих слов. На их основе потом описывалась геометрия объектов для метрологического контроля. Т.е. внутри движка были ТОЧКА ПРЯМАЯ ПЛОСКОСТЬ (и еще несколько наподобие), а в скрипте можно было написать


Оно было довольно удобно, тем более что заказчик грозился дать сборник на 600 схем, а увидев, как мы их делаем, запросил сам язык. Может быть, и здесь получится что-то на основе CREATE, чтобы внутри в DOES> описывались GET/POST... в вариациях, требуемых типовыми сценариями. То есть напрашивается некоторый набор таких строк, чтобы выделить из них часть, которую можно "вынести за скобки", т.е. задать внутри конструкции CREATE, а может быть даже и в словах.


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


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


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

То, что Си называют языком низкого уровня, я слышал. Но вот Питон... Дожили)



Ну, хм, я делают слова и некоторые алгоритмы на чем удобнее. На форте обычно удобнее, чем на ассемблере.

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

А то-ж!!!
На самом деле, так никто и не высказал ничего по теме вопроса, кроме Hishnik, с CREATE DOES>.
Правда я не совсем понял, зачем именно эта конструкция, и чем она так сильно отличается от обычного объявления слов. Но это, наверное, именно опыт использования языка, и глубокое понимания концепции.

У меня всё попроще. Труба пониже, дым пожиже...

Тем не менее, всё таки. Какие слова нужны обязательно?
Моё понимание:
1. Базовые слова:
+ - 1+ 1- / * AND OR XOR MOD /MOD NEGATE > < = !=
DUP DROP OVER SWAP 2DROP 2OVER 2SWAP ROT . CR EMIT
VARIABLE ! @ CONSTANT
IF ELSE THEN DO LOOP
: ; WORDS # ( )
2. Общие слова
." S" F"
USING - Загрузка библиотек кода на forth
Работа с HTML:
HTTPGET ( url -- response err_code )
REST_GET( url params -- response err_code )
REST запросы:
REST_PUSH REST_PUT REST_PATCH REST_DELETE ( url headers data -- response err_code )
Вот эта часть мне очень не нравится, т.к. headers необязательный параметр, и вопрос, как его формировать остается. По идее, должен быть что-то вроде key-value массива, но как это синтаксически формируется в форте я не знаю. В тестовой реализации сделал в питоне DICT@ и дальше именованные значения (props) через P! ( o v p -- o ) и P@ ( o p -- v ). На C++ через вектора можно хранить. Но скорее всего я изобретаю велосипед.
Синтаксис операторов работы со строками я так и не нашел. Буду благодарен, если кто подскажет

JSON@ ( o -- json ), JSON! ( json -- o ) - Формирование json строк из объекта и обратно. Так же встает вопрос структуры хранения значений в форт. Сейчас на питоне реализовано через встроенный dict. На С++ не реализовано.

Спецслово проверки на объект ?O ( o -- o -1| x 0) на верх стека добавляет признак объект или нет был верхним на стеке. Сделал оставление объекта на стеке, для того, что бы избежать лишнего DUP

Вот примерно то, к чему пришел на сегодняшний день. Жду комментарием и умных мыслей.

Это одна из фишек Форт языка позволяющая создавать параметризированные слова, если Вы читали
базисные книги по Форт (Баранова, Броуди - Основы, Мышление и др.)


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


Если Вам с ними удобно будет решить Вашу задачу, то почему нет?
К примеру, не увидел слов беззнакового сравнения.



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

P.S. В решении любой задачи и в том числе на Форт придётся углубится в проблематику и используемого инструментария и определиться что важно в её/его понимании, а что можно оставить "за бортом"
К, примеру, будет ли использована и какая то стороняя алгоритмическая база Форт кода
как FFL и др.

Далее, если выбран Python, то насколько и в какой степени при реализации Форт нужно следовать его канонам,
а не решать задачу в каком то его изменённом "варианте" инструментального языка, как Quackery или в концепции Factor языка или какого то другого из конкатенативных

Из книги "Python for Fun" Forth in Python

"Форт подобен Дао. Это Путь, и осознается он, когда ему следуешь"
В запросе от Google приводит эту i-net страничку

Видимо всё-таки я этот момент упустил. Буду перечитывать.

Вооо. Уже хорошо. В принципе, беззнаковое сравнение подразумевает наличие беззнаковых чисел. У меня и объявление в списке есть только для плавающей запятой. А операций с ними нет. Как и операций со строками.

Ну хоть бы и от Вас. Опыт вещь такая.... Кто-то может на мои тупые вопросы и среагирует.

Еще раз подчеркну - проект простейший. Для самых простых операций.
По сути тут достаточно только получение значений, их сравнение и обработка условий. И если не брать работу с внешними источниками (http), то вообще всё просто. Сейчас потихоньку уже пробую и гоняю. Но, блин, проклятая профдеформация. Должно быть сделано КАЧЕСТВЕННО! Не люблю халтуру.
FFL посмотрю. Не знал о его существовании по сути. Может и отпадет половина вопросов

Python является не более чем инструментальным языком реализации, следовать которому нет необходимости. Тем более, при реализации аналогичных слов в C++ это и невозможно.

Конечно проще всего делать как бог на душу положит, а потом выложить и сказать "Смотрите какую фигню я наваял!". Все скажут "ВАУ!!! ВОТ ЭТО ХРЕНЬ!!! " и забудут на второй день. Но всё-же хочется сделать что-то, что потом будет не стыдно показать. Одна проблема - в одиночку, такие вопросы решаются плохо. Всегда нужна некая критика со стороны. А в моем окружении нет ни одного человека, который тот самый forth в жизни видел хоть раз. Потому и пришел сюда, что бы хоть кто-то носом тыкал в бред и жизни поучил

Поначалу это может казаться/быть и так, пока не погрузишься в "кроличью нору" и по результатам этого погружения не возникнет желания написать какое то эссе или книгу путевых заметок.

P.S. Предполагал ли изначально автор программы Nncron что решением окажется использование Форт?
Eserv, конечно, изначально делался на Форт.
А, Net2o на gForth.

А, кстати, ДА! По сути, примерно то-же мне и надо. Пойду посмотрю синтаксис!