Смысла во множественном does> что-то не видно. С обычным DOES> понятно - параметризуем исполняющий код слова на этапе создания слова.
Но если исполняющие части разные, то вообще говоря они и параметризоваться должны по-разному. А вот с этим в конструкции с множественным
does> никак.
В итоге все сводится к такому:

И потом можно вызвать код выражений expr0-exprN по его номеру( 0 word ... N word )
без образования дополнительного слова типа test sample, а уже потом 0 sample.

да не совсем верно. "Параметризирует" ведь CREATE часть, а с данными работает DOES> , то есть с уже готовыми.
Насчет нет смысла - смотрите как устроены VALUE и VECT переменные тут даже придумывать ничего не надо.


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

Это и подразумевалось. Но ведь CREATE-часть только одна, и параметризовать она будет одинаково все does>-части.
CONSTANT, VARIABLE, VALUE, VECT в силу их частого употребления реализуют поближе к железу.

елки, экземпляр данных один, и он определяется CREATE частью, а методы работы с данными определяются DOES> частями.
Это очень похоже на ООП.


это понятно, но иногда неудобно опускаться до набирания кодов, а интерфейс удобный.

Я лишь хотел сказать, что метод работы с данными, прописанный в исполняющей части, не основная функция этой исполняющей части, а только способ
доопределения ее основной функциональности, которая и является общей для каждого экземпляра целого класса слов. Класс этих слов задает определяющее
слово, определенное через CREATE DOES>. В случае задания такого определяющего слова с CREATE и несколькими does> (предположим в каждом своя функциональность, и не
факт, что заданные методы работы с данными CREATE-части в каждой does>-части позволят нужным образом доопределить действие этой does>-части). В реальности функциональность
каждой does>-части практически сведется как вы и сказали только к своему методу работы с данными CREATE-части и все. В итоге область применения будет гораздо уже чем у стандартной конструкции CREATE DOES>.

вобщем я ведь согласен с этим.
Идея-то создание единообразного интерфейса для работы с однотипными данными (что в случае с единственным DOES> что с множественными),
причем, работая с множеством обработчиков приходится явно указывать с каким методом надо обрабатывать данные.
В случае с VALUE переменными основной метод выбирается автоматом, а для вызова дополнительных используются префиксы: TO FROM (их могло бы быть и больше). В случае с множественным dose> не понятно, как релизовать умолчание для первого метода (по крайней мере без громоздких конструкций), что не очень приятно (нельзя реализовать классические VALUE и VECT на основе множественного does> ), а так же неприятно то, что конструкцию DOES> ... ; то есть классическую определить через предложенный механизм не получится 8( по крайней мере я пока не придумал, как это можно сделать.

Или сведется практически к конструкциям переключателя или выбору по целому(кроме VALUE и VECT и им подобным).

но это ведь и есть переключатель по целому, к которому просто прикреплены данные!
даже обычный DOES> по сути являет собой обоработчик с прикрепленными к нему данными.
удобство же заключается в том, что для каждого обработчика (а они могут быть очень простыми: NOOP @ ! ) не приходится создавать отдельную словарную статью, и отдельно заботиться о прикреплении к обработчикам данных.
все-то может быть заменено на:
<pre>
: read-data @ ;
: write-data ! ;
: data-adrr ;

: methood SWITCH: read-data write-data data-addr ;SWITCH ;

: sample CREATE 0 , DOES> methood ;
</pre>
то есть действительно можно все реализовать уже имевшимися средствами, но синтаксически это более громоздко получается.
ну, для сравнения:
<pre>
: sample CREATE 0 ,
does> @
does> !
does>
;does
</pre>

Вот пример реализации VALUE и VECT на основе классического CREATE DOES>(здесь только не сделан префикс AT(FROM)),
хорошо здесь то, что префиксы TO и IS не читают из входного потока.

А плохо то, что заводится служебная ячейка $TO.

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

эм, в случае с множественным DOES> TO и FROM не читают из входного потока, и реализованы так:
<pre>
: TO 1 ;
: FROM 2 ;
</pre>
что же касается кода, то у него вообще никаких преимуществ нет, и дело не только в слове $TO , а в том, что исчезает универсальный интерфейс, и такие вещи: работа с адресами, как к VALUE переменными и им подобные уже не возможны.


я с вами не согласен, но, раз вы считаете умолчания проблемой, то множественный does> вам должен нравиться

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

Анализ по этому примеру как раз в плане этой необязательной нагрузки:
Здесь из-за анализа состояния STATE код довольно громоздкий
(а по хорошему-то состояние интерпретатора должно быть одно и нужно локально явно его переключать - это
как раз было-бы примером классического умолчания).
Да и еще: надо метить слова признаком IMMEDIATE, а потом помнить, что вот-это слово меченное и
использовать POSTPONE или [COMPILE], вместо того, чтобы в момент его вызова явно перевести интерпретатор
куда-надо(слова все должны быть исходно одинаковы - опять классическое умолчание).
Вспомнишь тут COLORFORTH.
Я конечно понимаю, что требования к Форт-программисту гораздо выше, чем к мэйнстрим-программисту.
Но почему нельзя изменить Форт-систему без ущемления ее возможностей и при этом снизить нагрузку
на программиста. Например, программируя на форте, программист как правило не предусматривает
встроенных средств контроля, не без оснований считая, что это понижает эффективность кода.
Но можно довольно много контрольного кода исключить(можно и автоматически) при втором проходе
по программе в случае отсутствия ошибок при компиляции программы на первом проходе.
Вообще Форт часто необязательно напрягает программиста, а напрягать его должна решаемая задача.

золотые слова. Чего стоит хотя бы реализация строк.

Ну, ведь как раз умолчания и позволяют "не допускать необязательной нагрузки на программиста" (хотя и не во всех случаях).


?где (в смысле в чем?) у меня в либе от этого анализа только слово ?COMP


уф. ну нету у меня такой проблемы, да и практически невозможно обойтись без режима исполнения при компиляции управляющих структур.
Что же касается переключения контекста для переключения режима компиляции, то, имхо, это еще более сомнительная практика, гораздо более опасная и хуже масштабируемая.STATE прост и тем привлекателен.
(Кстати, POSTPONE лучше никогда не пользоваться - старый COMPILE гораздо лучше)


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

уф, ну какие проблемы с реализацией строк-то?

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

проблемы есть и их наличие нужно признавать.