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

Лично я начал интересоваться этой тематикой в конце 90-х. Еще до появления "новой волны" в виде Joy и неуклюжего термина "конкатенативный". В первую очередь, влияние оказала, конечно же, тьюринговская лекция Бэкуса, а также его языки FP/FL. Помимо прочего, автор показал, что функциональное программирование совершенно не обязательно должно основываться на лямбда-исчислении. Простая мысль, но сейчас, кажется, до не доходят все реже. Тем не менее, комбинаторный подход, как он есть, из учебников по мат. логике, к прагматичному Форту неприменим. Однако, тут важнее сама идея -- базис функционального языка может быть построен разными способами. И один из таких способов -- стековые комбинаторы, о которых я узнал из работ Генри Бэйкера. Есть определенная ирония в том, что "функциональную суть" Форта углядел один из самых талантливых лисп-хакеров, не правда ли?

В конце 90-х я попытался продвигать функциональный подход в нашем форт-сообществе. Реализацию "лямбда"-функции в две строчки фортеры восприняли благосклонно. Более масштабный подход из статьи "Функциональное программирование на языке Форт", увы, практиков не заинтересовал ( http://sovietov.com/txt/forthfp.html ). Далее, в скриптовом форт/лисп-подобном языке Forpost я попробовал оценить, насколько возможно практическое околофункциональное программирование еще в более минималистичной среде, чем классический Форт. Среди забавных моментов упомяну использование самомодификации кода для имитации лексических замыканий.

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

P.S. А примеры кода показывайте конечно!

Вот просто тупо кусочек кода из "системы" уже 3-и года управляющей отоплением на моей даче:

Я бы хотел посмотреть. Вот честное пионерское. Нету ли где нибудь странички проекта? Какая область задач перед проектом ставилась?

Нет, пиколисп по прежнему виртуален, как и в 90е. Его только переписали на си целиком.

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

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

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

Попробую неформально описать язык и виртуальную машину.

Виртуальная машина имеет два стека: стек данных и стек возвратов. Пользователю предоставлен доступ к обеим стекам. Слова манипуляции элементами стеков взяты из форта.
Только три типа данных являются вычислимыми: встроенные подпрограммы, символы и списки, а остальные не вычисляются (копируются на стек данных).
Для описания списков используются видоизмененные s-выражения: (1 2 . 3) -> [1 2|3]. В отличие от классического лиспа, NIL является не константой, а встроенной подпрограммой, выполняющей роль NOP. Списки вычисляются немедленно (как в лиспе), например, [1 2 3], как и [1 2|3] при вычислении кладут на стек: 1 2 3. А список [1|[2[3|+]|-]] --> -4. Чтобы избежания вычисления, используют qoute и его сокращение ' (синтаксический сахар), например, [quote [1 2 3]] --> [1 2 3] или '[1 2 3] --> [1 2 3].
Т.к. вам доступен стек возвратов, то вы можете контролировать порядок вычислений как вам угодно. Например, QUOTE можно реализовать так: '[>r car] 'quote bind или [def quote r> car].
В качестве закуски дам код хвосторекурсивного вычислителя потока:Пример использования:

В таких учебных проектах главную пользу получает сам автор -- набирается опыта, знаний. Практичный стековый язык сегодня имел бы массивы-последовательности вместо архаичных списков с их точечными парами и тяжеловесным mark&sweep gc. Там бы минимально использовались стековые комбинаторы и был бы механизм именования значений в режиме связывания (однократного присваивания), с автоматическим генерированием соотв. перестановок.

P.S. Для вдохновения предлагаю посмотреть на комбинаторный язык Faust: http://faust.grame.fr/

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

Опять замечаю подчеркнутое стремление сделать Форт не работающим нигде кроме того огорода на котором пасетесь вы. Как будь-то кроме ПК и планшетов ничего больше не существует. А ведь существует. Существует мир встроенных систем и микроконтроллеров и для этого мира Форт подходит великолепно. Вы хотите чтобы больше не подходил ?
И куда вы собрались убрать 16-битные реализации ? В этом мире в массовом ходу 8-разрядные процессоры.

Не далее как сегодня припаивал к микроконтроллеру 4-х мегагерцовый кварц.
Где-то и выросла. Только там где это даром не нужно по прежнему миллион операций в секунду.

Мысль :
Совершенствуйте Форт сколько вашей душе угодно. Но только не так чтобы он перестал быть применим там где применяется на ура, причем так, как будь-то специально для того и создан.

Все это уже есть. Словарные записи итак имеют произвольный доступ. Забыть одну запись - это выставить у нее SMUDGE-бит. Он есть во многих реализациях. Если его нет, то исключить слово из односвязного списка, коим является словарь, подкорректировав у следующего за ним слова поле LFA. В общем, Ваше предложение реализуется определением нового слова NEW-FORGET в пару строчек длиной.

А FORGET - это не просто "забыть слово". Это забыть слово и освободить занимаемое им место в кодофайле. А такое возможно только вместе с освобождением всего, что определено и накомпилировано после него. Такой FORGET следует по любому сохранить.

Это архитектура 80x86 неполноценная.
У PDP-11 стек данных данных можно было построить используя в качестве указателя любой регистр общего назначения. Например используем указателем стека данных регистр R4 :
MOV R0, -(R4) <- покласть в стек косвенно по R4 с предекрементом содержимое R0
MOV (R4)+, R0 <- извлечь в регистр R0 из стека косвенно по R4 с постинкрементом
А вместо R4 можно использовать R0 R1 R2 R3 R5
Вот R6 = SP, т.е это аппаратный стек возвратов. А R7 = PC счетчик команд

З.Ы.
Для работы со стеком не нужны специальные слова типа push и pop. Введение таких слов - крайне тупая идея. Нужны кроме обычной косвенной адресации еще косвенная адресация с постинкрементом и косвенная с предекрементом. Эти адресации кроме работы со стеком позволяют еще и работать со строками как от начала к концу, так и от конца к началу. Одним махом семерых убивахом.
Создателям 80x86 один хрен ведь пришлось создавать LODS STOS SCAS CMPS MOVS с постинк- и декрементом и еще флажок направления к ним вводить. А можно было вместо всего этого дикого огорода с PUSH POP LODS STOS SCAS CMPS MOVS флаг D ввести 2 режима адресации и ничего больше не надо. Все что нужно сделают обычные команды MOV и CMP с этими режимами адресации у операндов. Да еще и стеков будет сколько хош.

Предлагаете что-то изменить в Форте в этом отношении, а по сути у Вас претензии только к терминологии.

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

Ну я же говорю, что это не механизм неочевидный, а это терминология для кое-кого не очевидная.

На самом деле все очевидно.
Если словарь ОТКУДА. И есть словарь КУДА.
Первый обозвали контекстным, а второй текущим.
А если называть первый ОТКУДА, а второй КУДА, то куда уж очевиднее.

Эм, относительно других архитектур не владею нужной инфой.
А push/pop? Вот это понять трудно.
Если в архитектуре два стека. Лучше всё же иметь для каждого из них свои push/pop. Ну dpop dpush rpush rpop и всё.
Больше двух стеков, думаю, мало где надо.