Re: НА ЧТО СПОСОБЕН И НА ЧТО ДОЛЖЕН БЫТЬ СПОСОБЕН FORTH?

gudleifr

Удалил, т.к. коллеге вожжа под мантию попала.

Hishnik писал(а):

А данный форум является по сути базой данных, содержащей сообщения подписчиков. И принадлежит данная БД тому, кто платит за хостинг.

См. там - http://www.gudleifr.h1.ru/g91.html.

mOleg

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

mOleg

начнем помаленьку

gudleifr писал(а):

Можно ли превратить FORTH-программу в полностью литературный текст? Этому мешает то, что FORTH интересует только смысл высказывания, а человеческие фразы содержат много слоев информации:

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

mOleg

gudleifr писал(а):

А, если мы рано или поздно вставим в свою FORTH-систему несколько сложных интерпретаторов, то почему мы должны ограничивать интерпретацию потока комманд только простейшим из них?

все же Форт не ограничивает (по крайней мере правильно спроектированный), а ограничивается простейшим вариантом. Входной поток остается во власти программиста, пишущего код, и это хорошо видно по словам типа S" и другим, "забегающим вперед интерпретатора" во входном потоке. Помнится, были предложения, а возможно, и варианты создания такого интерпретатора, в котором нераспознанные лексемы откладываются в виде адресных ссылок на вершину стека данных, только такой подход таки путь к глюкодрому. Сейчас мы имеем возможность создать хоть 100, хоть больше различных "разборщиков текста" и в произвольном порядке их вызывать в нужном нам порядке, собственно каждое слово вмешивающееся в разбор входного потока и является таким (предельно простым) интерпретатором

chess

mOleg писал(а):

все же Форт не ограничивает (по крайней мере правильно спроектированный), а ограничивается простейшим вариантом.

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

chess

Вот простейшие примеры исключения инструментального контекста из оперативной памяти программиста:
Нужно создать слово 2ROT

Код:

: 2ROT ( d1 d2 d3 -- d2 d3 d1)
2SWAP 2>R 2SWAP 2R> 2SWAP 2>R 2SWAP 2R> ; \ стандартный вариант - есть инструментальный оперативный контекст

Вот варианты когда его нет:

Код:

2ROT: ( d1 d2 d3 -- d2 d3 d1 ) 6\345612 ; \ прямой доступ к параметрам на стеке с использованием комбинатора(манипулятора)
2ROT: ( d1 d2 d3 -- d2 d3 d1 ) d3!d d2!d d1!d   d2 d3 d1 ; \ прямой доступ с использованием локальных имен
2ROT: ( d1 d2 d3 -- d2 d3 d1 ) C=A B=@P $ C A=@P $ C @P=C $ 10 C=@P $ 10 @P=B @P=C ; \ прямой доступ с помощью комбинаторов( комбинаторы - имена команд Х86)

ps. Как следствие, варианты без оперативного инструментального контекста пишутся быстро и без ошибок.

mOleg

gudleifr писал(а):

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

Мне это утверждение не понятно.
Впрочем, интересно, что автор может предложить на сей счет?

gudleifr писал(а):

Конечно, есть мнение, что при построении ядра можно ограничиться самыми простыми механизмами, а, затем, полностью их переопределять при построении своих "продвинутых" модулей, но стоит ли так делать?

все же, обычно, доопределять

gudleifr писал(а):

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

полностью согласен.

gudleifr писал(а):

Разве что, убрать из него, на всякий случай, литералы?

совсем непонятное мне утверждение, поясните, если возможно

gudleifr писал(а):

3. Словари. Безусловно. Этот механизм компенсирует отсутствие всякого рода виртуальных функций и позволяет экономить пространство имен не хуже методов объектно-ориентированных функций. Надо ли его развивать? Обычного поиска в трех словарях (стандартном, поиска слов, добавления слов) вполне достаточно, однако, при проектировании этого механизма сразу следует учитывать, что механизмы работы со словарями могут очень сильно отличаться от словаря к словарю.

Развивать надо!
Трех словарей недостаточно (если уметь ими пользоваться).
Механизм работы со словарями не должен отличаться вообще для разных словарей, в то время, как механизм работы словаря не должен быть фиксированным. Поясню, имеется ввиду, что интерфейс к словарю должен быть однородный и одинаковый, а методика поиска имен, создания определений, распределения пространства, и пр. для каждого из них будут свои. Собственно, тут надо смотреть в мой форк

чуть позже продолжу

gudleifr

Я так понял, что слово "литературность" на Форуме лучше не употреблять.

mOleg писал(а):

Уже обсуждалось...

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

gudleifr писал(а):

...необходимость в таких механизмах становится явной, когда FORTH ставится задачи интерпретации других потоков текстовых данных - формул, регулярных выражений, записей баз данных (жестко форматированных или с разделителями).
Более того, по мере усложнения FORTH-системы, может возникнуть и потребность общения программы с человеком "на естественном языке".

mOleg писал(а):

Т.е. даже трансляция текста собственными мозгами "хромает".

С того места статьи, где начались картинки, подобное поведение программы становится "не багом, а фичей".

mOleg писал(а):

Все же Форт не ограничивает (по крайней мере правильно спроектированный), а ограничивается простейшим вариантом [разбора входного потока].

Например, возьмем тот же Trac, интерпретатор, которого нас бы попросили написать на Forth. В этом случае, написание парсера входного потока, пожалуй, будет единственной нетривиальной частью этого проекта. Тогда, в нашем проекте будет явная узловая точка, ниже которой интерпретация входного потока происходит одинаково для Forth и Trac, а выше - две непересекающиеся ветви. Понятно, что чем выше расположена эта точка, тем проще использовать Forth для данной (или похожей) задачи. Сделать интерпретатор таким универсальным (и сложным), чтобы он мог "просто переключаться с режима на режим"? Понятно, плохо. Значит, остается одно - сделать подобные модули ядра "легко съемными и взаимозаменяемыми". Как раз про это и писал

gudleifr писал(а):

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

gudleifr писал(а):

Конечно, есть мнение, что при построении ядра можно ограничиться самыми простыми механизмами, а, затем, полностью их переопределять при построении своих "продвинутых" модулей, но стоит ли так делать?

chess писал(а):

Нужно создать слово 2ROT...

Не нужно. За создание таких слов надо карать.

mOleg писал(а):

совсем непонятное мне утверждение [уборка из шитого кода литералов], поясните, если возможно

Литералы - вещь очень машинно- и программно-зависимая, заменив их ссылками, мы резко повысим универсальность.

mOleg писал(а):

Трех словарей недостаточно (если уметь ими пользоваться).

gudleifr писал(а):

Обычного поиска в трех словарях (стандартном, поиска слов, добавления слов) вполне достаточно

Я не совсем понял, чего недостаточно, словарей или набора путей для поиска?

mOleg

gudleifr писал(а):

Значит, ожидание от умных программ какой-то человекообразности имеет обоснование.

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

gudleifr писал(а):

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

почему некрасиво?

gudleifr писал(а):

Какие источники слов возможны в принципе?1. строка, введенная с консоли;2. блок (строки), считанные из явно указанного файла;3. строка, считанная из файла, подменяющего стандартный поток ввода;4. строка, программно сформированная в каком-либо буфере;5. искусственно сформированное слово.

А зачем ограничиваться только текстовым представлением информации?
Вот, может быть токенезированный текст, к примеру, или последовательность нот (вспоминая с ностальгией Loom), последовательность иконок, да мало ли что еще.

gudleifr писал(а):

Из широко применяемых нюансов надо упомянуть разный способ обращения с отдельным словом:* поиск его в словаре;* поиск слова в специальных таблицах;* распознавание слова, как представления числа (или символьного литерала);* преобразование слова перед его поиском;* разбиение слова на отдельные фрагменты и обращение с каждым, как с отдельным словом.

Все свести к работе со словарями

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

gudleifr писал(а):

Как и в предыдущем случае, реализовать каждый из вариантов достаточно просто, но "серебрянной пули" опять нет. Более того, попытка унифицировать обработку случаев (1-3) породила избыточное количество переменных, которые приходится проанализировать, чтобы понять, откуда надо брать следующеее слово (особенно, если анализируемый поток вдруг иссякает).

Это утверждение опять не понятно совсем. Поясните пожалуйста.

gudleifr писал(а):

FORTH в этом случае оказывается не на высоте. Слова-синонимы, конечно, возможны, но сохранить их так, чтобы самому не запутаться вряд ли возможно. Кроме того необходим некоторый формализм меток блоков (как у Кнута). Блок должен быть явно помечен как, например: ОПИСАНИЕ, ПРЕДИКАТЫ, ЗАГЛУШКА, ЗАПРОС, ОТЛАДКА, РЕАЛИЗАЦИЯ и т.д. Необходимо так же хранить подобные блоки рядом, да еще с указанием применимости каждого из них в конкретном случае: самодокументирование, отладка, операционная система такая-то...

Где-то уже было: внутри словарной статьи были сделаны дополнительные поля, в которых размещались коментарии к слову, исходный текст слова, какие-то дополнительные метки. Что за форт-система не помню - это было еще в 16-битные времена.

mOleg

gudleifr писал(а):

Я так понял, что слово "литературность" на Форуме лучше не употреблять.

нет, почему же

gudleifr писал(а):

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

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

gudleifr писал(а):

Сделать интерпретатор таким универсальным (и сложным), чтобы он мог "просто переключаться с режима на режим"? Понятно, плохо. Значит, остается одно - сделать подобные модули ядра "легко съемными и взаимозаменяемыми".

но ведь это УЖЕ ЕСТЬ! вот я о чем. Пишем во входном потоке:
bla bla bla TRAC: тут нужный текст , дальше ограничительный символ(либо символьная последовательность) ограничитель, и мы снова с нашими bla bla bla.
Давай возьмем пример слова s", которое умеет преобразовывать строку в подходящий для компиляции вид:
s" \t\n bla bla bla \" bla bla \" \\ "
это, конечно же, не разбор текста ТРАС, но чем вариант-то не устраивает?

gudleifr писал(а):

mOleg писал(а):совсем непонятное мне утверждение [уборка из шитого кода литералов], поясните, если возможно Литералы - вещь очень машинно- и программно-зависимая, заменив их ссылками, мы резко повысим универсальность.

гм, не понял, всеравно не понял. Или вы ведете речь о возможно вариации размеров констант?

gudleifr писал(а):

mOleg писал(а):Трех словарей недостаточно (если уметь ими пользоваться).gudleifr писал(а):Обычного поиска в трех словарях (стандартном, поиска слов, добавления слов) вполне достаточноЯ не совсем понял, чего недостаточно, словарей или набора путей для поиска?

я пользуюсь большим количеством словарей и возможностями контекста

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

gudleifr

mOleg писал(а):

почему некрасиво [приходится выдирать из универсального интерпретатора отдельные куски и применять их в нужной последовательности]?

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

mOleg писал(а):

А зачем ограничиваться только текстовым представлением информации?

Незачем, но задача от этого проще не становится.

mOleg писал(а):

Все свести к работе со словарями

И иконки тоже?

mOleg писал(а):

оно, последнее [разбор слова на подслова] меня угнетает

И тем не менее, ты ниже предлагаешь подобный подход для решения задачи нетривиальной интерпретации?

mOleg писал(а):

Это утверждение [про большое количество слов управляющих источником входного потока] опять не понятно совсем.

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

mOleg писал(а):

Пишем во входном потоке: bla bla bla TRAC: тут нужный текст , дальше ограничительный символ(либо символьная последовательность) ограничитель, и мы снова с нашими bla bla bla.

Вот оно - столь нелюбимый тобой разбор слова на подслова. Скорее требуется что-то вроде:
* поток А - выделение слова способом А - интерпретация
* поток Б - выделение слова способом Б - интерпретация
...
* стандартный поток - тупо ищем пробелы - интерпретация
бла бла бла ДАЛЕЕ-ТРАК #(пц, CR/LF)#(пц, #(чц))#(вернись-в-Forth) бла бла бла
С возможностью подавать в виде входного потока иконки, программные прерывания и что-там еще было в "Игре в Бисер"?
А в большой системе: поток i - выделение слова способом i - системная очередь - выбор по приоритету - интерпретация.

mOleg писал(а):

Или вы ведете речь о возможно вариации размеров констант?

В первую очередь.

mOleg писал(а):

я пользуюсь большим количеством словарей и возможностями контекста

Мне ближе не трактовка словаря не в качестве слова - префикса класса, а слова - формирователя фокуса внимания.

mOleg

gudleifr писал(а):

И иконки тоже?

почему нет? Собственно, не важно, что использовать в качестве ключевой информации для идентификации определения в словаре.

gudleifr писал(а):

eg писал(а):оно, последнее [разбор слова на подслова] меня угнетает
И тем не менее, ты ниже предлагаешь подобный подход для решения задачи нетривиальной интерпретации?

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

gudleifr писал(а):

mOleg писал(а):Это утверждение [про большое количество слов управляющих источником входного потока] опять не понятно совсем.Почему же, семейство SOURCE, по-моему и слишком велико, и достаточно беспомощно в нетривиальных случаях.

не плохо бы пример нетривиального случая.

gudleifr писал(а):

mOleg писал(а):Пишем во входном потоке: bla bla bla TRAC: тут нужный текст , дальше ограничительный символ(либо символьная последовательность) ограничитель, и мы снова с нашими bla bla bla.Вот оно - столь нелюбимый тобой разбор слова на подслова. Скорее требуется что-то вроде:* поток А - выделение слова способом А - интерпретация* поток Б - выделение слова способом Б - интерпретация...* стандартный поток - тупо ищем пробелы - интерпретациябла бла бла ДАЛЕЕ-ТРАК #(пц, CR/LF)#(пц, #(чц))#(вернись-в-Forth) бла бла блаС возможностью подавать в виде входного потока иконки, программные прерывания и что-там еще было в "Игре в Бисер"?А в большой системе: поток i - выделение слова способом i - системная очередь - выбор по приоритету - интерпретация.

увы, опять ничего не понял 8( причем тут разные потоки? Потом, интерпретация все же ассоциируется со всем процессом: разбор входного потока + поиск лексем в словаре + действия над ними.

gudleifr писал(а):

mOleg писал(а):Или вы ведете речь о возможно вариации размеров констант?В первую очередь.

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

gudleifr писал(а):

mOleg писал(а):я пользуюсь большим количеством словарей и возможностями контекста
Мне ближе не трактовка словаря не в качестве слова - префикса класса, а слова - формирователя фокуса внимания.

Я о классах ничего не говорил, собственно, "фокус внимания" вполне подходит.

И все же оформите, пожалуйста, вторую статью, там, где про Фобос

chess

gudleifr писал(а):

Не нужно. За создание таких слов надо карать.

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

gudleifr

<Случайно удалил>

chess

gudleifr писал(а):

Это точно. Не могу провести ту грань, где инструментальный контекст сменяет оперативный.

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

Re: НА ЧТО СПОСОБЕН И НА ЧТО ДОЛЖЕН БЫТЬ СПОСОБЕН FORTH?

Кто сейчас на конференции