Кстати для этого есть слово --

Михаил, в чём-то Олег прав - оптимизация создаёт дополнительные формальные сложности
Но перспектива Форта - в развитии оптимизации

Вот разбор исходного варианта:
Стековая нотации
0 - ( -- 0 )
, - ( a -- )
Результат стековая нотация 0 , ( -- ). Отбросив все эквивалентные куски доходим до HERE который имея нотацию ( -- а ) и оставляет wid.

Вот разбор Вашего варианта:
HERE #VocRec ALLOT \ зарезервировали место под словарь
VOC-LIST @ OVER VocBackLink + !
DUP VOC-LIST ! \ связали в список
0 OVER VocLastWord + !
0 OVER VocName + !
0 OVER VocParentID + !
0 OVER VocClass + !
VocLastWord + ;

Стековая нотации
+ - ( a б -- а )
VocLastWord - ( -- а ) \ это надо еще найти - совсем не факт, что константа
! - ( a б -- )
VocClass - ( -- а ) \ это надо еще найти - совсем не факт, что константа
OVER ( a б -- а б а )
0 ( -- 0 )

С какой попытки Вы в уме сможете правильно отследить стековую нотацию куска
0 OVER VocClass + !
если не Вы его написали?
0 ( -- 0 )
OVER ( a 0 -- а 0 а )
VocClass ( а 0 а -- а 0 а б )
+ - ( а 0 а б -- а 0 с)
! - ( а 0 с -- а )
Стековая нотация этого куска ( а -- а )

Далее смотрим "похожие" куски с участием VocParentID VocName VocLastWord предварительно найдя в тексте, что это все-таки так-же константы.
Одбрасываем эти 4-е куска оставив их стековую нотацию ( а -- а )
Разбираем следующий кусок:
DUP VOC-LIST !
....
В общем вспоминаем, что VOC-LIST это переменная и того этот кусок так-же имеет нотацию ( а -- а )
Разбираем следующий кусок:
VOC-LIST @ OVER VocBackLink + !

......
В общем я уже закипел, но что такое wid так еще и не нашел... Мне известно только, что он вычисляется как сумма VocLastWord с каким-то числом. А вот что за число...

Так понятнее слова "на порядок сложнее" ?


Не "можно и так", а НУЖНО именно так. Вы ввели в код 6 новых имен, а теперь приведите пример как Вы их будете использовать например для чтения поля VocName скажем словаря FORTH (или любого другого словаря). Еще 6 имен введете?
Намек ясен или показать "в примерах"?


Для того, что-бы найти чему он равен. У Вас в примере он закопан так глубоко, что надо перерыть почти весь код слова.


Дык там-же и комментарии рядом лежат. Большего ответа на вопрос "что делают остальные поля" получить из того кода нельзя.

cells ( a -- a*cell )
6 cells - ( -- 6*cell )
Далее R@ 6 cells + это адрес выделенный по ALLOCATE + 6 ячеек

Добавить - почти наверняка ничего, а вот убирать я бы Вам не советовал - мало ли какие либы пользуются убраным полем....

Надеюсь в последствии при переносе перенесенных Вами либ на еще какую нибудь Форт-систему не понадобиться еще раз залезать в структуру словаря той ФОРТ-системы. Бо проблемы как раз и возникли по указанной мной причине - причене смал32-зависимости этих либ. Возможно именно такой подход к либам и не дал развиваться этой Форт-системе .

А может стоит попробывать изменить либу так, что-бы она работала на существующем ядре. Иначе достаточно мелкие изменения ядра могут катастрофически отразиться на работе либы .

я в самом начале описал проблему.

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

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

Возможно я назвал достаточно неправильно поля. можно обозвать и так:

0 Cell -- voc_lfa
Cell -- >wid

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


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


и закопан адрес не глубоко - нет ни pick ни roll для его доставания.
с чего бы это? по-моему все ясно. ( тут одна проблема есть - при постах в форум форматирование улетает 8( все пробелы с начала строки уходят. Тогда да не так понятно получается 8( )
И еще насчет перерывания кода слова - там всего несколько строк. И при желании можно добавить коментарии. Но формат статьи будет задокументирован уже в коде, а не на словах.




И как мне получить информацию о полях из интерпретатора? Каким образом?
парсить комментарии исходников? не слишком ли?


И что там находится? Могу еще один перл привести:

: CLASS! ( cls wid -- ) CELL+ CELL+ CELL+ ! ;
и что бы это значило? И что здесь делать, если добавлено еще одно поле? А таких слова в СПФ мноого!
Если бы использовалась структура мне не пришлось бы лезть в этот код! А так при копании в СПФ руки опускаются 8(((


Вот это самое неприятное - использование хаков при написании либ. Вот в результате таких вещей и не работают многие либы 8( А совместимость обеспечить просто.


Смал здесь не причем. Развиваться он перестал из за создателя - он не открыл код 8(
Хотя порт смала под винду есть, но тоже без исходников. Смал спроектирован гораздо лучше СПФа и встреченных в спф-е проблем в смале нет.
Залезать в структуру словарной статьи придется по любому. Но это не проблема, когда она описана нормально, все что необходимо добавляется максимум двумя-тремя строчками.


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

Кстати, чтобы пробелы не улетали, надо использовать окружение code, т.е. вот так:

Можно еще в качестве табулятоа использовать html-тег < dd > (без пробелов внутри скобок). Но с dd проблема в том, что не все браузеры его правильно отрабатывают ("правильно" - я называю так, как в IE).

<dd>Тогда
<dd><dd>можно
<dd><dd><dd>сделать
<dd><dd><dd><dd>и так

Приведи конкретный пример. И как он решается в СМОЛ и какие проблемы в СПФ?

Может потому, что для остальных этой проблемы просто не существует ?

Проблема добавить 0 , и свой комментарий, что-бы стало ясно, что это место уже кто-то забил?
Уже вижу, что Вы не поняли. Проблема была не в том, как написан этот кусок, а в том, что у Вас получились не функциональные слова - их НИГДЕ кроме определения слова WORDLIST нельзя использовать т.к. только в этом месте заголовок адресуется с начала. В остальных местах он адресуется с wid .



А зачем вникать если Вы его (поле) не используете? Там ведь 0 , на всех полях кроме 3-х только это и означает - кто-то подумал, что в будущем может понадобиться в заголовке дополнительное поле. Вот он его и добавил, и добавил слова для работы с этим полем относительно wid.
Причем совсем не факт, что это поле было использовано. Например попробуйте найти использование слов PAR@ PAR! ....

Вы спросите у Черезова как он смотрит на подобное разнообразие слов . Добавив 20 новых слов текст практически НИКОГДА чище не станет.

А че показывать-то. В коде словарь мы обычно видим как CONTEXT @ ( wid ), а все Ваши константы построены относительно поля VocBackLink которое надо еще как-то получить... Т.е. они стали "мертвым грузом".
Используйте CODE. Пример смотрите Выше. Но это не выход - что Вы имели ввиду форматируя код отступами кроме Вас мало кто поймет... Нет, посмотреть как используются поля в либах. Другого способа просто нет т.к. часть полей там была просто "заложена на будущее"Значит абсолютно то, что значит - записать число в поле "CLASS". Что значит это поле - как говориться "догадуйся сам". Пока я видел использование этого поля только у Немцова. Если хочешь иметь совместимость с ним используй с учетом того как он это делает. Иначе это поле полностью на твое усмотрение.
По поводу "если добавлено еще одно поле?" - добавляй. Слово CLASS! при этом не изменится. Естественно, если ты нормально его добавишь...

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

ДОБАВЛЯЙ, но с учетом сохранения работоспособности всего предыдущего. Например - адрес с которого исполняется любое слово лежит в CFA. НИЧЕГО не мешает изменить этот адрес с учетом хоть сотни новых полей в слове и при этом эти слова все еще чесно будут работать.

: ShowMe Create Archive Does> Body> >name 20 + Print ;

ShowMe



напиши то же на СПФ

Да, проблема, так как править нужно в десятке мест.


а какая разница, с какого поля идет адресация? Если я использую струкутуру для описания статьи, то порядок полей я могу поменять, например для того же выравнивания полей. ( сейчас в спф поля идут в таком порядке CELL BYTE CELL BYTE - хотя правильнее было бы CELL CELL BYTE BYTE А теперь давайте поменяем поля местами !8) сколько сразу всего перестанет работать? а ведь не должно переставать!

: <wid ( wid --> start ) 0 VocLastWord - ;

: FREE-WORDLIST ( wid --> ) <wid FREE THROW ;
: CLASS! ( cls wid --> ) <wid VocClass ! ;

Еще примеры?
Я не утверждаю, что это лучший подход! Но тот же wid мог бы находиться в начале записи и мой подход не вызвал бы у вас данного замечания. А какая разница, как в памяти расположены поля?!




А вот я захочу память поберечь!
К тому же я говорил о том, что приходится вникать в код и править его во многих местах вместо одного.


Он станет не чище, а легче. Впрочем и чище тоже. И проще.


я привел начало работы, в качестве примера. Простейшим вариантом было бы поменять порядок полей так, чтобы wid оказался в самом начале и небыло бы тогда "отрицательных полей"(смещений). Сам я еще до конца не решил, как сделать лучше. К тому же я наткнулся на ряд неудобств, связанных с тем, что тот же HEADER определен в двух местах(одинаковый почти) то есть нужно либо оба править, либо выносить его в отдельный файл и подключать в двух местах. Я считаю ваши замечания некорректными, так как они(замечания) не по сути проблемы, а по методике решения(которых может быть много).




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


да причем тут значение поля? что значит Cell+ Cell+ Cell+ ???? мне это ничего не говорит! и не может сказать!


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


Ладно, разговор перерастает в что-то нехорошее 8( Доделаю, приведу окончательный код, если конечно у меня хватит терпения все это перыть 8(

Че делает ARCHIVE да и PRINT то-же?

А вообще
: SHOWME CREATE LAST @ , DOES> @ COUNT TYPE ;

За пределами уже определенных полей (до, после - без разницы)

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

И не должно сказат !!!! Ты эти Cell+ Cell+ Cell+ не должен использовать НИ КАКИМ образом. Бо иначе будет тот самый хак...

Не-а . Просто не трогать это . Тогда и править не придется .

Это где Вы нашли в SPF такой порядок полей? Там-же по человечески написано
0 , 0 , 0 , 0 ,
т.е. CELL CELL CELL CELL ...

И кстати что значит "правильнее было бы "? Чем правильнее?

: PRINT COUNT TYPE ;
ARCHIVE - это уже к целевому компилятору относится. Говорит что данное слово при сохранении в готовый ехешник нужно оставить целиком( вместе со словарной статьей)

Теперь, то же самое, но без LAST @ , в части create?

сейчас у спф формат словарной статьи ( а не словаря, о чем говорилось ранее:)
на сколько я понимаю такой:

cell cfa - sheader
byte flags - sheader
cell backlink - +sword
byte #name - +sword
string name - +sword
cell [wid] - +sword
aligned - sheader
--- отсюда начинается cfa

а правильнее располагать поля по адресам кратным 4 или даже 16 то есть выравнивать.