собственно дальше размышление (работающее) на тему раннего объявления слов.
идея в том, чтобы объявить имя слова заранее (не используя при этом VECT - слово ) а скомпилировать код в последствии.
Cинтаксически это должно выглядеть как-то так:

DECLARE NAME \ ...

: blabla ... NAME ...

DESCRIBE NAME .... ;

слово describe должно связать код, созданный после него с именем NAME , объявленном заранее.

<pre>
\ 26.04.2009 ~mOleg
\ Сopyright [C] 2009 mOleg mininoleg@yahoo.com
\ ранние объявления имен слов

vocs/ compile.fts

0 VALUE no_declare

\ объявить имя слова
: DECLARE ( --> )
CREATE
DOES> [ HERE TO no_declare ]
ERROR" поведение слова не описано с помощью DESCRIBE" ;

\ связать ранее объявленное с помощью DECLARE слово name с кодом, следующим
\ за name вплодь до завершающей ;
: DESCRIBE ( / name --> )
' DUP >R
TOKEN@ CFL + no_declare <> ABORT" DESCRIBE работает только в паре с DECLARE"
:NONAME R> TOKEN! COMPILE RDROP ;

\ EOF пример использования:

DECLARE sample

: test ." вызов " sample ." работает" ;

DESCRIBE sample ." слова sample " ;

test
</pre>

после того, как было написано, в голову пришло, что идея очень похожа(проще) на конструкцию DOER .. MAKE предложенную Броуди. хотя хотелось немного другого:
"как вариант, можно создать некую таблицу ссылок на адреса, ссылающиеся на указанное слово,
а во время DESCRIBE все эти адреса править, что выглядит грамотнее, но сложнее в реализации"
кто-нибудь может предложить лучший вариант?

А как вариант патчить код NAME чтоб получился переход на слово, позднее определенное через NONAME? В одной из реализаций слово, которое такое делало, называлось NEW .

Вы не обратили внимание, что именно так и делается
но хочется(интересно) найти более изящный вариант, если он возможен.

да, забыл привести код
<pre>
\ заменить значение токена dst на src
: TOKEN! ( src dst --> ) TUCK CFL + - SWAP 1 + ! ;
</pre>

А чем плох VECT? Он уже есть. А тут еще какие-то слова объявлять, которые будут достигать того эффекта, который возможен и без них.

это уже тоже есть.
VECT плох тем, что он нетороплив, кушает несколько больше памяти.


да понятно, хотя это все-таки не одно и то же, то есть несколько другое употребление.

К тому же тут скорее "шахматная задача" нежели важный вопрос (этакий вариант "перегрузки операторов" по-Фортовски)

впрочем, к примеру, кто пользуется конструкцией DOER MAKE , предложенной Броуди?
А ведь штука занятная и вполне полезная...

Можно подумать, он какие-то развесистые структуры создает Один лишний call получается.





Разница "синтаксически-сахарная". Напрашивается только убрать явное назначение вектора, но это уже по вкусу.

смотря по чем судить, если по скорости, то да, если по размеру, то три лишних CALL + собственно не нужное поле кода (но это особенность реализации в СПФ , в других системах может быть инАче)


а так же, кодоразмерная, и скоросте-вызовная

к примеру, можно взять scattered-colon определения. Ведь тоже разница синтаксически-сахарная, а народу нравицца.

Мне это мерещится или и вправду пахнет ООП?

(вполне возможно, что это только на фоне того, что мне приходится сейчас учить)

А что приходится учить?

ООП пахнет всюду

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

Дельфи - не люблю, не пользуюсь, а ООП - хорошая вещь, полезная и обьективно нужная, потому - успехов

нет, ЯОП пахнет