Gudleifr: Все сообщения за 23 Марта 2014 года

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

Речь не о том, где будут жить DUP и SWAP, а о том, что они, часто, вообще не нужны.

•  33
•  инфо
•  инструменты
• Ответить на сообщение

Kopa> Если "абстрагироваться" от возможности прямого управления "межпроцедурным местом накопления данных"...
Не надо ни от чего абстрагироваться...
Есть стек возвратов и стек ввода. Они необходимы FORTH для работы.
Если возникает необходимость "где-то что-то сохранить" можно ими воспользоваться,.. но можно и не пользоваться.
Например:
1. Вычисления в стеке ввода (ну тут все очевидно, поэтому мы и предпочитаем называть его стеком данных). Иногда, даже, его "стековая сущность" удобна для вычислений (см., например, мое решение задачи о переправе).
2. Вычисление частично в стеке ввода. Те же WORD и FIND. Адрес слова и флаг IMMEDIATE идут через стек, а само слово - через словарь (тоже, по сути, стек).
3. Вычисление в стеке возвратов - тот же DO ... LOOP.
4. Вычисление в специальном отдельном стеке - стек приоритетов при обработке инфиксной арифметики.
5. Вычисления "где-то рядом". Пример Мура (проблемно-ориентированного языка) для работы с таблицами БД, где все шло через промежуточный файл.
И т.д., и т.п...

•  32
•  инфо
•  инструменты
• Ответить на сообщение

Kopa> И что и где вычислять Форт особо не ограничивает
Именно! И стек ввода - только "один из".

Kopa> А зачем? Можно же добавьте к языку поддержку инфиксной записи на уровень трансляции до использования инфиксных выражений.
Как бы классика. Обоснование можно посмотреть у Мура - он там предлагал подобные "арифметики" использовать и для других целей.
А трансляция? Думаете она не будет использовать дополнительных стеков? Как бы, деревья грамматического разбора предрасполагают...

Kopa> P.S. Есть же статистика использования в реальных програмах слов "перестановки" ячеек стека и вроде не сильно плохая и при программировании задачи не так их и обременительно использовать.
А кто-нибудь видел на FORTH задачи, требующие сложной обработки данных? Как бы, даже, простейшие задачи (та же задача переправа) на кошачьем форуме аукаются применением языка файловых манипуляторов...

•  31
•  инфо
•  инструменты
• Ответить на сообщение

Kopa> Насколько сложных и какой области? Мульти-сервер Eserv сложно? (nncron?)
Kopa> P.S. Что всё таки не хватает Форту?
Ответ на оба вопроса один. Не хватает сложных задач. Т.е. задач, которые бы окупили написание FORTH специально для их решения.

•  30
•  инфо
•  инструменты
• Ответить на сообщение

Kopa> Нету заказчиков на решение задач на Форт, кроме самих Форт пользователей языка.
Что значит "на Форт"? Например, если Вы напишете микроядро FORTH на С и остальная задача будет на нем...
Просто, мы привыкли к неким парадигмам программирования. Например, типичная программа "на C++" - это обычно C-программа с комментариями "через 2 косых" и классами вместо структур (в худшем случае - с жуткими наследованиями из библиотечных классов). Вот - конструктор главного окна, вот - по файлу-форме на все остальные окна... Считать это программой "на каком-то конкретном языке" даже язык не поворачивается. Так и пишут, например, "Qt" - и сразу ясно, где что лежит, даже если Вы плохо знаете C++...
Область FORTH - построение проблемно-ориентированных языков. Нужен такой язык? Тогда Вы поневоле слепите что-то FORTH-образное, на любом языке, который под рукой. (Правда 'nix-ы ушли дальше и Вы сможете писать в их среде гораздо более замысловатые языки).
Минус FORTH - текстовый проблемно-ориентированный язык. Какой уважающий пользователь будет что-то набивать в консоли? Так что программист вынужден играть в это сам с собой. Но, опять же, FORTH, если к нему присмотреться, может читать и другие языки (язык кнопок, язык сообщений, язык пакетов)...

Так что главную проблему можно сформулировать так: "Прежде, чем исследовать границы применимости FORTH-метода, нужно определить FORTH как метод. А не как язык, систему, среду разработки..."

•  29
•  инфо
•  инструменты
• Ответить на сообщение

Veden12> Как Вы себе представляете накопление ввода? Почему для ввода обязательно нужен стек?
Стек достаточен для контекстно независимого интерпретатора (в общем случае). С одной стороны интерпретатор не обязан содержать в себе автомат, допускающий некую грамматику (мол, ввели номер строки, значит сейчас будет оператор, ввели оператор - ждем параметры...); с другой - не мешает такие псевдограмматические переключатели состояний создавать (я называю их оборотами, например, CREATE, и предложениями, например, IF ... THEN).

Veden12> Если они не реализованы в железе.
А зачем? Чтобы заранее себя ограничить?

Veden12> Если слова Форта достаточно высокого уровня, то можно создать под это дело разного рода визуальные среды (скорее проектирование, чем программирование).
Это как? Визуальные среды основаны на минимизации "словаря" (иначе программист не сможет отследить все возможные ситуации), а чем более высокоуровневый у нас FORTH, тем обширнее его словарь.

Veden12> Если же основание разработки предельно низкого уровня, то наиболее удобной будет текстовая среда.
Все зависит не от уровня A, а от уровня P.

И не надо путать проблемно-ориентированный язык с языком среды разработки.

•  2
•  инфо
•  инструменты
• Ответить на сообщение