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

Автор написал это после попытки разобраться с ALSO и ONLY.
Окончательно добила конструкция
VOCABULARY имя ALSO чего-то ALSO чего-то ONLY DEFINITIONS в ficl
- - - -

Вопрос: Ну вот для чего нужно множество словарей?
Ответ: Чтобы использовать разные слова с одинаковыми именами.

Без этого можно жить?
Вполне.

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

Минус:
1. больший набор имен слов в исходниках

для того, чтобы реализовывать изолированные DSL,
для того, чтобы скрывать внутреннюю организацию какого-либо модуля.
Есть и другие применения.


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

С точностью до наоборот: Замедляется поиск в словаре, т.к. слов становится больше (если не приняты меры по повышению скорости поиска, о чем в последнее время забывают).


ну с чего такой вывод?

Хотел добавить но нечего

Не хочу повторяться, но организация древовидного словаря:

Реализует полноценные DSL с отделением редких слов в отдельные ветви, без необходимости переключаться со словаря на словарь.
Скрывает слова одной ветви для другой.=> имена не заняты

Ускоряется поиск - нет переключения словарей, можно искать только в определённом подмножестве слов.

и одно не противоречит другому?
или вы предлагаете писать ужасы типа: left.make.strait ?
(ксати, чтобы пользоваться такими ужасами ничего менять не нужно, и оно уже давно есть в СПФе...)


Это раз, второе, как часто, по-вашему, приходится переключать словари? И сколько по-вашему в проекте бывает словарей?


все это уже есть, зачем мудрить?

Нет. Обращение к слову такое же как и раньше.
Меняется структура словаря на нелинейную и меняется поиск.


Поиск идёт как и раньше в отдельной ветви - то есть в одном списке - то есть с точки с зрения поиска все нужные словари сцепляются в один.
Чтобы изменить структуру поиска достаточно записать всего 1 адрес в переменную.
При переключении поиск перестаёт затрагивать слова ветвей на одном уровне - т.е. образуется DSL. Очень похоже на русский язык - есть общий набор слов, ствол
ветви - отдельные DSL



Проще реализация при сохранении функционала. Наоборот упрощать.

тогда совсем не понятно, как это должно выглядеть синтаксически (короче, пример в студию).


а теперь возьмите старый форт 79 или 83 стандарта потом подумайте, почему от такой организации отказались.

Во-первых там тоже несколько словарей, а не один!
Во-вторых все словари там линейные, а должен быть один древовидный!

Так в чём смысл тыканья мной в 83 стандарт?

пример обращения к слову:

слово

Просто и банально!

Изменяется способ определения слова ( немного ) и поиска ( тоже немного )

один (в смысле переменная CONTEXT там не была стеком).


они всегда древовидные (и сейчас тоже)


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

Сейчас словари - это список, а не дерево!Или несколько несвязных списков! (Требуется показать древовидность)
Стек словарей не будет нужен! Поиск проходит по внешней ветви по вутренним ветвям прицепленным друг к другу по "стволу", основному словарю и оканчивается на NOOP



Цепляем к корню основного словаря, к NOOP - виден только он.


P.S. Очень в тему viewtopic.php?f=34&t=1120&start=15
Объединяются преимущества и 83, и 94 стандартов.

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


Это ваше мнение. Накладные расходы удержания контекста программистом
во время программирования могут быть гораздо выше накладных расходов
на введение новых слов(ресурсы для поддержания того и другого разные и стоят совершенно по разному).
В большинстве случаев вообще бывает достаточно локального именования.
Концепция контекстных словарей еще как-то работает когда этих словарей 1-2,
а когда больше - себе дороже. Тут полная аналогия с параметрами на стеке -
когда их 2-4 еще куда ни шло, если больше - себе дороже.

Насчет поиска - конечно я не забываю об ускоренном поиске слов.
Но даже и он ускорится когда будет только один словарь.
И соответственно ускорится код программ, которые этот поиск используют.

если говорить о физическом предсатавлении, то дерево.


требуется просто подумать о том, где определен каждый словарь (и определяются последующие)


он нужен совсем по другой причине - с ним просто удобнее.


ТАК УЖЕ БЫЛО - это не очень удобно, хотя работать можно.
Например, без стека контекста было бы значительно неудобнее делать ЦК (в том же СПФе, например).

не обязательно.


тут у всех "свое мнение", напоминать не обязательно


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

vocabulary module
also module definitions

Cerate buff ...
: bla
: bla
: bla

previous definitions also module
: интерфейсные слова тут ;

previous

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


в маленьких словарях ищется быстрее.
в контексте слишком много словарей не бывает.

А вообще, очень много зависит от вашего стиля написания кода, поэтому то, что для вас применимо, ко мне может не относиться и наоборот.

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

1 Не обязательно делать именованые точки прикрепления ветвей.
2 От того что дерево не будет дробиться на списки от маркера до маркера, а будет восприниматься как один список при поиске работать будет проще и быстрее.
3 Сейчас нельзя прикрепить слова посредине основных слов системы и использовать
не весь основной словарь ( либо всё, либо ничего )