Рекурсия и сопрограммы - это вполне устойчивые способы написания процедур. Основная идея там - передача параметров. Если таковой нет, то проще говорить просто о передаче управления (обычном goto).

Я не говорю, о том, что "сращивание хвостов", это плохо. Или, что Вы сделали его неаккуратно. Но это частная оптимизация, которая не имеет практически никакого отношения к теме. Оптимизация не меняет языка. Разве что, повторю, обедняет его ("фиксируя синтаксис")...

ОС может языки порождать, но не появляется в результате "фиксации синтаксиса"...

Передача параметров и передача управления процессами имеют отношение к теме.
Я вот не придумал красивую передачу более 3х параметров(пока думаю адрес блока данных передавать) и качественную вытеснительную многозадачность без обрамления многих участков запретом прерываний. Смотреть надо будет.

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

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

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

Об чем и речь с самого начала тему. Допустим, Вам по условиям задачи не очень подходит передача данных через стек... Что делать? Просто "добавить слов" (1), включить виртуальное спец-АЛУ внутрь интерпретатора (2), попытаться описать свои вычисления на спец-языке (3), прицепить интерпретатор этого спец-языка к FORTH "параллельно" (4)...
Я иду обратным путем. Если естественный язык для задачи "не FORTH", то какой стиль перевода является наиболее подходящим?

В такой постановке - (4)+(1) в порядке значимости. (1) - слова добавлять все равно придется! А (4) - принципиальный момент реализации.
Для задачи естественный язык, скорее всего, не FORTH. А дальше надо смотреть, на что больше похоже. Можем разобрать несколько примеров. Предложите варианты!

Вот пример, когда задача более красиво(IMHO) решается на colorForth, чем на традиционном.

Как же сделана красивая передача 1-3 параметров?


Сверхбыстрая компиляция = медленный код

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

То есть неоптимизированный, медленный.

Очень удачный пример. Ведь, что мы знаем о конечных автоматах? Они порождают языки... Да и FORTH-интерпретатор - сам конечный автомат, так, что для него понимание подобных языков естественно... Читаем поток символов (слов, сообщений или что там разбирает Ваш конечный автомат) и тупо запускаем FIND для нахождения текущего состояния. Возможны варианты: если события "что-то значит", то доходит и до EXECUTE, а если наша задача - достижение конечного состояния (распознание строки), то выполнение слова-состояния означает лишь фиксацию его в качестве текущего...
Более того, т.к. работа по регулярному выражению более естественна для NUMBER (а не FIND), то в нашем спец-FORTH мы можем заявить, что результатом NUMBER будет не литерал, а адрес слова...

Задача построения ОС "в общем смысле" оже близка. Очереди "сообщений" и/или "ожидания семафоров" порождают аналогичные языки.

Зависит от задачи. Вроде получается достаточно неплохой. Конечно, он не учитывает конвейеры, переупрорядочивания и векторные команды. Но зато универсальный и небольшой(нет лишних проверок возможностей процессора ). И, если не очень большие циклы, еще неизвестно, что будет быстрее, загрузка+компиляция+исполнение такого кода или загрузка+исполнение результата С# или Lazarus(в одинаковых стартовых условиях). Внутри большого цикла, конечно, ставить не стОит. Но, по-хорошему, для этого код надо готовить специально под процессор и/или под систему(использование векторных команд и GPU).

можно подробнее?

В смысле? Что NUMBER по жизни распознает регулярные выражения (и наиболее эффективно реализуется конечным автоматом), это вроде, очевидно. Что в рамках FORTH-автомата словарной статье будет соответствовать состояние конечного автомата, вроде, тоже понятно.

Видел реализацию, где NUMBER читает число из входного потока и возвращает его на стеке. А если не литерал, адрес какого слова? Вот про это слово и его адрес поподробнее...

Это в "нормальном" FORTH. А я говорю о построении специальной FORTH-системы (2) для чтения специфического ввода - регулярных выражений. Это будет, по определению, конечный автомат, схожий по функционалу (если не по устройству) с NUMBER. Состояния конечного автомата будут словами.

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

Можно попытаться посмотреть в теме
http://fforum.winglion.ru/viewtopic.php?f=25&t=2929, там, правда, много мусора, или сразу у меня [url]http://www.gudleifr.h1.ru/cgi-bin/pilo.cgi?FL=../g9.txt&IS=\3.POLESNYE%20ALGORITMY\KONETNYE%20AWTOMATY[/url].

Вот, еще одно возможное FORTH-применение, требующее подобного выбора подхода.

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

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

Если бы метод "Дракон" действительно бы работал, достаточно было бы переписать задачу на нем, а потом - автоматически породить код, но т.к. он, очевидно, не может работать по определению, то приходится каждый раз думать заново.
Я одно время занимался схожей проблемой по роду службы, но т.к. работа всегда происходила в условиях постоянного форс-мажора, то почти все делал на Perl...
А кто-нибудь пытался автоматизировать (или, хотя бы, инструментализировать) перевод на-FORTH? Конечно, подразумевается, что программа слишком сложна, чтобы держать алгоритм и переменные в голове, а фортер не болеет манией тупо создавать по слову на каждую C-функцию.

Такой перевод потребует пересмотра архитектуры программы. А почему простой перевод на Форт обязательно является "тупым"?

Об этом и речь. О языках описания, пересмотра и переделки архитектуры.
Потому что не подразумевает рассматриваемых в данной теме интересностей.