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

А теперь по изменениям.
Добавлено слово TEMP-OUT ( temp-voc -- ) убирает из стека контекста временный словарь и освобождает память под него. А то расплодилось в Нове временных словарей и все нужны
Описана внутри форта структура используемая для перехвата ошибок. Теперь её можно использовать не боясь обвинений в хаках. Что задокументировано, то не хак (c).

Мысли:
Создание для Новы вторичного форт-транслятора в байткод.
Обоснование зачем надо: форт-системы обычно загружают все определения, даже если они не будут использоваться в конечном коде. Это лишние затраты памяти. Поэтому дух кривого перфекционизма требует как-нибудь это исправить.
Соответственно, при загрузке исходников они изначально компилируются в простейший байткод (хватит нескольких инструкций: вызов форт-слова, вызов слова опр. в байт-коде, число, адрес слова в байт-коде).
Если такой транслятор не смог отработать, то и фиг с ним. Отранслируем стандартным.
Весь байткод будет собираться во временном словаре.
Если нам понадобится этот код, то система найдёт его через NOTFOUND (ибо влом усложнять механизм стандартного поиска), преобразует байткод в натив и скомпилирует в текущий словарь.

Понятно изложил мысль?

NOTFOUND так много забирает времени при сборке... 5-ть 10-ть кило лишнего, сейчас никого не напугают..

Чё ито он много времени забирает? Я несколько не понял, проясните, будьте любезны

Думаю, сделаю в Нове функцию печати (TYPE) пользовательским вектором для расширяемости.

А то решил повозиться тут с трансляцией JSON и обратил внимание, что скопировать тот или иной объект трудная задача, особенно если он вложенный.
Поэтому пришла в голову мысль:
Поскольку в ООП для JSON зашита функция печати, то механизм такой:
Перенаправить весь TYPE-вывод в строку (у нас получится классический json) и результат снова отранслировать!
Дело осталось за малым - научиться перенаправлять вывод вместо файла в строку и желательно не квадратно-гнездовым способом
Впрочем, это не сложно

Сделать >STR бывает полезно. Потом с этой строкой можно делать все, что обычно делают со строками.

Сейчас в Нове используются 4 пространства:
Пр. кода (изначальное)
Пр. данных (строки и переменные)
Пр. словарных статей (хранение заголовков слов идоп. информации)

И особняком стоит
Пр. пользовательских переменных, поскольку ни с одним из пр. выше оно не пересекается.

Мне тут подумалось, что должен быть механизм создания пространств.
Ведь по факту можно выделить ещё 2 пространства
Отдельное под переменные
Отдельное под лямбды и безымянные участки кода.

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

Что для этого нужно?
Пока опускаем насколько это вообще востребовано.

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

Зададим каждое пространство так:

STRUCT: space
CELL -- S>hash \ хешированое обозначение пространства
CELL -- S>start \ начало старта пространства
CELL -- S>end \ конец пространства
CELL -- S>xt \ код для корректности контроля пространств.
STRUCT;

Тогда пространства служебная информация будет распределена так:
Код (основное пр-во), Строки, Словарные статьи, Переменные, Лямбды

Соот-но у структуры словаря должны быть такие поля:
...
4 CELLS -- L>LLFA
CELL -- L>MFA \ смещение до указателя, по которому хранится указатель до пространства механизма пространств. А что вы хотели? Так проще организовать наследование.
CELL -- L>compFA
CELL -- L>notfoundFA

Сейчас в Нове с доп. полями сложнее.

Как выразить тогда слова

: DP \ должен возвращать указатель, где хранится HERE соотв. пространства. только для стандартных
0
BEGIN BEGIN
space *
CURRENT @ L>MFA @ @ + S>start EXIT
ALTERNATIVE: 1 AGAIN \ на данные
ALTERNATIVE: 2 AGAIN \ на слов. статьи

;


: HERE
0
BEGIN BEGIN
space *
DP + @ EXIT
ALTERNATIVE: 1 AGAIN \ на данные
ALTERNATIVE: 2 AGAIN \ на слов. статьи

а с остальными словами для управления пространствами придётся поизголяться


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

Из недостатков: придётся повозиться со словами для работы с кодофайлом

у меня оно называется хранилищами.
Вот так, думаешь, реализуешь, рассказываешь другим, а потом наслаждаешься наблюдениями за другим изобретающим то же 8)

Где код этих хранилищ можно посмотреть в форке?
Желательно дайте путь до файлов)

И тогда уж скажите, что ещё интересного есть в форке)
А то мне вспоминается только настраеваемый поиск в словарях

Мне вообще не нравится такой механизм обработки ненайденных слов поиском NOTFOUND в словаре. Чем он лучше простого векторизированноно определения, которое можно в любой момент изменить/восстановить без проблем, + нет лишних заголовков, + не тратится время на поиск одного и того же слова по несколько раз?

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


Это в СПФ NOTFOUND каждый раз искался в словаре, в Nova просто прописано в поле, откуда обработчик берётся.