Часть имен, введенных через NOTFOUND могут стать невидимыми при последующем определении имен.
Это может произойти из-за того, что не предусмотрена проверка на совпадение
для определяемых имен с именами ранее введенными через NOTFOUND.
Для того, чтобы такой конфликт не прошел незаметно необходимо при введении имени, например, через двоеточие произвести поиск этого вновь вводимого имени в статьях NOTFOUND, а не только в обычных словарных статьях.
Для этого надо изменить процедуру поиска имен(добавив поиск в NOTFOUND'ах), таким образом,
чтобы выдавалось сообщение "уже есть такое имя в NOTFOUND".
Для этого в каждой статье NOTFOUND должен быть анализ флага "входные A U - это ссылка
на имя вновь создаваемого слова", с тем чтобы при успешной идентификации
этого имени было выдано сообщение об уже существующем имени(реально хватит выдачи адреса
этого NOTFOUND).
В идеале, конечно, хотелось бы получить сообщение о конфликте имен и в случаях когда новые слова
вводятся через NOTFOUND.
Короче процедура поиска должна быть расширена с вовлечением туда поиска во всех NOTFOUND'ах.

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

PS. Пока конфликта имен во всех случаях(кроме определения новых имен через NOTFOUND)
можно избежать отделив область списка слов от списка NOTFOUND'ов при поиске:

Забыл сказать, что заменить INTERPRET_ надо в исходнике SPF(в файле spf_translate.f), а затем пересобрать систему
пустив на исполнение файл compile.bat.
После этого можно определять через NOTFOUND новые имена, не беспокоясь, что последующие определения новых слов перекроют доступ к именам, определенным через NOTFOUND(надо только не забывать перед NF-именами ставить преффикс %, означающий принудительное переключение поиска имени после преффикса на статьи NOTFOUND без захода в списки обычных слов).

бедный процент
его уже предлагали в начала комментария в стандарт РУФ вместо скобок

Ну можно назвать SSNGC или сокращенно NCG или SG от "the syntactic selection of name and the generation of the code".
Суть как всегда не в названиях и терминах, а в чем-то другом.

ничего не понял. Как могут определяться именя через NOTFOUND?(точнее зачем?)
вообще зачем использовать NOTFOUND, который ну очень неудачная и опасная вещь!
в любом случае, если вы навешиваете на систему поиска не свойственные поиску вещи, то стоит ожидать необычного поведения.

Простите, но я тоже ничего не понял:(



"зачем" - это не столь интересно,
а вот "почему" слова "должны определяться" через NOTFOUND - точно непонятно.
И совсем непонятно, какие специфичесие ужасы ;( произойдут на случай, если слова все-таки будут определятся
через NOTFOUND.

Если речь идёт о чистом spf, то вроде бы должно быть так: при ненахождении какого-то слова NOTFOUNDу
(точнее, первому найденному NOTFOUNDу) передается имя (адрес длина) того, что не найдено. А дальше - уже
самого NOTFOUNDа дело, как поступить:
ничего не делать --> "на Лубянке разберутся" (интерпретер его не узнал - пусть сам и разбирается)
дропнуть --> "отряд не заметил потери бойца"
подправить и поискать ещё --> "мы говорим ::Ленин - подразумеваем FORTH::Ленин"
... и т.д. и т.п.

Кстати, так было реализовано когда-то, или нет? И если да, то оно таким и осталось?

Также этикет велит вызвать предыдущий NOTFOUND, если имя все-таки не найдено - тогда "последним шансом найти
хоть что-нибудь" будет штатный NOTFOUND spf-а. И если он попробует дважды создать слово, то, наверно, мы
увидим что-то вроде "ISN"T UNIQUE", но не обратим внимания ;( (Или же ничего не увидим, если WARNING 0)

Во-первых не слова, а имена(имена это не имена слов), а во вторых не должны, а могут.

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

Все-таки решил дать какие-то объяснения для облегчения понимания смысла предыдущих постов, а то как-то все непонятно(по-фортовски) получается. Под именами, которые являются условным обозначением лексем из входного потока, я понимаю такие лексемы, которые не являются именами слов уже определенных через двоеточие или другими стандартными для форта способами, а также имеющие обработчики в статьях NOTFOUND, тоесть перед ними не должно быть имени слова, читающего следующую лексему из входного потока с целью ее как-то обработать. Имена также как и слова откладывают код в режиме компиляции, а могут и исполняться в режиме компиляции(как слова немедленного исполнения) и также могут исполняться в режиме исполнения.
Но имена, в отличии от слов, не имеют словарных статей, поэтому, например, к ним не применимы слова ', [']. У них нет тела кода. Код имен в режиме компиляции не компилируется(не формируется CALL на адрес поля кода и не пересылается само тело кода как при инлайн-вставке), а генерируется на лету, например, в определяемое через двоеточие слово на основании информации в самом имени обработчиком этого имени, расположенном в одной из статей NOTFOUND. Обработчик начинает формировать(не компилировать) код в памяти, предварительно проверив, что синтаксические характеристики конкретного экземпляра имени из определенного набора(группы|класса) имен соответстветствуют характеристикам этого набора(группы|класса) имен. Код конкретного имени(экземпляра) обладает особенностями характерными только для данного экземпляра. Обработчик таким образом настроен на целую группу имен. Так, например, формируется код конкретного числа из всего набора чисел. Характеристикой класса чисел может быть присутствие в лексеме только символов цифр(не выше текущего основания системы счисления) и знака - в начале, а также максимальное количество этих символов цифр, соответствующее максимальному диапазону. Если конкретная лексема это "число", то обработчик класса чисел формирует код этого конкретного числа. Перед числом нет слова, читающего из входного потока лексему "числа". Этот подход целесобразно применять к лексемам комбинаторной природы, код которых будет по смыслу близок, но иметь для каждого экземпляра свои особенности. Так можно, например, написать ассемблер, ввести локальные переменные и т.п. Текста при этом будет намного меньше, а результат тот же.

Так получилось, что тема состоит из двух вопросов:
1й - "проблема найденная chess-ом"
2й - "NOTFOUND как ГрозноеОружие "
Эти вопросы пересекаются, но все-таки они немножко разные.
Поэтому буду постить отдельно (если успею;)

..по поводу проблемы:

Наверное, лучше всего проблемму посмотреть на каком-то примере попроще:



и дальше:



Случай zz::tst правильно обрабатывается NOTFOUNDом, но если некто (предполагается, что этот "некто" должен
знать, что делает) скомандует что-то вроде , то "спецэффект" с поиском tst из
словаря zz исчезнет.
Так и должно быть. "Это не бага, это фича."
И посему - нет тут никакой проблемы.

Ну во-первых много словарей меня не интересует, одного вполне достаточно (громоздкий механизм переключения контекста чего стоит, да и тот потенциально ненадежный).
Безобразные конструкции zz::tst посему тоже ни к чему(к примеру легко заменяется на имя zz.tst при одном словаре).
А проблема "тихого" перекрытия доступа к нужному коду осталась, потому, что когда слов десятки тысяч и более, этот "некто"
должен быть фортером по имени Ю. Цезарь.

Хочу по этому поводу сказать, что NOTFOUND не совсем тот механизм(в нем есть лишнее)
для введения в Форт более-менее универсального механизма кодогенерации, включающего синтаксический
разбор на уровне лексем. Пусть в форте будет дуализм.

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



.. так это только потенциально. А во время войны "ненадёжный" и "идеологически неправильный" Ил-2
очень даже пригодился.
Если слов очень много - тысячи, то множественные словари + немного аккуратности могут сильно помочь
делу - тогда фортера Цезаря вполне заменит его лошадь
Но если уже пошли десятки тысяч - "трудно плыть в серной кислоте, слишком уж она вязкая";(

А теперь - часть 2-я, о силе NOTFOUNDа, плавно переходящая в стенания;(


Не стоит смешивать синтаксический разбор и кодогенерацию - это вещи принипиально разные, даже в том
случае, если они совмещены в пространстве и времени (как в Форте;) ) И разбор на уровне лексем вообще для Форта
совсем "не родной". А насчёт "лишнего" - честно не знаю. Если это "бесплатный бонус", а не "сыр в мышеловке" -
то почему бы и нет?


..да, да - Вы смотрите с точки зрения NOTFOUNDа, . Лексемы, они же имена "по классике" - это последовательности символов, полученные парсером, которые в Форте обычно либо являются именами слов,
либо сами по себе есть литералами. Обычно, но не обязательно: еще лексема может быть результатом (1)заглядывания
вперед (как в :, CREATE и т.п.), либо (2)аргументом NOTFOUNDа.
Именно в этом случае имя ничего не обозначает, поэтому

И кода как такового тоже нет. И вообще ничего нет. Правда.


А здесь чуть-чуть неточно: раз "кода имен" нету, то и "генерировать", собственно нечего.
Для NOTFOUNDа лексема всего лишь данные, просто кучка байт, и ничего больше. И что с этими данными делать -
это исключительно дело обработчика. Причем не одного "большого и универсального", а конкретного - найденного
первым. Механизм сверхмощный - можно имя подправить и поискать опять(напр. ::), можно в число сконвертить (0x...). А можно и под шумок скомпилить чего-то;). Вариантов - тьма, и какие-то из них могут оказаться бесценными.

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

Задача такая: есть слова, которые могут иметь суффиксы разных видов, каждый вид суффикса имеет
несколько вариантов. Просто "комбинаторный взрыв" какой-то;(. После такого слова с возможными суффиксами - строковые данные для разбора.
Желательно (1) чередовать строки такого винегрета со строками номального фортовского исходника, и (2) всё-таки
писать суффиксы слитно.

Есть несколько решений, отличающихся степенью и формой горбатости ((.
chess, выручайте пожалуйста, может у Вас есть вариант получше.

А решения есть такие:
1) простейшее и тупое: сгенерить все варианты с суффиксами во время компиляции. Вместо ок. 100 слов получим
>3500 - жуть. Мне сейчас, конечно, кто-нибудь отпишет, что избыток оперативки оправдывает всякое уродство - но
это явно не так.
2) Использовать NOTFOUND по полной. Но если где-то все-таки слово вроде MOV уже есть - будет очень некрасиво;(
Кроме того - тормозить будет ужасно.
3) писать суффиксы все-таки раздельно, реализацию этих суффиксов (OR с константой) запихнуть в отдельный словарь. "Базовое" слово должно сделать что-то вроде STORE-ORDER, потом установить порядок поиска только из
этого словаря с суффиксами, интерпретить хвост буффера, после чего от места, где сработал NOTFOUND можно уже
раздирать наш строковый аргумент, и под конец RESTORE-ORDER -- Выглядит получше предыдущих, но уж слишком
навороченно:(, и одно требование нарушает:(

Чувствую, что есть еще альтернатива. Наверное, с применением NOTFOUNDа. Но я ёё не вижу.