Хищник
Спасибо тебе. Отлично, теперь не нужно возиться с аргументами. Это то, что я хотел. Тему можно закрывать.

где-то у нас была тема, где в словах остаются пустые места, в которые потом добавляются вызовы

вы на самом деле не про рекурсию спрашиваете, а про раннее объявление.
вот, для решения есть два варианта: VECT переменные и ранние объявления имен слов, правда второе действительно только для форка

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

Цель: получить быстрый интерпретатор лиспа (виртуальную машину), абсолютно переносимый, маленький и красивый. Форт идеально вписывается в мои требования. Конечно, можно написать интерпретатор лиспа и на самом лиспе, но это будет медленно работать, а мне это не подходит. На Си тоже не катит, не люблю я Си, он некрасивый (имхо) и слишком сложный (на мозги давит), что не соответствует мои требованиям...

Потом (может быть), для этой виртуальной машины будет написана ОСа... И основная фишка в том, что программы (на лиспе) будут выполняться прямо из исходников, без компиляции. Поэтому мне нужна очень качественная реализация (чтоб скорость была нормальной). И еще, это будет нетривиальная реализация лиспа (надеюсь): я собираюсь выкинуть из ядра интерпретатора все особые формы (define, quote, lambda, if и т.д.) и оставить только процедуры. При этом особые формы будут доступны, но реализованы не в ядре интерпретатора...

Ой, чего-то я разговорился, извините если что.

обращаю внимание mOleg - это лиспа форк

Это не форк, всё пишется с нуля.

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

Недостаточно! Есть еще и восстановление после ошибок, которое в общем случае нетривиально.

ну хорошо.. а что бы предложили Вы?

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

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

Для работы со взаимными рекурсиями есть VECT, стек компиляции, бэктрекинг и можно добавить собственные конструкции!

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

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

замечательно! а можно про это рассказать на форуме (если можно то и с исходниками). Тема очень интересная, и для нее не жаль отдельную ветку обсуждения завести.

эх..если бы у меня остались исходники.. но увы..

могу только вспомнить общий смысл - как всегда решений было куча: от вполне фортовского перехвата фрагмента входного потока и разбора его в служебном буфере, который потом отдавался на "растерзание" Interpret-у. - до написания отдельной служебной утилиты которая конвертировала мой исходный текст в нечто съедобное ларионовскому gp-forthy - первому который мне попался для i8086 после ДВК.

P.S.
кстати этот ларионовский форт ещё запомнился тем что был первым моим кряком - там защита была дурацкая которая заставляла таскать за компилятором весь пакет файлов включая *.doc, а дискеты то были по 360 кБ..

С некоторых пор, я ассемблеры делаю 2 проходными, именно ради упрощения.
При этом для ссылок вперед по сути являются векторными переменными.
Однако, многие языки в рамках Форта, хотелось бы иметь в виде конвертеров в польскую запись.
Причем, результат обработки очередной (каждой) строки можно подать на вход интерпретатору (команде EVALUATE).
Т.е. целесообразность применения многопроходности зависит от реализуемого языка.

Если нетрудно, напишите - с какими?