А вы проверьте ;)

На самом деле, Михаил очень интересно и элегантно употребил слово COUNT :)
И, кроме того, исправил ошибку в приведеных ранее определениях, которые сваливаются на 0 0 TYPE

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

А чего спорить-то? В описании TYPE cказано - печатать u символов начиная с адреса addr. Вот пускай так и печатает. А вдруг нам надо будет через него например бинарные данные слать куда-то в порт или файл, а он тут на нуле будет спотыкаться? Зачем усложнять его поведение? Для az строк - PRINT, для a u - TYPE.

Только вот при визуальном анализе текста человек "споткнется" на таком куске. К тому же его поведение зависит от формата представления строки, так что путешествия по символам может и не получиться. Hint: а что, если строки ограничены не 255 символами, а большим количеством?


Ни то, ни другое. Это документированное поведение системы при печати строк (оправдываться тут незачем).


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

По спецификации DPANS94, слово COUNT сдвигает адрес ровно на размер символа (считая, что размер счетчика совпадает с размером символа). Если в форт-системе слово COUNT ведет себя по другому, то лучше его и по другому называть. Например, в SPF4 есть слово XCOUNT, которое полагает размер счетчика в размер ячейки; есть слово STR@ ( addr-str -- c-addr u ), которое из объекта "строка" дает адрес и длину блока памяти; есть слово ASCIIZ> ( addr -- addr u ) которое из адреса ASCIIZ-строки (т.е., завершаемый кодом 0) дает адрес и длину.

Учитывая стандартное (де-факто среди современных форт-систем) поведение, слово TYPE документированно недостаточно. Было бы лучше упоминуть там о коде 0 так же, как для слов "S=", "SMOVE" и т.п.


не "оправдываться", а "оправдывать" — в смысле обосновывать.

Возможно, этому и стоит уделить больше внимания в подробном описании слов. На "стандарты" и "де-факто" у меня не то чтобы стойкая аллергия, а скорее попросту игнорирование, если есть далеко перекрывающие стандарт требования рынка или отрасли. В 90-х годах, в эпоху Borland, были строки со счетчиком. Сейчас - ASCIIZ и Unicode. Если "Баба-Яга против", то это проблемы Бабы-Яги. Работа со словами, поддерживающими оборудование или стандартные интерфейсы программной платформы, идет от этой платформы, а не от устаревших стандартов.

"Оправдывать" и "обосновывать" - разные вещи.

Я как раз и обратил внимание на случай, когда размер счетчика с размером символа не совпадает. Причем тут уже идет "возможность работать с большими строками" vs "когда-то давно написали вот так". Зачем мне помнить, как именно думали 20 лет назад? Я вон уже и от круглых скобок в качестве комментариев отказался - это 20-30 лет назад фортерам было удобно троллить скобками-комментариями противников постфиксной записи Почему вообще современные приемы программирования должны учитывать реалии прошлых поколений?

Часть темы можно уже отделить "Баг или Фича" :)

Имхо, просто достаточно указать, что система не является совместимой со стандартом(ами) и отправить за справками к документации.

к документции по C++ что ли?

Речь то о том, что В ОПИСАНИИ КВАРКА отсутствует объяснение этой особенности поведения TYPE, а приведено описание именно стандартного TYPE...
Потому в баги и записал. Если не баг кварка - значит баг описания.
Либо то, либо другое третьего не дано.

Мне таки проще поправить TYPE. Все равно я им не пользуюсь.

Для такого случая лучше определить другое слово (с другим именем), вместо "COUNT".

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

Например, слову TYPE можно дать семантику ( addr-asciiz -- ) и даже аккуратно описать это в документации. Но, до каких пор систему оправдано называть форт-системой, если давать известным словам другую семантику?

Лучше иметь одно и то же слово для действий с одинаковым алгоритмическим смыслом. Если в Форте уже есть несколько представлений строк, то для COUNT ожидаемым действием является "из представления строки в виде начального адреса некоей структуры дать представление вида АдресПервогоСимвола, ДлинаСтроки".

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

В документации вполне аккуратно описано слово PRINT с таким действием. Более того, так сложилось, что это основное слово для вывода строк.

У TYPE стековая нотация (c-addr u -- ). С дополнительным механизмом контроля недопустимых символов в строке.

Имеет смысл, объявить малоинформативное слово COUNT устаревшим и заменить например, c той же семантикой
для байтовых символов на C@++ :)