Прежде всего надо определиться с концепцией использования форта.
В Нове в силу исторических причин появилась концепция: "всё что нужно в основном словаре, всё вспомогательное во временных словарях, и после удаляется".
Такой подход вспомогательности привёл к нынешней в Нове архитектуре построения словаря.
Именно по этой причине изначально каждый словарь может иметь свой обработчик нераспознанных строк. А с недавнего времени и обработчик компиляции определений.
Пример последнего можно посмотреть в библиотеке поддержки лок. переменных (~er/locals/r-local.f)

Но сам подход предполагающий кучу вспомогательных словарей может сильно замедлить поиск. Естественно, из-за большего времени поиска слов.
Чтобы компенсировать это, поиск ведётся не по строке, а хешу от этой строки. В ходе философских бесед с mOleg я пришёл к выводу, что для ускорения трансляции неплохо подойдёт поиск по 4-м цепочкам, а не по 1-й.
Почему 4, а не 8 или 16?
Причина больше в целесообразности. Если цепочек 4, то на 100 слов в каждой в каждой цепочке будет 25. Но во всех вспом. словарях кол-во слов редко когда превышает 100. Если же цепочек будет больше, то некоторые из них будут пустовать. Можно, конечно, добить и более равномерного распределения, но тогда придётся переписывать слово для нахождения номера цепочки от хеша.
Сейчас код такой:

Быстро, дёшево и сердито.
Поэтому 4 цепочки, по моему скромному мнению, оптимальный вариант.
В итоге скорость поиска выросла значительно, если считать в тактах

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

И раз коснулись портируемости, то поговорим и о ней.
Вначале в Нове использовался стековый манипулятор как а-ля высокоуровневый ассемблер, благо он им и был.
Использовался он для быстрого набора определений. Так на нём было написано слово COMPARE .
Помимо этого стековый манипулятор является неплохим DSL для написания участка кода, который будет использован 1 раз и сложновыражаем на форте.
К примеру в одном месте используется код для замены в строке всех символов, которые равны n на символ m
Соотно, входные параметры n m addr u
Вот что вышло на манипуляторе: 3/B1&3..?(1&2..<)1i0dU
А теперь распишите это на форте.

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

Как показывает скромная статистика в Нове с каждым обновлением количество слов становится всё меньше. Убираются в основном редкоиспользуемые слова, да и те переменные, которые на прямую использовать не нужно и/или не рекомендуется.
При этом переменные "остаются" в ядре, но не явно. Они существуют в словах, которые их используют.
Эти переменные де-юре и константы де-факто можно либо заменить, либо подменить на время. Хотя и синтаксиса для этого не предусмотрено, ибо требовалось аж 0 раз.

Сравнение, наверное, не в пользу GForth manual

P.S. Заметил, что в сети много ресурсов изучения языков online (тестирования кода в веб-фреймворке)
и в качестве Форта прикручивают GForth 0.7.3, но при этом функционал терминальной консоли не полный
и не отрабатывает как слово PAGE так и команды управления курсором консоли и запуск того же банального консольного тетриса tt.fs из внутренностей GForth приводит к выводу Escape-последовательностей в диалоговое окно,
хотя штатный Бенчмарк от VFX Forth отрабатывается, но с прохождение ANSI 94 Forth теста похоже (из-за консоли) возникают проблемы.
А так, в online сессии запуска Форт кода можно запустить, наверное, разный Форт-скрипт. (какой нибудь майнер

Ну а где же ниже приведена концепция? Концепция системы - термин из ГОСТ 34-й группы, там можно посмотреть, что это такое и какие должны быть рассуждения на эту тему. Собственно, из-за пропуска этой стадии в нужном виде дальше получается масса чрезмерно детализированных частностей.


Это и близко не тянет на концепцию. Это просто техническое решение, которое то ли корректно, то ли нет... а понять это можно, посмотрев как раз на концепцию системы. Какую задачу решает такой подход? Экономия памяти? Улучшение читаемости исходных текстов? Может быть, что-то еще? В зависимости от решаемой задачи (а набор решаемых задач служит достижению цели, определяемой в концепции) имеет смысл оценивать и принятые технические решения. Может быть, это прорыв, а может, временная затычка, сразу-то непонятно.


"Сильно" - это насколько? И относительно чего? И как это повлияет на потребительскую привлекательность программ?


Почему? Откуда такая статистика?


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


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

В принципе, вирусных идей не так уж мало. Например, бектрекинг был - все о нем писали, ждали каких-то откровений, а это просто вариант подхода, и никакой мистической связи с Фортом у него нет. Ходило словосочетание "насыщение словаря примитивами". То есть надо было обязательно в определенный момент "начать насыщать". По факту это не привело к каким-то заметным шагам вперед и получению продуктов, хотя ожиданий у людей было много. Поэтому кодинг - это далеко не первая и не главная стадия. Не имея проекта, можно плутать в подпрограммах, переменных, словарях, оптимизациях и прочем практически до бесконечности. Или до "наконец-то я нашел нормальную, настоящую работу, и теперь мне не приходится писать на Форте" - бывало в RuFIG и такое.

Тов. Админ.
Во первых, я академиев не кончал.
Если считаете какой-то термин неудачным в использовании, намекните на более корректный, поправлю.

Во вторых,
Экономия памяти? - безъусловно.
Улучшение читаемости исходных текстов? - спорно, но модульность мне ещё ни разу не мешала.
Что-то ещё? - вполне может быть.

В третьих,

Хм, когда-то замерял даже тут на форуме были результаты. Минимум в 50 раз поиск быстрее. Быстрее чего? Быстрее поиска в списке словаря по имени слова. По влиянию для потребителей никак. Хотя если приложение можно считать продолжением форта, и плагин это словарь, то быстрый поиск будет плюсом, но это не точно

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

В пятых,
"а что такого в Форте сделано плохо, и чем тут помогает именно манипулятор"
Помог быстро набросать работоспособный код, над которым на форте ещё надо думать или долго набирать в ассемблере.
Вот аналог на форте.
: change-char \ ch1 ch2 addr u
>R ROT >R
BEGIN 1 RPICK WHILE
DUP C@ R@ = IF 2DUP C! THEN
1+
-1 RP@ CELL+ +!
REPEAT
RDROP RDROP
2DROP
;
Заметьте подобный код по функционалу располагается только в одном месте. Т.е это определение не востребовано в ядре Новы. В итоге код на манипуляторе проще (после подготовки), про размер и скорость не говорю, фиг с ними.
Я ответил на Ваш вопрос?

В шестых,

Скажем так, исторически сложилось. Когда начинал писать ядро некоторые механизмы прописывались, чтоб работали, а не чтоб работали и были понятны при этом. Манипулятор позволял реализовать что-то сложное в одном месте, а не домик из набора юного строителя. Когда начался пересмотр кода роль манипулятора начала снижаться. Теперь его роль минимальна.
Хочу отметить, что в данном случае речь ведётся не о том, что есть в ядре, а о том что было. И почему этого сейчас нет.


Это-то тут причём?
Ну вот в Нове повсеместно используются откатные операции и итераторы. И что? Вирус эволюционировал что ли?
Тот же манипулятор использовался не из-за крутости, а из-за своей лаконичности и возможности делать кодовые затычки. Ну и производительность хотел поднять, молодой был Не далеко правда повзрослел, но это уже детали)

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

P.S. Да, и решения в дизайне по Кварку никто не сможет покритиковать т.к. это закрытый проект по исходникам.
Сам, наконец то, завёл аккаунт на Github (буду сливать туда своё "непотребство" на радость еврофортёрам)


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

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

Дело тут как раз не в терминах, а в том, что попытка притянуть термин "концепция" при отсутствии самой концепции создаст лишнее впечатление, что все хорошо и весь написанный код улучшает систему в целом.


Так а что из этого нужно? И зачем? И когда этим можно поступиться? И ради какого эффекта? Вот комплекс таких "если - то" уже ближе к понятию "концепция". А иначе будут фрагментарные решения, составленные из прочитанного, модного, освоенного и проч., а в сборе это будет непонятно для чего предназначено. Это как из мультфильма "Мадагаскар": "Это же водоросли!" - "На палочке!!!! ". Да на кой ему "на палочке", если он лев и ему мясо надо?


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


Не в том смысле, который я ожидал. Это опять набор аргументов вида "мне же нравится!". Никто не спорит, что можно пользоваться Фортом тысячами способов. Можно и манипулятор, причем десятками способов. Только не стоит после этого ожидать, что всем понравится именно такой вариант. А если я хочу кириллицей? А если я хочу другие слова? Важнее то, что каждая библиотека, прием или алгоритм должны быть соотнесены с тем, для чего они предназначены и что проверяем в итоге. Иначе получится или долгострой или просто веселая игра в программирование разных приятных штук.


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

Так кто ж в районе 20 лет не писал свой Форт? Только зачем на этом уровне застревать, если можно идти дальше.

Ой, какое прелестное и симпатичное мелкое хамство Только чего ж меня в должности-то понижать... "проект менеджер"...

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

Не надо признать, потому что этого нету. Оно вообще из разных категорий. В мире тысячи языков программирования, и только поклонники "странных языков" сидят и охают. Очевидно, потому что культивирование исключительности и является для некоторых людей целью причисления себя к <...>-истам. Форт это дело тоже не обошло стороной, как и любое направление не из мейнстрима. Все там можно, если действительно хотеть разобраться, а не ждать, пока благодарные последователи столпятся вокруг и будут вопить "научите нас, что такое стек, а то мы в шоке".

Кто ж знает как оно у Вас устроено.

P.S. На днях, в магазине Пятёрочки (в районе касс) прочитал такую табличку (размером с плакат) - "Место директора по свежести"
Сфотографировать этот ... (маразм) у меня оказалось нечем.
А, что бы сначала улучшать, необходимо критически рассмотреть существующее решения со своей субъективной точки зрения.
На Github кучу проектов форкают для чего то, наверное покритиковать!
Будут ли слиты изменения форка в оригинальную ветвь, тут уже как звёзды сойдутся.
Мне, для примерa, ничего не помешало доработать исходники Форт системы от Михаила для KolibriOS и разместить в форуме сообщества.

Можно предложить использовать трубу (FIFO) или именованные переменные, но только захотят ли они их, после знакомства с концепцией стека и кратковременной жизни неименованных локальных данных?

В Нове есть цикл со счётчиком?

Уже не так страшно. Или имелось ввиду что-то другое?

Именованными переменными (в том числе и локальными) большинство популярных языков пользуется, так что да, захотят.
А FIFO или LIFO - это просто структуры данных, каждая для своей области применения.

Нет, DO LOOP в ядре отсутствует, поскольку требуется очень редко

Что из этого нужно? Всё и побольше
Зачем? Чтобы итоговое приложение было компактней (всё лишнее уже за бортом), стабильней (кодогенераторы не наслаиваются друг на друга), расширяемей (врем словари могут служить пралгинами, как уже указывалась выше).
Когда поступиться:
Ну если приложение изначально будет какой-то диалоговой средой, то можно накомпилировать в кодофайл всякие полезные определения для решения задачи (сравнение строки с маской, к примеру), естественно, ради удобства пользователя.

Да мне не жалко, я сейчас вот это все аккуратно разберу.

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

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

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


Нет, чтобы улучшать, надо обсудить идею и понять, принимается ли она. Скачивать код и высматривать там что-то - неблагодарное занятие. Можно наисправлять до полной потери исходной идеи, и можно заниматься выискиванием мелочей. Опять же, культивируя позицию "ой, я такой профессионал - там все было плохо, а я инициализировал переменные, исправил mov eax, 0 на xor eax, eax ну и вообще". Сколько там по статистике на гитхабе нафоркали? Ну и где этот мощный рывок мирового программирования вокруг нас?

Оо, да, это конечно продвижение. Это долгострой. С созданием мини-секты "специальных фортеров". Уж Kolibri на что забавная зверюшка, на которую в основном ходят смотреть "ну что там еще придумали", так еще и Форт... и еще и форк Форта. Максимову, видимо, уже не надоест делать себя странным, раз не надоело за последние ~20 лет. Но ему деваться некуда - он уже последовательно загнал себя в угол, и если когда-то давно он еще мог сделать резкий поворот и начать уже программы писать, а не рассказывать, какой крутой компилятор он вот-вот напишет. А у каждого уровня работ есть критические сроки, когда они должны давать ну хоть что-то. За станком надо отдать детали в конце смены. Инженер должен запустить коробочку за дни-недели-месяцы, в зависимости от сложности. Прикладное исследование можно растянуть на полгода-год. Фундаментальное - на 5-10 лет. А сколько там уже ждем результатов от некоторых форт-проектов? Что-то ни ФортОС, ни российского стандарта, ни визуальной IDE не наблюдается. Так что уже надо туда или сюда. Не иметь Форта, дающего осязаемый результат на работе, но убеждать себя, что "еще чуть-чуть" - это самообман. На чужом Форте за пару месяцев надо выдать хоть что-то. Свой - написать, освоить и внедрить за пару лет. Иначе это все техническое сектантство. А чтобы делать, надо тщательно избавляться от ореола исключительности, и понять, что редкий язык - это ни разу не права на странные вещи, а как раз обязанности следить за выполнение таких вещей, за которыми в широко распространенных языках следит сообщество и много фирм-производителей ПО с готовыми управленческими структурами.

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

Ауу! Я о чем пишу-то тут? Надо чуть-чуть глаза поднять и осмотреться вокруг. Посмотреть, как все выглядит с точки зрения коллег, начальства, других программистов. Я что, именно про стек спрашиваю? Такие разговоры - это междусобойчики программистов, которые заканчиваются при наступлении общей усталости от разговора. Пока Форт преподносится окружающим в стиле "тут вот стек, но мы можем FIFO", в глазах непрофессионала это все выглядит очередной блажью, которая скоро кончится. Потому что окружающие смотрят очень просто - распространенность, книги, другие проекты. А тут ловить нечего, но можно (и нужно!) переходить к вещам, понятным непрофессионалу. Как будет выглядеть работа с Фортом. Что это даст на практике. Какие конкретно use case будут решаться на Форте существенно проще и эффективнее. Вот это движение в сторону "Форт для людей". А пока в Форт натаскиваются фрагментарные технологии, и все это подается под соусом "просто все боятся стека, а так бы перешли на Форт" - это все самообман, так можно годами сидеть и ждать.