Разве что в общих чертах. А конкретика зависит от множества решений, принятых программистов. Например, где держать стек(и).

Судя по тому, что я успел прочитать у Броуди вопрос об избыточности кода, создаваемого транслятором Форт-системы(кратко Форта) им не рассматривался. Не те задачи решал Броуди своими книгами. А именно этот момент я и рассматриваю в этом топике.
А то, что я и сказал. Например, в так называемых форт-процессорах степень поддержки стека параметров на аппаратном уровне гораздо выше, чем может быть опеспечена на х86. И еще, во всех форт-системах с подпрограммным кодом на х86 стек x86 используется как стек возвратов, а стек параметров организуется программно. Это делается именно
с целью повысить эффективность кода приложений.
В выражении 'подпрограммный шитый код' слово 'шитый' может быть отброшено за ненадобностью без искажения смысла исходного выражения. Транслятором Форт-систему можно назвать при условии, что код приложения, который она выдала не содержит форт-систему или ее составляющие. Тут надо заметить, что форт-система нужна для создания приложений, а в качестве составляющей части приложений может создать проблемы с надежностью
этих приложений. Собственно это моя трактовка использования форт-систем для создания ПО.
Насчет транслятора я сказал выше, классика и типичность вытекают из желания разработчиков форт-систем придерживаться какого-то стандарта(за неимением лучшего, хотя бы ANSI-94). Насчет главной ошибки, я ведь не говорю о создании оптимизатора, я говорю лишь об удалении определенной избыточности, которая обусловлена разными моделями виртуальной машины форт-системы и реальной машиной целевой платформы. В основном это касается кода операций на стеке параметров. А вы что имели ввиду под явной ошибкой.

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

Наконец-то я понял. Здесь обсуждаются не Forth-системы, а Forth-основанные трансляторы. И от Forth здесь взяты не его идеи и возможности, а лишь простота построения компилятора. Отсюда и самая убогая из моделей - подпрограммный шитый код, и разговоры о нужных/ненужных словах, и... В общем - все, вплоть до непонимания Броуди и обвинений Forth-трансляторов в убожестве...

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

Наличие транслятора в рамках Форт-системы не исключает всего остального
присущего Форту.


О каких возможностях идет речь?


Ну проложен подпрограммный код командой CALL
(по отношению к другим видам ШК), почему это делает его убогим?

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

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

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

Это не бага, это - фича! Такое желание конкретного программиста - это только "частный случай".

Как я понял ты утверждаешь, что СПФ из за оптимизатора утратил что-то
на столько важное, что даже Фортом его назвать нельзя.
Можно без общих слов, что именно? И не обо всем остальном, а о чем то одном.

Для компиляции любого вида ШК не нужен Форт. Транслятор с Algol-добный языка
вполне может генерить хоть прямой хоть косвенный ШК или еще какой.

Что за [само]модификация кода?

Что значит смешивать?

Дело не в конкретном техническом решении, а в отношении к нему коллег. Уважаемыми коллеги не видят за деревьями "транслятора" леса Forth-системы.Именно! Более того парадигма "Forth-транслятора" возникла только потому, что "нормальный" транслятор написать сложно, а Forth-систему - легко. В такой интерпретации использование Forth - лишь дань нашей криворукости.Возможность программиста/программы править уже скомпилированный (и, возможно, в данный момент работающий) код.Иметь одновременно загруженными и связанными в единую сеть поиска/исполнения словари с совершенно разной структурой словарных статей, представлением кода, особенностями связывания. (Прошу прощения у коллеги mOleg за возможное искажение его идеи.)

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

P.S. Примеры есть и в devel spf и на данном форуме и
зависимость их от spf4 "условна"!

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

Конечно урезаем:)Но, что бы использовать всё "многобезобразие"существующих возможностей необходимо владеть неким аппаратом абстракций.

P.S. Показателен, в данном аспекте, аппарат функционального
программирования с его "небольшим" сообществом. Программы
могут быть написаны на процедурном подходе:) Prolog
даже можно и не вспоминать.