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

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

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

Вот лично я по собственному опыту работы со строками считаю, что необходимы и достаточны только:
пара видов слов для создания строк
S" ххх" - a u строка(после последнего символа ноль)
" ххх" - az-строка
т.н. "бэкслеш-выражения" вида:
\xAB \n \crlf и пр.;
и несколько простейших операций со строками:
/STR ( a u n -- a u-n ) - укоротить строку
S+ ( a1 u2 a2 u2 -- a3 u3 ) - сложить строки с выделением памяти
SEARCH - ну это уже обычный поиск
А дополнительные слова типа поиск и замена, подстроки и прочее - как расширение в дополнительной библиотеке. Те же поиск и замена легко пишутся через SEARCH. Все! Больше совершенно ничего не нужно. А если надо работать с юникод-строками:
либо отдельно слова для работы с юникод-строками;
либо один вид строк - или юникод, или обычные;
или вводим контроль типов строк - в позиции -1 от адреса первого символа указываем тип строки-кодировку и радуемся жизни.
IMHO: всякие счетчики переменной длины, указатили и прочие дополнительные поля - полная и безполезная ерунда.

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

А никто не хочет сделать строки таким же элементом, как числа?
Т.е. чтоб строки задавались в виде "Это строка" без всяких пробелов? И обрабатывались на уровне интерпретатора/компилятора.

Описание реализации строк нужно только для реализации эффективных алгоритмов работы с ними и если есть функционально полный набор - можно работать одинаково (на высоком уровне) с любой реализацией.

Вот только для разных задач полный набор слов может быть разный...
И работать разные реализации будут с разной скоростью...

В принципе есть предлагавшееся решение из простых - внутри системы (для ПК) хранить все строки с 32-битовым счетчиком (память не экономить, вернее - экономить на программах обработки, а не на строках ), а при обращении к ОС - копировать нужные строки в буфер или в кучу и давать ссылку туда. При соотношении скорости работы процессоров и вызовов ОС может получиться приемлемо!

Хотя по-правильному надо бы проанализировать все разные задачи, в которых используются строки. М. будут решения и получше...

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

WingLion, только функциональность - я был бы за, если бы это было!
У меня ушла уйма времени, чтобы понять, как устроены строки в разных ситуациях в СПФ, теперь, попытавшись перенести в форк - снова обнаружил несовместимость, хотя функциональность присутствует.

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

К тому же даже в форке не возникает проблем, если вы работаете со строками с помощью стандартных COUNT TYPE s" SLITERAL и пр.

может если дать определение понятию "строка" половина теорий автоматически самокалапсируются ?
или например обсудить недостатки на примере конкретной библиотеки "devel\~ac\lib\str5.f " ?
так дискус размазыватся будет меньше, наверное

Что-нибудь изменилось?

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

и почему все эти вопросы не самокаллапсировались?

Потому. что могут быть разные форматы строк ( WingLion ещё столкнётся)

Хм... В конце концов мы имеем только "программы" и "данные". "Данные" в свою очередь - это либо "числа", либо "строки". Тогда почему бы сразу жестко не зарезервировать всего несколько форматов для разных типов представления числа (бинарное, целое..), а все остальное автоматом засчитывать как строки? При этом количество различных форматов строк вообще не ограничивать, а воспринимать это их разнообразие по аналогии с множеством типов кодировок символов. (Как - не знаю...) Скажем, к примеру, через некое "поле кодировки": кодировка №001 - строка со счетчиком, кодировка №002 - ...

(Сорри за сумбур)