Что не хватает Форту?

Gudleifr> Встройте! Например, изготовьте ФортWindows. Хотя бы, наметьте пути "встраивания"...
Форт можно встроить в ReactOS. Eсли ядро ОС на Си
исходники Форта на Си просто добавляется к проекту. Windows слишком крут для начала.
Я встроил в KolibriOS.
Я хотел встроить в Visopsys, но не удалось
собрать под Ubuntu.

Gudleifr> А для превращения ВАЗа в престижный автомобиль надо сзади на веревочку привязать Кадиллак.
Всегда можно найти абсурдный пример из жизни. Этим постоянно пользуется Хищник.

mak44> Eсли ядро ОС на Си исходники Форта на Си просто добавляется к проекту.
А если я еще добавлю исходники FORTRAN, COBOL и BASIC, то это будет C-FORTH-FORTRAN-COBOL-BASIC-ОС?
С каких пор добавление нового компилятора означает превращение в основу ОС?
Поэтому и написал про веревочку.
Чего я не понимаю?

mak44> Однако, целесообразнее Форт встраивать в уже отлаженные ОС, тем самым они становится ФортОС.
Какие полезные свойства получат эти ОС по сравнению с использованием их традиционных пользовательских оболочек?
mak44> Для использования средств Форта в BASIC-е, достаточно в BASIC добавить возможность вызова функций Форта.
Каким образом при работе в среде BASIC может потребоваться обращение к FORTH? Никак не могу себе представить такую задачу.

Gudleifr> И не надо отказывать себе в прерываниях и/или критических секциях.
Я просто не нахожу им применения. Программа, ожидающая действия пользователя или аппаратуры, получается проще, чем программа, построенная на прерываниях. Очень легко определить допустимое время реакции на любое событие. И гарантировать это самое время реакции.
Прерывания нужны лишь в системах реального времени. На практике, такие системы строятся на контроллерах, куда пользователи в принципе не допускаются.
Gudleifr> Исключения - [Visual]BASIC (ценой упрощения пользовательской модели ОС), OKKAM (с его завязкой на многопроцессорность), CUA/GUI (с заложенной внутрь объектной ориентированностью), nix'-shell (с файлами-каналами)...
Прогресс аппаратуры привёл к тому, что при решении достаточно ресурсоёмкой задачи на любом железе придётся сразу же закладываться на многопоточность, причём масштабируемую. А значит эти исключения станут незыблемыми правилами. Или уже стали.
Может я ошибаюсь, но думаю, что ввести в Форт-систему изначально отдельные стеки для разных ядер с адекватной реализацией межпроцессного взаимодействия куда проще, чем в другие языки.
Конечно, неплохо бы сначала разобраться со всякими MPI, OpenMP, OpenCP. Но это - на очереди.

Veden12> Программа, ожидающая действия пользователя или аппаратуры, получается проще, чем программа, построенная на прерываниях.
Еще в 70-е годы ребята из XEROX показали, что ПО для ОС, основанных на процессах, и ОС, основанных на сообщениях, изоморфно (ON THE DUALITY OF OPERATING SYSTEM STRUCTURES, HUGH C.LAUER, XEROX CORPORATION, PALO ALTO, CALIFORNIA, ROGER M.NEEDHAM, CAMBRIDGE UNIVERSITY, CAMBRIDGE, ENGLAND).
ИМХО для FORTH это означает одно - завязка обмена информацией с ОС на обработку ПОТОКА (WORD). Какая разница ждать ввода слова от пользователя с консоли, или считать словом Win-сообщение, или заголовок IP-пакета?

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

Gudleifr> ИМХО для FORTH это означает одно - завязка обмена информацией с ОС на обработку ПОТОКА (WORD).
Согласен. Если Форт не способен самостоятельно рулить железом (хотя, если я не ошибаюсь, он для того он и создавался), ничего другого не остаётся.
Но вот вопрос: если прерывания не навязаны извне, то нужны ли они Форту? Не противоречат ли они его концепции?
Gudleifr> Какая разница ждать ввода слова от пользователя с консоли, или считать словом Win-сообщение, или заголовок IP-пакета?
Ожидаемые события, в отличие от внезапных, позволяют сэкономить время на переключении контекста и получить существенно большую прогнозируемость поведения. А вот в плане функциональности - да, разницы никакой.
Gudleifr> Проблемы управления просто становятся проблемами синхронизации. Проще это все выглядит только потому, что программисты очень плохо знают, чем это чревато.
Я тоже. Мои знания паттернов параллельной обработки (отсутствие оных) явно недостаточны для этого. Что ж, буду учиться.

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

Veden12> Но вот вопрос: если прерывания не навязаны извне, то нужны ли они Форту? Не противоречат ли они его концепции?
Что значит "не навязаны извне"? Прерывания - свойство железа, а не ПО. FORTH они просто не мешают. (Пока структурные фортеры не начинают требовать структурной обработки исключений). Допустим, мы переписываем на FORTH операционную систему MS DOS... Очевидно, мы имеем язык системных запросов в качестве проблемно-ориентированного языка. Вместо EXPECT (ACCEPT) мы имеем вектор прерывания 21h, вместо WORD - чтение регистра AX, FIND ищет нужное слово-обработчик по значению AX. Работа со стеком ограничивается кадром, в начале которого сохранены регистры... Компиляция не используется. Но это FORTH!

Gudleifr> Прерывания - свойство железа, а не ПО. FORTH они просто не мешают.
И не помогают? Считаю, что аппаратные прерывания в процессе работы препятствуют созданию хорошо продуманной единой программной архитектуры. Я ничего не потеряю, если не буду вводить базовые слова для поддержки прерываний?
Gudleifr> Допустим, мы переписываем на FORTH операционную систему MS DOS...
Gudleifr> Компиляция не используется. Но это FORTH!
Да... Надеюсь, никто не станет создавать ОС на Форте. Во всяком случае, в сегодняшнем понимании ОС. Форт хорош для разработки полностью законченных приложений. Одним таким я и занимаюсь. Хочется верить, что несмотря на непосредственную работу с железом, отстутствие интерпретатора/компилятора Форта в конечном продукте (а в средстве разработки - слов CODE и END-CODE) никак не позволит отнести его к операционным системам.

Veden12> Я ничего не потеряю, если не буду вводить базовые слова для поддержки прерываний?
EXPECT, WORD, FIND, NUMBER... INTERPRET, в конце концов?

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

Допустим, мы пишем оконное приложение. Мы можем предусмотреть все возможные действия пользователя в любой последовательности и предложить решение для любой ситуации. Например, что будет при нажатии клавиши табуляции (переход к следующему полю) в поле X, если вкладка Y неактивна, а поле Z не заполнено...
Задача настолько NP-полная, что решить ее никакой FORTH не поможет.
...
Откажемся от создания "законченного приложения". Будем рассматривать все действия пользователя, как проблемно-ориентированный язык. Глагол - кнопка, прилагательное - окошко ввода... Не будем стесняться выдавать сообщения "Не понял" и "Сам дурак!"... Вот это и будет FORTH-подход. Пусть пользователь сам думает, как решать его задачу, какие кнопки и в каком порядке жать... (Полезным бонусом будет то, что интерфейс завсегда при таком подходе здорово упрощается. А заодно растворяется и необходимость в ООП).

mak44>> Eсли ядро ОС на Си исходники Форта на Си просто добавляется к проекту.
Gudleifr> С каких пор добавление нового компилятора означает превращение в основу ОС?
Форт-система представляет собой набор слабосвязанных процедур и словаря
по средствам которого эти процедуры можно найти. Процедуры ядра некой ОС тоже
можно занести в словарь Фора. Конечно, обычным EXECUTE можно вызвать только
те процедуры, которым не надо передавать параметры. Как вариант, можно
создать эквивалент EXECUTE, который перекладывает параметры со стека данных
в регистры или на стек возвратов, в зависимости от того, что этой процедуре
требуется. Переренные ядра ОС для форта представляются в виде форт-констант
возвращающие адреса этих переменных. С помощью Форта в ядре ОС мощно загрузить
новый драйвер представленного в виде форт-исходников. Вообще, Форт в ядре ОС
может с этой ОС все, что угодно вплоть до полного преобразования.
Из ядра ОС можно выкинуть все кроме того, что поддерживает Форт.
Оставшуюся часть можно загрузить в рантайме. Тем самым мы получаем
загрузчик операционных систем.

Veden12> Каким образом при работе в среде BASIC может потребоваться обращение к FORTH?
Ну например перенаправить ввод/вывод. Вообще, вызов функций форта я предусматриваю
как вызов функций вообще. Форт представление может быть стандартным представлением
для всех языков.

mak44> Оставшуюся часть можно загрузить в рантайме. Тем самым мы получаем
mak44> загрузчик операционных систем.
Для реального использования Форт в качестве первичного языка ОС необходима технология эффективной оптимизации Форт кода в код целевого процессора, но и с тем что имеется можно экспериментировать

Veden12>> Я ничего не потеряю, если не буду вводить базовые слова для поддержки прерываний?
Gudleifr> EXPECT, WORD, FIND, NUMBER... INTERPRET, в конце концов?
EXPECT не требует прерываний, остальные слова - тем более. Я про специальные слова, назначающие слова-обработчики на внешние события. Насколько я знаю, ни в одном стандарте таких нет.
Gudleifr> Откажемся от создания "законченного приложения". Будем рассматривать все действия пользователя, как проблемно-ориентированный язык.
С одной стороны, законченное приложение на Форте - это и есть интерпретатор проблемно-ориентированного языка, к созданию которого закономерно приводит процесс ассоциативного наращивания лексикона Форт-системы сообразно поставленной задаче. Разве можно иначе?
С другой стороны, это ни в коем случае не оболочка (shell). Пользователь не должен расширять набор команд и/или создавать скрипты. Иначе скрипты становятся самостоятельными программами, в отношении которых я ничего не могу гарантировать. Это уже не подпадает под определение "законченного приложения" и создаёт массу проблем. Интерпретатор непосредственных команд пользователя (в обход предлагаемого интерфейса) не нужен в принципе.
Gudleifr> Пусть пользователь сам думает, как решать его задачу, какие кнопки и в каком порядке жать... (Полезным бонусом будет то, что интерфейс завсегда при таком подходе здорово упрощается. А заодно растворяется и необходимость в ООП).
Интерфейс можно усложнять или упрощать, но только в расчёте на пользователя, а не на сложность программы. Правда, в русском переводе Раскина из названия загадочным образом исчезло слово "Humane"... Искренне надеюсь, что это ничего не значит.

mak44>>> Из ядра ОС можно выкинуть все кроме того, что поддерживает Форт.
Вы это и сделали в Колибри?

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

Veden12> С другой стороны, это ни в коем случае не оболочка (shell). Пользователь не должен расширять набор команд и/или создавать скрипты.
Тогда и FORTH не нужен. Именно для этого он и был придуман.

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

Veden12>> Каким образом при работе в среде BASIC может потребоваться обращение к FORTH?
mak44> Ну например перенаправить ввод/вывод. Вообще, вызов функций форта я предусматриваю как вызов функций вообще.
Какие именно функции Форта могут потребоваться сверх функций BASIC'а? Примитивные слова Форта не нужны конечному пользователю если под рукой BASIC. Остаются вторичные слова, использованные как строительный материал при создании интерпретатора BASIC'а. Но зачем они пользователю?
mak44> Форт представление может быть стандартным представлением для всех языков.
Как это возможно? У каждого языка свой синтаксис, своя логика.

Veden12>> С другой стороны, это ни в коем случае не оболочка (shell). Пользователь не должен расширять набор команд и/или создавать скрипты.
Gudleifr> Тогда и FORTH не нужен. Именно для этого он и был придуман.
Что меняет, если пользователем интерпретатора проблемно-ориентированного языка фактически является фильтрующий интерфейс (описанный тем самым языком), а не человек непосредственно?

Veden12> Что меняет, если пользователем интерпретатора проблемно-ориентированного языка фактически является фильтрующий интерфейс, а не человек непосредственно?
Что вы имеете в виду под "фильтрующим": целевой, безопасный, умный, настраиваемый..?

Veden12>> Что меняет, если пользователем интерпретатора проблемно-ориентированного языка фактически является фильтрующий интерфейс, а не человек непосредственно?
Gudleifr> Что вы имеете в виду под "фильтрующим": целевой, безопасный, умный, настраиваемый..?
Целевой, безопасный.

Veden12>>> Каким образом при работе в среде BASIC может потребоваться обращение к FORTH?
Вы всерьёз полагаете, что программирование на Бейсик может перекрыть возможности Форт подхода?
Один из примеров новых языков Factor автор которого интенсивно программировал на Java.
Но уровень пользователей может быть разный и Бейсика им может вполне хватить
У меня был опыт промышленного программирования на Бейсике, но расстался я с ним без особого сожаления (но не так сразу т.к. было ещё некоторое время для желания "докончить" некоторые разработки сделанные на нём) "Мелкие" кирпичики Форта оказались эффективнее в использовании для програминга.

Veden12> Целевой, безопасный.
А чем это отличается от "нормального" пользователя?
Парой селекций-проекций на входе-выходе?

Единственная неприятная ситуация, которую я могу придумать: "на том конце" некому вести с нами диалог. Т.е. мы не можем уведомлять его об ошибке и требовать сделать что-то по-людски.
1. Нам дана в ощущениях грамматика входного языка, которую нам придется соблюдать. В этом случае FORTH не особенно нужен - пропускаем правила через lex и yacc - и получаем программу автоматически. Тем более, что большая часть подобных "грамматик" тривиальна.
2. Допустим, "грамматика" слишком сложна (или даже нам не до конца известна). Пишем FORTH-систему, состоящую из двух: одна, как может интерпретирует вход (то и дело вылетая), другая ведет диалог с диспетчером/тестером.
3. Никакая отладка не помогает, но входной язык имеет возможность перезапроса (как, например, сетевые протоколы). Ими и пользуемся.
4. Боюсь, иначе уже никакой FORTH не поможет.

Veden12> Какие именно функции Форта могут потребоваться сверх функций BASIC'а?
Был BASIC под SPF. Куда-то пропал.
Я сделал Си под SPF. За него могу отвечать.
Там есть примеры.

Gudleifr> 1. Нам дана в ощущениях грамматика входного языка, которую нам придется соблюдать. В этом случае FORTH не особенно нужен - пропускаем правила через lex и yacc - и получаем программу автоматически. Тем более, что большая часть подобных "грамматик" тривиальна.
mak44> Я сделал Си под SPF.
Отличный пример!

mak44>> Я сделал Си под SPF.
Gudleifr> Отличный пример!
У меня тоже был вариант Си -> SPF4 и тоже рабочий, но без "мимикрии" Cи LCC кода в макро вариант Форта.
Обощёлся разработкой и проверкой Васк-еnda и поддержкой рантайма SPF4 кода (cм. на fforume)
хотя можно и состыковать с вариантом mak44 до полного автономного рабочего варианта.

Kopa> Вы всерьёз полагаете, что программирование на Бейсик может перекрыть возможности Форт подхода?
Всерьёз я полагаю лишь одно: надо исходить из задачи. Если первично решение, а не задача, то это уже игра.
Kopa> Один из примеров новых языков Factor автор которого интенсивно программировал на Java.
Спасибо, гляну. Пока что самым универсальным языком высокого уровня мне кажется Lua.
Kopa> Но уровень пользователей может быть разный и Бейсика им может вполне хватить
Никак не могу понять, чего может настолько не хватить программисту на Бейсике, что он будет вынужден обратиться к фундаментально иному языку, причём в рамках того же Бейсика. Как - тоже непонятно.

Gudleifr> А чем это отличается от "нормального" пользователя?
Gudleifr> Парой селекций-проекций на входе-выходе?
Для интерпретатора - да. А для пользователя, если интерпретатор не содержит ничего лишнего и не является средством разработки алгоритмов - такой интерпретатор попросту непрошибаем (рассчитываю на это).
Gudleifr> Единственная неприятная ситуация, которую я могу придумать: "на том конце" некому вести с нами диалог. Т.е. мы не можем уведомлять его об ошибке и требовать сделать что-то по-людски.
Входная фильтрация и ограниченность интерпретатора оставляет нам только аппаратные ошибки, справиться с которыми ни одна программа уже не сможет.
Gudleifr> 1. Нам дана в ощущениях грамматика входного языка, которую нам придется соблюдать. В этом случае FORTH не особенно нужен - пропускаем правила через lex и yacc - и получаем программу автоматически.
Лексический анализатор - да, но не обработка поступающих и поддерживаемых данных.
Gudleifr> 2. Допустим, "грамматика" слишком сложна (или даже нам не до конца известна). Пишем FORTH-систему, состоящую из двух: одна, как может интерпретирует вход (то и дело вылетая), другая ведет диалог с диспетчером/тестером.
При отладке это обязательно. Более того, второй интерпретатор - интерпретатор самого Форта. Я правильно понял?