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

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

Например: слова дополнительного форматирования.
или определении слова :> ( "name" -- ) , как замены ' name после его определения.
( в этом случае логичным решением, могло стать слово :CREATE )
Оправдано ли введение несовместимости заменой слов оперирующих двумя ячейками,
на более логичное с префиксом D?

P.S. Плохо совместимых версий "мой" форт систем уже предостаточно:)
Может, все таки, попробовать минимизировать уровень несовместимсти
при использовании наработок из наиболее представленных Форт систем?

Спасибо за идею.


это про форматный вывод? {# #} и прочие? Или речь о другом?


оно достаточно просто разрешается с помощью ansinames.f, зато синтаксис получается более регулярным.


увы, никуда не денешься от этого. С другой стороны, совместимость тянет за собой статичность в развитии 8(


какие вы видите пути разрешения проблемы?

[quote]Оправдано ли введение несовместимости заменой слов оперирующих двумя ячейками,
на более логичное с префиксом D?[/quote] Вряд ли.

Префикс [b]D[/b] у слов, работающих с числами двойной длины (порядок важен), а префикс [b]2[/b] у слов, работающих с парами значений. Например, D+, D* — это для чисел двойной длины, а 2SWAP, 2! — любые пары значений, например, (addr u). Слова 2+ и 2* исключения из этого правила (исторически сложилось). Ссылку на Элизабет Райзер см. в Этимология, проФорт.

А вообще, делать SMAL32 из SPF никто не запретит ведь
Кто чего достиг, тот так и делает.

гм. А кто делает СМАЛ32 из СПФа?


в том то и беда, что выделяется, кстати, есть еще 2/
Отмазка "так сложилось" мне очень не нравится, поэтому, во избежание бардака все сведено к одному префиксу.
А для совместимости со "стандартными именами" имеется список имен алиасов, которые можно подключить.

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

Возможно, но это уже обсуждалось, причем, даже на форуме.
С другой стороны, чем плохо решение с алиасами?

А вообще, данный предмет, как предмет в себе, критике не подлежит.
Доступно обсуждению лишь степень пригодности для тех или иных целей (в том числе, сравнивая с альтернативами), воспринимаемость, производимое впечатление, личное нравится/не нравится (в соответствии с собственными представлениями о том, как должно быть).

Например, я считаю, что имя "?BIT" не подходит для заданной там семантики. Ну и что?

Тем, что Ваш код (DDROP, DDUP, DSWAP) будет обладать худшей воспринимаемостью, и давать минус всей системе. По моему, например, этот минус уже дают cp866, особая манера отступов и обозначений. Впрочем, в этих моих высказываниях ни капли конструктива

вобщем да

Если это имелось ввиду, то
идея общая ( формировать слова из существующих)
и применяется при формировании слов в некоторых Форт системах
Например можно так: 'TYPE адрес переменной хранения вектора для TYPE
( так можно прийти к суффиксам, префиксам и др. частицам



Обосновано брать употребимые слова, и может быть механизмы формирования ядра
из других Форт систем. ( но термин "обоснованно", в данном контексте, достаточно
субъективен)



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



Достаточная статичность стандарта Форта и его некоторый минимализм,
позволяет Форту, и с учетом этого, быть востребованным языком:)


P.S. При чтении документации к Small32 есть некоторые сомнения в необходимости
введения в систему такого количества слов

Для меня лично DDROP, DDUP, DSWAP обладают большей воспринимаемостью чем 2DROP, 2DUP, 2SWAP.

Для меня предпочтительнее было-бы DROPD, DUPD, SWAPD.

А вот я привык к 2DROP, 2DUP, 2SWAP. Так что мешает сделать так:

Тут вообще-то о форке от mOlega говорят У него там словарь сам числа распознает, а слова типа 2DUP, 2/, 1+ и т.п. этому мешают.

имелась ввиду идея создания топика


я вижу другое решение: ядро делается наиболее удобным образом с привлечением нужных средств, пускай и не общеприятых, совместимость вся находится в библиотеках. Ядро же только обеспечивает возможность подключения любой из библиотек. По крайней мере сейчас у меня такой курс. Надо, чтобы было совместимо с АНСИ - подключаем .\lib\ansi.f
надо иметь под рукой стандартные средства типа DUMP .S ORDER WORDS и прочие - подключаем .\lib\all.f

Таким образом гораздо проще работать с ядром. Именно по этой причине из последней сборки исключена опция сборки "толстого ядра".

ну, давайте тогда посчитаем, на сколько же медленнее работает <# состоящий из:
: {# ( base --> ) TO BASE@ SPAD-TOP HLD A! 0 HOLD ;
: <# ( --> ) BASE @ {# ;
и позволяющий выводить числа в необходимой системе исчисления без плясок с <s>бубном</s> BASE.
например:
: N. ( n --> ) S>D 0x0A {# #S #> TYPE ;