<Убрано во исполнение решения Hishnik>

Нельзя менять класс грамматики - она регулярная (автоматная). Попытки ввести разбор инфиксных выражений превращают Форт в алголоподобный язык со своеобразным синтаксисом, просто написанный на Форте. Однако Хаскелль, написанный на Си, который написан на ассемблере, не остается ассемблером. Точно так же Форт не останется Фортом, если после выполнения какого-то количества слов на вход пойдут строки вида int a; a = b + c; data[a+3] = (d + e)*f; Да, согласно старому мему "Форт может все". И вообще он "среди небожителей великий Индра, среди летающих - могучий Гаруда, средь огней - негасимый Агни" и так далее в стиле Махабхараты. Однако есть простое практическое правило - если программист знает язык и имеет базовую подготовку в своей области, он должен иметь возможность самостоятельно разбирать программы, написанные на этом языке для своей области. Иначе его придется переучивать под другой язык.

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

<Убрано во исполнение решения Hishnik>

Нет, это не просто общее требование. Любые классификации должны вводиться не просто так, а для упрощения процесса разработки. Если живые организмы классифицировали на птиц и рыб, то в целом понятно, что птицы летают, а рыбы плавают (исключения рассматриваем отдельно). Соответственно, их надо ловить по-разному, от птицы получаем перья, крылышки и ножки, а рыбку надо чистить. Классификация языков программирования также преследует определенные цели. Языки 3-го класса (регулярные) разбираются простейшим автоматом. Языки 2-го класса - магазинным автоматом (т.е. по сути надо завести стек внутри компилятора, что в Форте заменяется стеками в рантайме, включая стек control flow). Это разный уровень работы, и выполнить для того и другого надо разный набор действий - по объему кода, сложности отладки, получаемым результатам, объему последующей работы по описанию языка и т.п.

По разбору - именно регулярная. Выделили токен - нашли адрес. Одна из находок Форта - слова немедленного исполнения, что и позволило вместо классификаторов строк и констант получить действительно язык программирования. Векторные слова (да, слова с несколькими точками входа), POSTPONE - это уже детали. Ни того, ни другого может не быть, вместе с тем VECT и QUAN будут в реализации присутствовать. Программист обычно действует не строго в рамках одной концепции, и если кому-то показалось удобным/уместным добавить "нестрогую" технологию, то кто ж ему запретит? Да, текущий Форт есть смесь исходной идеи и последующих добавок, выполненных конкретными авторами (у которых своя предыстория). С тем же VECT - я прекрасно понимаю, что название уже не соответствует внутренней начинке (у меня нет никаких CFA внутри). Потому и "указатель" - это просто возможность хоть как-то зацепиться за образ. А еще есть "кодофайл", есть "насыщение". Оно может восприниматься как удачное или неудачное, но так сложилось.

О, интересно. А почему это печально?

<Убрано во исполнение решения Hishnik>

А герой Мольера ведать не ведал, что говорит прозой Таки ему это не мешало говорить именно прозой, потому что на поэзию он как-то не тянул. Разве что случайно срифмовать пару слов. Так и фортеры в основной массе точно так же "случайно рифмуют".

А как я могу запретить что-то постороннему человеку? Он купил компьютер, пусть хоть Форт пишет, хоть Си, хоть молотком его разбивает. Вот только и он меня не может заставить мгновенно распознать Форт, если реализует какой-нибудь синтаксический анализатор, а потом напишет func1(int x, int y). И встроить в свой Форт его анализатор сможет не каждый. А вот взять слово с некоторой стековой нотацией и несложным действием и добавить в свой транслятор могут многие.

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

Так хочется думать апологетам computer science откуда-нибудь из СпбГТУ. Там много фанатов лямбды, генетических алгоритмов и лексического разбора. В действительности это навык, который просто не всем нужен. Просто стараниями рафинированных теоретиков лексический разбор превратился в подобие диамата - все слышали, никто толком не знает, но все боятся признаться, что не разбираются. Что интересно, если человек не хочет писать лексический анализатор, то он может его и не писать, и все равно получить Форт.

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

Форт удачно мимикрирует под алголоподобные языки. Главное - оставаться в рамках постфикса/конкатенативной компиляции.

<Убрано во исполнение решения Hishnik>

Мне хочется только, чтобы он работал. Будут ли рады теоретики, мне как-то не очень важно.

В целом да, потому что слова немедленного исполнения занимаются формированием кода самостоятельно. CREATE DOES> способны создать такие вещи, которые заранее предусмотреть невозможно. Переключение контекстного словаря может сделать совершенно другим даже ранее проанализированный текст. Тем оно и ценно

Оно слишком скучно, чтобы класть в железо.

<Убрано во исполнение решения Hishnik>

<Убрано во исполнение решения Hishnik>

Оба пункта решаются выработкой соответствующих навыков и применением собственных шаблонов кодирования. Сложные элементы не надо класть на стек вообще. Слишком много OVER TUCK NIP ROT - признак неразберихи на стеке, которая решается введением вспомогательных слов и локальных переменных. Надо откатить данные? Заводим временные структуры, работаем в них, при необходимости переписываем их в постоянные или же не переписываем. Работает безотносительно языка.

<Убрано во исполнение решения Hishnik>

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


Шаблон - понятие аморфное.



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

<Убрано во исполнение решения Hishnik>

Совсем не очевидно. Что такое все эти слова? Требуется ли DEPT перед всем этим? Только ли DEPT (может, там еще есть другие подразделения, которые обозначаются не DEPT). Видно, что LIST - это точно слово с каким-то действием внутри. А остальное? Слова, константы, модификаторы? LIST способно самостоятельно подстроиться под разные комбинации, или же данный синтаксис - просто мимикрия под языки запросов к БД? Так что вопрос сложности открыт. Он и вообще открыт (чем мерить сложность?), а в данном случае требует уточнения. Это сложность реализации? Или сложность работы с системой? Или сложность сопровождения и отладки?

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


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




Визуальное впечатление другое. DO LOOP не используется.

Я уже не говорю о различиях кода, построенного вокруг КА, и кода из цепочек IF THEN. Они могут быть логически эквивалентными, но писаться и отлаживаться в разных стилях.


"Ограничения" уровня логики кодирования являются сугубо тактическими и решаются не волшебными лексиконами (вариант: сборкой мусора, статической типизацией, фреймворками), а выработкой четкого ТЗ и его детализацией в нужных местах. Далее программист может сам решить, в каких местах ему добавить тесты, в каких разработать вспомогательные инструменты (в том числе серию CREATE-определений), а в каких просто внимательно следить за тем, что на стеке.