02.01. БЕЗ НАЗВАНИЯ

ТОМ II. ЧЕЛОВЕК ИГРАЕТ С МАШИНОЙ
Строим игру из того, что есть.

ГЛАВА ПЕРВАЯ. БЕЗ НАЗВАНИЯ

Мои любимые произведения о воистину компьютерных играх:
ВЛАДИМИР ПИРОЖНИКОВ / НА ПАЖИТЯХ НЕБЕСНЫХ / 1982 ТЕМА #29, АБЗАЦ #2312
МАРЕК БАРАНЕЦКИЙ / ПРАВО АЛЬТЕРНАТИВЫ / 1984 ТЕМА #129, АБЗАЦ #2303
ДЭВИД БИШОФ / НЕДЕТСКИЕ ИГРЫ / 1983 ТЕМА #129, АБЗАЦ #2772
Обратите внимание на даты. То ли публикация этих произведений пришлась на то время, когда я как раз решал, стоит ли мне становится программистом. И поэтому они у меня отложились все вместе. То ли это было осознание писательским сообществом того факта, что кибернетика умерла и можно быстренько подвести итоги?

ТЕКСТОВОЕ ПРОГРАММИРОВАНИЕ

В первой части заметок, я попытался рассмотреть вопрос создания простых игр на основе простых идей.
Конечно, мы видим, что, если какая-либо простая игра приобретает популярность, на ее основе делают сложную (и не одну). Причем сложность здесь подразумевается в виде т.н. "контента". Т.е. практически не имеет отношения к, собственно, игре, а выполняет лишь украшашательно-завлекательную функцию.
Тут, главное, не перепутать, что считать сложным. Да, нарисовать целый мир, в котором будет бегать герой, сложно. Но это сложность художника. А засунуть в этот мир трехмерную куклу игрока - сложность аниматора. А выдавать всю эту живую картинку со всеми тенями, бликами и брызгами на экран с приемлемой скоростью - сложность... да, программиста, но не того программиста, который сам играет в то, что делает, а несчастного работяги, погрязшего в технических описаниях "новейшего аппаратно-программного обеспечения, без использования которого ваша игра будет третьесортной".
Если мы хотим погрузится во все эти сложности, то играть придется, в первую очередь, в манагера, а не творца.
Я же хочу поиграть в программирование игр: придумать мир игры, в котором мне будет интересно творить; определить правила своей игры с будущим игроком; ограничить свои хотелки компьютерными возможностями (и, как сказано выше, гораздо более скромными своими возможностями).
Т.е. допустим, что простенькая игра-концепция нас не устраивает, мы хотим целый мир "на пределе собственной сложности". (Это такой закон кибернетики: управляющий должен быть сложнее управляемого).
***

При такой постановке вопроса сразу же возникает проблема: а что делать-то?
С простыми играми было просто: работали проходы и сверху-вниз (раз задача понятна, ее вполне можно разбить на подзадачи) и снизу-вверх (мы были вправе ожидать, что работа понятных нам процедур будет предсказуема).
А тут? Например, напрягая все свои слабые художественные способности, я нарисую какого-нибудь гвардейского сержанта татуинских бабуинов. Или придумаю замечательный алгоритм его поведения на поле боя. И что? Либо весь остаток жизни я буду рисовать подобных чудиков и их алгоритмы, и до самой игры дело так и не дойдет, либо я все-таки сделаю макет игры, но для бравого сержанта там, уверен, не будет места...
И наоборот, начав с общих мест, я буду все добавлять и добавлять варианты, которых будет так много, что я так и не начну писать...
В итоге, сложная программа обычно оказывается гениально не работающей или работающей тривиально. Так появляются многочисленные "компьютерные офисы", которые могут все, но... при условии, что пользователь знает, как это сделать без помощи офиса.
***

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

Что значит "компьютер понимает текст"?
- Во-первых, он должен уметь выдавать текст пользователю. Для создания иллюзии "разумности", как я писал в предыдущей части заметок, всего-то достаточно подобрать баланс между ожидаемыми и неожиданными ответами. С этим задолго до компьютеров справлялась, например, "Книга перемен". Назовем это ЗАДАЧЕЙ ВЫВОДА.
- Во-вторых, компьютер должен понимать текст пользователя - ЗАДАЧА ВВОДА. Обычно эту задачу решают созданием языков программирования. Последние настолько просты, что компьютеру практически не нужно их понимать, только считать, что в каком месте "предложения" стоит. Вспомните, как в первой части мы объясняли компьютеру, что делать, на BASIC.
- В-третьих, можно обойтись еще более простым средством - решить УПРОЩЕННУЮ ЗАДАЧУ. Создать некую форму/бланк для ввода данных и некую простую систему пересчета/упорядочения этих бланков. Так устроен отдел кадров предприятия, библиотечные каталоги... да все базы данных, наконец, так устроены.

Только два замечания:
1. Программисту удобнее думать, что задачи ВЫВОДА и ВВОДА - зеркальные отображения друг друга. Но это не так даже на уровне обмена простейшими сообщениями-сигналами. Об этом всегда надо помнить.
2. Компьютер бы легко справился со всеми тремя задачами, но ему не дают... Операционные Системы. Они из всего возможного спектра решений выбирают только несколько простейших, а остальные практически воспрещают.

Например, MS Windows. Просто вывести текст на нем невозможно, нужно создать некий графический объект и уже в него этот текст запихнуть (как если бы мы вынуждены были перед писанием заметок сами создать для них бумагу). Проще уж создать некий "документ" (по сути, решить УПРОЩЕННУЮ задачу) и поручить Windows его обработать "на общих основаниях". С задачей ВВОДА Windows "справляется" аналогично - сам создай окно... Не умеешь, купи программу (MS Visual Studio), которая умеет. Да и язык ВВОДА должен быть не текстовым, а пиктограммно-кнопочным, с рычагами и колесиками, как станок начала двадцатого века. Зато, Windows утверждает, что полностью решил для нас УПРОЩЕННУЮ задачу - напридумывал кучу бланков/документов на все случаи жизни. И текстовые, и табличные, и отчетные...

Еще неприятнее, когда приходится работать с парой Операционных Систем. Например, для этого тома заметок мне придется использовать две: ту, что у меня и у вас на компьютере (я предполагаю, что это Windows этого века), и ту, что обеспечивает вам чтение этих заметок (это "движок" данного форума и ваш браузер - программа для его рассматривания).
Получается несколько петель:
- Игра на своем поле: ВВОД в текстовом редакторе (или в окошке браузера) - ВЫВОД результатов в окошке браузера (промежуточные результаты запоминаются в файлах).
- Писание заметок: ВВОД в текстовом редакторе - переформатирование данных - загрузка на Форум.
- Чтение заметок: распаковка браузером - ВВОД в окошке браузера - ВЫВОД в браузере.
Т.е. чтобы выложить сюда для чтения упомянутые выше книжки, я должен сначала придумать, как они должны выглядеть на экране браузера и как они могут храниться на форуме. Затем написать соответствующие программы переформатирования/распаковки. А в итоге вы будете наблюдать в этом сообщении ссылки на "Почитать". Если я достаточно преуспею, то на Форуме останутся только ссылки и технические комментарии, а все статьи будут храниться "где-то рядом".
***

И еще пара ссылок на книгу Ч.УЭЗЕРЕЛЛА ЭТЮДЫ ДЛЯ ПРОГРАММИСТОВ, М. "МИР", 1982 -
- ПЕЧАТНИК-ПОДМАСТЕРЬЕ - как писать программы форматирования текста - ТЕМА #117, АБЗАЦ #1944;
- НОВЫЙ АТТРАКЦИОН - как писать язык для написания программ форматирования текста - ТЕМА #117, АБЗАЦ #1975.
***

Для примера я выбрал, пожалуй, одно из самых неблагородных занятий - перенос настольной (сложной!) игры на компьютер (На тот момент, когда я это писал, почти все тексты той игры уже были практически переведены/отсортированы. Оставалось только начать да кончить... И где оно?- G.). При этом, обычно, теряется все полиграфическое обаяние и удовольствие от общения, но взамен ничего не дается. Однако, мне деваться некуда: слишком уж необходима "игра в написание игры". Буду, правда, надеяться, что в какой-то момент произойдет переход количества в качество, и откроется какая-то возможность создания, действительно, игры компьютерной.
***

ВСЕ ОЧЕНЬ ПРОСТО

Меня постоянно попрекают тем, что я не отслеживаю всю цепочку действий по запуску моих "игр", начиная от копки Пуск Windows. Современное программирование слишком уж похоже на запуск заводского станка - точные заученные движения профессионала, производящие со стороны впечатление немыслимой сложности. Хотя, единственная сложность здесь - зубрежка алгоритма: "Положи фиговину поперек загогулины, дергани за пимпочку..."

Как научиться программировать, если вы кое-как запомнили, как в Интернет выходить и тексты распечатывать? Не просто, а очень просто: нужно только понять смысл танцев с бубном, а поняв - добавить в них пару кувырков.

Итак, что "на самом деле" происходит в компьютере, когда вы "пишете оперу"?



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

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

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



Во-вторых, см. на новый рисунок. Он отличается от старого только пониманием того, что в некоторых документах могут содержаться инструкции по работе с другими документами (или инструментами). Конечно, эти инструкции могут быть записаны в специальном "компьютерном" виде, непонятном человеку (об этом мы поговорим в третьем томе Записок), но многое можно сделать и вводя инструкции на вполне человеческом языке (том же BASIC). В том же "офисе"... Чем я здесь и занимаюсь.

Боюсь, однако, что предлагаемый мною способ "программирования подстановкой макросов" может показаться не совсем понятным. Но, ведь вы же, наверное, умеете копировать и переносить куски текста внутри документа? Значит умеете и макроподставлять - заменять текст-метку в одном документе текстом из другого документа (этой странички). Надо только запомнить, что почти все программы надо сохранять как обычный текст без форматирования (потом приписывая к имени специальный суффикс: .vbs - для Visual Basic, .js - для JavaScript, .cmd - для самой Операционной системы, .htm - для браузера...).

ПОСТАНОВКА ЗАДАЧИ

В наличии имеются кое-как распознанные, структурированные и местами переведенные правила "тактических" игровых систем (категория #3 настольных игр - "шашки", тип 1а военных игр - "абстрактные с миниатюрами"): StarGrunt II (уровень взвода), DirtSide II (уровень батальона) и FullThrust (космические схватки). Кроме того, есть "недостающее" дивизионное звено - правила BOOTS, TRACKS, AND HOVERSKIRTS (BOOTS, TRACKS, AND ROTORS), выдранные из Сети, как есть.
Надо:

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

Конечно, хотелось бы делать все это в специальном "офисе", позволяющем проходить все перечисленные в предыдущем посте "петли" в одном диалоге с компьютером, а не постоянно переключаться вручную с программу на программу. И такие "офисы", в общем-то, есть. Тот же, например,  MS Office. Есть люди, которые могут на таблицах MS Excel игры программировать. Но эти "офисы" имеют очень высокий порог вхождения (нужно достать нужную версию, научиться в ней работать...), а подсев на них, очень трудно расстаться, даже, если, новые задачи уже не вписываются в привычную схему.
Конечно, если у вас есть такой "офис", то можете пользоваться им. Думаю, вам не составит труда повторить на нем то, что я тут буду делать на коленке.

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

Мой опыт работы с большим количеством текстов свелся к наличию четырех универсальных конструкций (решения УПРОЩЕННОЙ задачи), позволяющих не утонуть в потоке информации.

1. Обычный текст. Снабженный гиперссылками, позволяет визуализировать практически что угодно. Обязательна возможность макроподстановок. С другой стороны, с текстом могут быть связаны некие соглашения о его верстке - отступы, выравнивание, шрифты, буквицы, иллюстрации и т.д.
2. Электронная Таблица (ЭТ). Объединяет в себе универсальную экранную форму и способ пересчета данных при изменении одного из них.
3. Реляционная База Данных (БД). Позволяет хранить множества данных в виде таблиц и выдавать их в виде виртуальных таблиц. Кроме того, может визуализировать/редактировать данные согласно их типам.
4. Иерархический документ. Годится не только для построения оглавлений (каталогов), но и для построения списковых БД. Желательна возможность хранения альтернативных путей к данным. И хранения макропеременных. И наличия операции сравнения поддеревьев - унификации.

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


На худой конец, можно попытаться обойтись и меньшим числом конструкций (В МИРЕ НАУКИ 11/1984 ТЕМА #15, АБЗАЦ #386).

ИСТОРИЧЕСКАЯ СПРАВКА

Я очень люблю древнюю компьютерную литературу. Хотя она и гораздо требовательнее к уровню подготовки читателей (заставляя иногда исчирикивать по паре-другой листов бумаги при очередном "далее - очевидно"), но это окупается. Размышления с позиции "что нам надо от компьютера" вместо "берите, что дают" привлекают гораздо сильнее.
Поэтому просто сошлюсь на книгу: В.М.Брябрин, Программное обеспечение персональных ЭВМ, 1988 - ТЕМА #15, АБЗАЦ #386. Точнее, на подробное описание там системы Framework (с. 187-193). Пусть это и "давно обычные для нас вещи". Ведь, первая версия этой программы была создана в 1984 для процессора 8086 и монохромного дисплея и занимала в памяти всего три сотни килобайт (т.е. в тысячи раз меньше современных программ). Так что надо удивляться не примитивности и обычности тех программ, а беспомощности современного программирования, не способного создать ничего нового.

ТЕМА #118, АБЗАЦ #1999

Нас в этом отрывке должны интересовать не пользовательский интерфейс и (не)удобство офисного применения (например, столь же древний Multi-Edit может делать все тоже самое, но другими методами). Мы видим три очень важных для дальнейших экспериментов решения:
1. набор основных типов информационных блоков/фреймов - текст, ЭТ, таблица БД;
2. дополнение этого набора "связующим" иерархическим фреймом;
3. использование единого для всех блоков языка программирования - Fred. В рамках этого языка любой фрейм/часть фрейма имеет значение, которое можно вычислить и подставить в другой фрейм (практически соответствует обычным формулам ЭТ).
***


MindJet - более современный "интегратор". Работает с обычными "офисными" документами.

Кстати, я честно пытался применить этот самый Mindjet для чего-то интересного:
- DIRTSIDE II & STARGRUNT II. Т.к. в то время работа над переводом правил этих игр была вынужденно приостановлена на самом переломном месте – переосмыслении представления на моей страничке, то карта создавалась с целью сохранить как можно больше информации до момента восстановления работ. Формат входных данных – текстовая база данных моего формата (ГЛЮКВА, см. далее). Ветви естественно расползлись влево и вправо. Слева накопилось 4 очевидных уровня: "Первоисточники" – <Книга> – <Глава> – <Параграф>, и пара более коротких ветвей "Мои комментарии" и "Огрызки из других источников". Справа – ветвление определялось моим новым видением правил изложения правил (до 5 уровней вложения). Процесс дальнейшего переформатирования т.о. состоял в переносе кусков текста слева-направо. Никаких специальных узлов с концепциями/памятками не появилось (не до того было).
- VOID. Входные данные – аналогичные: мои переводы (описания вселенной игр этой серии) в той же ГЛЮКВЕ. Но построение карты осуществлялось с совершенно с другой целью. Файл ГЛЮКВЫ вырос до таких размеров, что я сам потерял за этими деревьями лес. Захотелось наглядности, а писать для этого очередной неудачный визуализатор ГЛЮКВЫ не хотелось. Работа успехом не увенчалась. Т.к. ГЛЮКВА обладает гораздо большими возможностями перекрестных ссылок, при прямом переносе голого текста в карту очень большая часть информации была потеряна. Обозримости достигнуть не удалось – карта влезает в экран только в масштабе 28%.
- H1.RU. Карта создавалась с целью отследить необходимые мероприятия по обновлению моей странички. Наученный горьким опытом VOID, сразу отказался от копирования в структуре карты структуры странички. Разбил все мероприятия по темам: проекты с громкими названиями, замеченные опечатки, пока бесхозные куски и т.д. Карта пока (здесь и далее "сейчас" - лет десять назад.- G.) обозрима. Активно используются "циферблаты" - это такие иконки, показывающие как я оцениваю готовность фрагментов. Однако, проявились и ограничения модели: привязка некоторых узлов спорна, также пришлось использовать "поперечные" связи.
- ВСЕЛЕННАЯ. Входные данные – совершенно разнородные фрагменты с описаниями моей "тренировочной" вселенной. Основной источник данных – текст, разбитый на нумерованные абзацы. Получилось интересно. В карте совмещены как данные разных типов (тексты, картинка, таблицы), так и узлы различных типов: информационные фрагменты, наметки будущих концепций, замечания о дальнейших направлениях работы. К сожалению, как только карта стала интересной, она перестала влезать в экран.
- ФРАГМЕНТ. Карта создавалась как подспорье в разработке некоторой системы интерактивной обработки, единица которой и была названа "фрагментом". Гордо воткнув "Фрагмент" в центр карты я честно потянул от него связи к сущностям, которые должны были участвовать в обработке. Очередной раз убедился, что ветвям карты заказано соответствовать каким-либо связям реального мира. Во-первых, оказался совершенно никак не отраженным в карте тот факт, что многие сущности, связанные с фрагментом, сами являются фрагментами (рекурсия). Во-вторых, если узлы еще можно кое-как откомментировать (иконками или навешиванием узлов специального вида), то связи между узлами откомментировать практически невозможно. В-третьих, Для ветвей "Теория [, философия, аксиоматика]", "Операции [и предикаты над фрагментами]" и "Вопросы [, подлежащие решению]" места не нашлось совершенно и их пришлось раскидать экрану, не привязывая к "корню".
- ПРОЕКТЫ. Только начал, в попытке как-то упорядочить текущие проблемы. Пока развесил по веткам только содержимое пары файлов, аналогичных файлу ВСЕЛЕННОЙ, содержащих старые заметки. В перспективе, надо связать эту карту со всеми остальными.
Т.е. весь опыт свелся к тому, что проще было переформатировать (или написать для этого программку) данные самому, чем таскать их в MindMap и обратно. Тем более, что я так и не понял, может ли MindMap как-то помочь автоматизировать обработку.

Кстати, Жюль Верн вел картотеку научных и технологических новостей из десятков тысяч карточек:

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

ЗАДАЧА 1 ("ПРАВИЛА"). ЭТАП 0 ("РУЧНЫЕ ОПЕРАЦИИ")

Сами по себе все эти замечательные текстовые "кирпичики" никакой задачи не решат.

Надо решить:
1. Как этими данными описать то, что нам надо?
2. Какие программы нужны для манипулирования ими?
3. Как запустить эти программы на нашей машине?



По сути, это те cамые три части задачи, которые постоянно решает программист ТЕМА #15, АБЗАЦ #388. И аксиома #3 говорит нам, что решаются эти три части почти независимо друг от друга.

Лучше, конечно, начать с первой, т.к. она, все-таки, главная.
***

Какие форматы данных нам понадобятся для записи "ПРАВИЛ" и организации к ним "РУЧНОГО ДОСТУПА"?

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

В идеале, конечно текст хорошо бы упаковать в БД. (Подходит агент Малдер к компьютеру и вбивает: "Найди что-нибудь интересное". А тот ему в ответ: "Заметка из газеты за 1934-й год... Заметка за 1962-й... Вампир на фотографии - тот же самый... Четвертый справа в кепке...") Однако, такое возможно только когда мы уже пересчитали все возможные варианты текстов, выделили и классифицировали все их признаки и параметры... Этот подход действительно встречается - в "простых книгах-играх" ТЕМА #20, для которых написаны многочисленные редакторы/проигрыватели, держащие автора в достаточно жестких шорах, не позволяя писать того, что не предусмотрено.

Как же записывать то, что еще не готово? Только допуская запись в "свободном формате" и разрешая гибкую систему адресации.
***

Посмотрим на "блок-схему" игры, приведенную в первой главе записок. По идее, ЗАДАЧА 1, это преобразование "Идеи" в "Правила", пока без какой-либо спецификации "отдельных Машин".
В чем состоит наша "игра"?
Например, в X-Com игрок совершает некоторые игровые действия, по результатам которых ему постепенно открывается "полная энциклопедия инопланетян" - параграф за параграфом.
Для того, чтобы у нас получилось что-то подобное, нам надо...

I. Сформировать процедуру выбора "неготовых фрагментов". Этакая "Формализация Идеи". Как последовательно вырезать из огромного куска текста маленькие "карточки"? Одного разбиения на части, главы и прочие параграфы, как показывает мой опыт перевода, явно недостаточно. Мне не хватает знаний иностранного языка, чтобы делать все честно от начала до конца и с постоянной скоростью. Постоянно возвращаюсь к пройденным кускам, чтобы подправить перевод терминов или даже целых кусков, понятых задним числом. После долгих перерывов в работе очень часто хочется переделать "все".
- Проще всего брать фрагменты подряд (но это совсем не интересно);
- Выбирать фрагменты путем ручного перебора дерева, но боюсь, что без какого-либо художественного "переосмыслятора" это будет занудно;

Для этого надо в т.ч. придумать какие-либо очевидые начальные пути. Например, у меня было такое разделение материалов (именно для STARGRUNT II):
1) Антуражные иллюстрации - очень "маловысокохудожественные". Кто-то из "художников" самовыражался, кто-то "для прикола" ретушировал реальные фотографии, кто-то явно творил, сидя на скучном заседании или лекции. Пропускаем. Интереснее создавать свой антураж.
2) Пояснительные иллюстрации - отрисованы получше, да и смысла в них побольше будет, надо их вырезать и вставлять в перевод.
3) Антуражные тексты - моих знаний английского языка явно недостаточно не только для литературного перевода, но даже для оценки качества и полезности этих художественных вставок. Пропускаем.
4) Сопроводительные тексты, в которых авторы пытаются обосновать оригинальность игры, рассказать о ее истории, посоветовать, какими модельками в нее играть... передают приветы родственникам, в конце концов. Пропускаем без вопросов.
5) Собственно правила. Надо переводить. С поправкой на то, что английский язык (в отличие от русского/немецкого) совершенно не приспособлен для передачи технических знаний, и после выливания обязательной воды размер текста уменьшается на порядок.
6) Типовые сценарии игры. Переводить, но - потом, если руки дойдут.
7) Конструирование подразделений и техники - самые для меня интересные разделы правил. Конечно, переводить.
8 ) Таблицы, краткие памятки-шпаргалки, примеры. Очень удобная для переводчика вещь. Почти билингва. По ним можно проверить правильность перевода правил. Сюда же можно отнести пояснительные иллюстрации и подписи под ними.
9) Описания типовой вселенной. Ничего интересного, за исключением некоторых примеров, относящихся к предыдущему разделу.

-  Искать фрагменты по упоминающимся терминам;
- Каким-либо образом сохранять информацию о предыдущих выборах пользователя и пытаться действовать "разумно";
- - Это нужно, чтобы программа могла "отвечать нам по-умному" или "выдавать нам что-то интересное". На язык кибернетики это можно перевести, соответственно, как "выдать то, что игрок ожидает" и "выдать игроку нечто неожиданное". Первое ограничивается способностью программы к построению модели игрока, второе - размером базы данных и непредсказуемостью генератора случайных чисел. Третья необходимая способность - (авторская) фильтрация, не допускающая выдачи белиберды. Две первых способности, в основном, реализуются "Оценками", а третья - "Логикой".
- - А где хранить "память"? Очевидно - в структуре БД.

II. Придумать подходящее "оглавление" для готовых фрагментов. Например, у меня получилось следующее (я даже попытался таким образом перетасовать пару своих переводов):

Что в первую очередь интересует игроков? Общие слова о том, что модель покрывает наземно-воздушные тактические боестолкновения 2000-2500гг.? Это только слова. Игроков интересует, какими фишками играть, как ходить и как побеждать? Первое, что приходит в голову: какова общая последовательность игры (настольная пошаговая, она, в конце концов, или компьютерная реального времени)? Так и запишем:

1) ПОСЛЕДОВАТЕЛЬНОСТИ - подготовки к игре, хода игры, фаз одного хода... Т.е. алгоритмы, которые можно жестко привязать к общему алгоритму игры. Последовательности указывают нам, какие действия следует предпринять в каждый конкретный момент времени, но не конкретизируют точный вид этих самых действий, ограничиваясь общими терминами. Конкретные действия зависят от конкретной обстановки на игровом поле и конкретных сил игрока, вовлеченных в это действие. Самая главная последовательность - алгоритм проведения партии. От подготовки к игре - до присуждения победы одному из игроков. Понятно, эта последовательность может быть разделена на совершенно разнородные фрагменты - последовательности подготовки поля боя и армий; разбиения игры на раунды, а раундов - на ходы; методы подсчета трофеев... "Глубина" вложения одних последовательностей в другие может быть совершенно различной в разных частях игры. Где-то формализмы практически полностью определяют действия игроков одно за другим, а где - все делается "по договоренности". Например, шахматы. Основная последовательность - расставить фигуры и играть. Собственно игра распадается на последовательность поочередных ходов, а те - на фазы, так же жестко определенные правилами: "взялся - ходи", "напал на короля - скажи: "Шах""... Последовательность же расстановки фигур жестко не определяется, например, игроки обычно сами решают, кому играть белыми. В Го в основную последовательность добавляется фаза подсчета очков по завершении партии. Возможны и "надпоследовательности", например, в шахматных турнирах, где в них описываются правила чередования партий, подсчет очков, шахматного этикета. Описывать последовательности естественно так же, как алгоритмы вычислений - блок-схемами или в виде пронумерованных абзацев.
***

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

2) ЗАВИСИМОСТИ, конкретизирующие алгоритмы действий игрока, при обращении им с разными частями комплекта игры и/или нахождения в конкретном состоянии последовательности. Описание зависимости должно включать указание на конкретное ее место в игровой последовательности, условия ее применения и требования к фишкам (или другим частям игрового комплекта), в ней задействованных. Шахматный пример: "ход лошадью" - во время фазы перемещения, при отсутствии шаха, конем - далее описание буквы "Г". Конечно, нельзя не отметить, что в большинстве игр подобные описания называются просто "правилами".
***

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

3) ИСКЛЮЧЕНИЯ, т.е. описания случаев, когда следование конкретным алгоритмам приводит к нарушению последовательностей действий. Здесь мы сталкиваемся с разновидностью последовательностей, которые привязываются не столько к какому-либо состоянию более общей последовательности, но к какому либо условию.
***

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

4) УСЛОВИЯ, определяющие изменения состояния сил игрока или состояния игры, которые невозможно привязать к конкретной последовательности. Формат описания подобных правил по необходимости сильно отличается от перечисленных выше. В условиях описывается лишь результат действия, но не его алгоритм. Например: "королева любит свой цвет".
***

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

5) ПАРАМЕТРЫ - переменные, используемые в алгоритмах игры. Важнейшая характеристика параметра - список алгоритмов, его использующих. Т.о. их описание должно обязательно включать ссылки на правила их использующие. Обычно, авторы этим пренебрегают. Это вполне объяснимо -  сразу становится наглядной ненужность многих параметров. Гораздо "наукообразней" подробно расписывать, в какую графу "паспорта" фишки нужное число крестиков поставить.
***

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

6) ФОРМУЛЫ, жестко привязанные к параметрам и описывающие конкретные алгоритмы их связей и применения, использующиеся в разных контекстах/ситуациях игры.
***

К сожалению, прямолинейное следование изложенной системе до добра не доведет: во-первых, последовательности очень быстро заканчиваются, уступая место жуткому змеиному клубку условных условий, во-вторых, должен же где-то учитываться тот факт, что мы имеем дело не с обобщенной моделью непонятно чего, а с конкретной военной и, более того, сугубо тактической. Т.е. как ни крути, где-то должны быть правила перемещения, стрельбы, рукопашного боя и т.д. Возникает вопрос об однородности модели. На одном конце шкалы расположены модели однородные (как шахматы), где атака одной фишки другой происходит независимо от типов фишек (в шахматах - просто взятие, с двумя исключениями - атака короля и взятие на проходе). На другом конце - модели полностью неоднородные, где число видов схваток двух фишек разного типа примерно равно квадрату количества типов. (Тут надо заметить, что данная шкала, скорее всего, замкнута в кольцо, ведь, если каждые две фишки сражаются по своим правилам, то подобная исключительность становится правилом, только другого уровня). Очень часто встречаются квазиоднородные модели - в них бой проходит одинаково для всех фишек, но расчет боевой силы фишек отличается от фишки к фишке (как в игре BTH). Еще более интересны комплексные модели, где даже одиночный бой проходит не между отдельными фишками, но между некими их конгломератами, в которых каждому типу фишек отведено отдельное место. (Как в модели раздела Практики, где сила пехоты, танков и артиллерии учитывается в разных местах формулы.) Впрочем, все приведенные примеры достаточно сильно "притянуты за уши", т.к. чистые решения в играх встречаются крайне редко. Гораздо чаще в военных играх используется "объектно-ориентированный" подход: все важные правила оперируют некими "классами", а для каждой фишки подробно указывается, каким классам она принадлежит. В простейшем случае, почти все правила используют единую систему классов (например: пехота, пушка, танк, самолет...). В сложном, свои классы в правилах стрельбы (винтовки, пулеметы, пушки,), свои в правилах перемещения (пехота, колесные, гусеничные...), свои в правилах защиты (небронированные, бронированные...) и т.д. Часто, даже в простом случае, наблюдается уж воистину "объектно-ориентированная" иерархия классов. Что-то вроде: "Казаки относятся к кавалерии, а кавалерия движется как танки и воюет как пехота". Итак, добавляем:

7) НЕОДНОРОДНОСТИ в составе армий противников - особые рода войск, спецподразделения и т.д. И, соответственно, различные виды боя.

III. Каким-либо образом художественно оформить перевод из формы I в форму II. Собственно, "Построение Правил": как размещать переведенные куски таким образом, чтобы самому было интересно? Более того, чтобы создавалось впечатление, что машина что-то делает сама, радуя нас неожиданным результатом?
***

Хочется надеяться, что все эти "проблемы" не выходят за пределы манипулирования структурой БД. Надо только собрать коллекцию нужных команд, и научиться собирать их в наборы "по смыслу".
***

К чему все эти попытки найти какие-то общие черты в самых разнообразных текстовых/гипертекстовых описаниях непонятно-чего? Ведь, есть же визуальное программирование! Если у вас установлен какой-нибудь Visual Basic (или его младший брат Delphi, Power C++, Visual C# и т.п.), вы без труда сможете создать по отдельному Windows-окошку для доступа к любой порции данных/текста. Некоторые умельцы умудряются создавать текстовые игры на основе баз данных или электронных таблиц. Чем плохо?

Скажу:
1. Визуальное программирование "на чем-то серьезном", как писал выше, достаточно затратное дело. Откладывать солдатиков и изучать новые технологии?
2. "Рисование окошек" по правилам "современных технологий" относится не к игре, а к программированию игры. Не только в смысле "серьезности дела", но и в смысле невозможности создания/доделывания игры в процессе самой игры.

А я - за неуглубление внутрь машины более необходимого и за возможность играть в создание игры.
***

ИТАК:
Есть некие ФАКТЫ, данные мне в ощущении. И есть мои МЫСЛИ по поводу них. Игра - упорядочение этих МЫСЛЕЙ в какой-то форме. МЫСЛЬ может быть выражена в виде некоторой структуризации ФАКТОВ. Может - в использовании ФАКТОВ в виде констант некоторых программ. Может - в выборе представления ФАКТОВ игроку. В отличие от ФАКТОВ, МЫСЛИ не имеют какой-либо окончательной формы и могут сменять друг друга по мере игры.
В такой трактовке, все что нам надо от программирования, это иметь возможность записи МЫСЛЕЙ. Наших МЫСЛЕЙ, достаточно простых, и, возможно, примитивных. Важна не изощренная способность записи изощренных МЫСЛЕЙ (называемых алгоритмами, парадигмами, технологиями и движками), а простая возможность простой записи. Сел за компьютер, записал/прочел, что надо, и забыл до следующего раза..

Если механизм обмена МЫСЛЯМИ с компьютером будет достаточно прост, чтобы быть работоспособным, и достаточно сложным, чтобы удовлетворить нашу потребность в структуризации данных, то мы получим тот самый баланс ожидаемого и неожиданного, который желателен от машинного интеллекта (см. главу "Про кота").

После экспериментов с введением в БД дополнительных таблиц-справочников и попыток свести все к XML, я остановился на чисто текстовом формате:
1. Описываются только "листья" нашего "дерева".
2. При описании каждого "листа" указываются все пути - "ветви" - которые к нему ведут от самого "корня".
Это напоминает дисковую систему Unix, где один файл может быть привязан к нескольким директориям одновременно.

Исторически примером этого метода служит эта "база компонентов" (табуляцию заменил на #):

Спойлер:

За время использования этого формата, я перепробовал разные способы применения:
- Когда лепил дополнительные библиотеки к PCAD, активно использовал разные флаги и пометки, т.к. база редактировалась в этой версии очень активно: выделенные элементы, копирование блоков, сравнение множеств.
- Когда хранил блоки информации для одного забавного прибора шифрования, ничего интересного не встретилось, за исключением  многочисленных операций клонирования.
- Применяя для анализа модулей/подпрограмм BIOS, отказался от наследования параметров, т.к. использовал их для определения типов переходов между узлами.
- При описании вселенной игры VOID получилось не дерево, но лес - библиотека имела несколько входов: содержание, упорядочение по первоисточникам, словарь...

Какие полезные свойства я обнаружил у этого способа за годы его использования?
1. Для любой порции информации без труда находится место.
2. Поиск по базе производится очень удобно.
3. Избыточность минимальна.
4. Перенос, копирование, клонирование и прочие операции над "узлами дерева" сводятся к операции замены подстрок в путях.
5. Можно управлять показом содержимого листа в зависимости от пути, по которому к нему пришли.

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

Какие выявились недостатки?
Требуется придумывать дополнительные дисциплины управления путями в каждом новом проекте. Иначе ввод новых путей может вызвать неожиданные последствия.

Впрочем, игровое применение данного способа, как раз, и требует изобретение такой дисциплины как части правил игры.
***

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

Приняв текст как способ хранения данных, мы имеем выбор, которого у нас не было, если бы мы использовали специализированные/бинарные/архивированные данные. Если данные нельзя "просто прочитать" из файла, то любая операция их редактирования должна состоять из трех частей: считываем текст/файл в структуры данных, преобразуем, загоняем структуры обратно в текст/файл. Назовем такие операции ОБЩИМИ.

Пример решения, состоящего из оконного скрипта на Tcl/Tk с вызовом Perl-скриптов (одного большого, обеспечивающего выполнение ОБЩИХ операций, и кучи маленьких - на одну операцию):



Если же мы оперируем текстом, нам доступны еще два вида операций: ПОСЛЕДОВАТЕЛЬНЫЕ (прогоняем текст/файл через какой-либо фильтр, как это всегда делалось в Unix) и ЧАСТНЫЕ (вырезаем из текста/файла нужный фрагмент, правим его в обычном
текстовом редакторе, записываем обратно).

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

Надо сразу понять связь между этими тремя видами операций:
1. Считывание файла в память для проведения ОБЩЕЙ операции само по себе практически является ПОСЛЕДОВАТЕЛЬНОЙ операцией.
2. Вырезание из файла куска для ЧАСТНОЙ операции может являться ПОСЛЕДОВАТЕЛЬНОЙ операцией.
***

Т.о. программирование ПОСЛЕДОВАТЕЛЬНЫХ операций должно предшествовать программированию ОБЩИХ и ЧАСТНЫХ просто потому, что первые обеспечивают последним среду обитания.

Для моих "деревьев" существует простейшая "пустая" ПОСЛЕДОВАТЕЛЬНАЯ операция - перебрать весь список листов, отслеживая тип читаемой информации. Т.е. т.к. описания "листов" в файле состоят из описаний путей, типов, заголовков и содержимого, операция должна в каждый момент понимать, что из этого она в данный момент читает.

Написав программу этой операции мы без труда получим нужные нам ПОСЛЕДОВАТЕЛЬНЫЕ операции просто подставляя нужный код в ее "пустые" места.

По сути это почти "Машина Тьюринга", программа которой, как известно, представляет из себя таблицу

Символ * Состояние = (Нов.Символ, Нов.Состояние, Сдвиг.Курсора).

Наша машина проще, за единственным исключением: "Символы"-строки определяются регулярными выражениями.
Зато, "Нов.Символ" не используется. А "Сдвиг.Курсора" означает, лишь, ввести новую строку или оставить текущей старую.

Всего используется семь "Символов":
- пустая строка;
- строка, начинающаяся с "обратной косой" ("путь");
- строка с единственным словом ТЕКСТ;
- ... ТАБЛИЦА;
- ... ЗАПИСИ;
- строка начинающаяся с пары "латинская буква" и "пробел" ("параметр");
- любая другая строка.

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

И пять "Состояний":
- Garbage (мусор) - информация вне "листов";
- Path (путь) - путь к листу;
- Head (заголовок) - текст заголовка для "листов" типов ТАБЛИЦА и ЗАПИСИ;
- Text (текст) - текст "листа";
- Param (параметр) - параметры "листа".

Состояние	Символ	Нов.Состояние, строка	Сокращение
Garbage	Обратная косая	Path, сохраняется	G\P
Garbage	Пустая	Garbage, новая	G0GI
Garbage	Все остальные	Garbage, новая	GXGI
Path	Обратная косая	Path, новая	P\PI
Path	ТАБЛИЦА	Head, новая	P#PI
Path	ЗАПИСИ	Head, новая	PRPI
Path	ТЕКСТ	Text, новая	PTTI
Path	Литера и пробел	Param, сохраняется	PLL
Path	Пустая	Param, новая	P0LI
Path	Все остальные	Garbage, сохраняется	PXG
Head	Пустая	Text, новая	H0TI
Head	Все остальные	Head, новая	HXHI
Text	Пустая	Param, новая	T0LI
Text	Все остальные	Text, новая	TXTI
Param	Обратная косая	Path, сохраняется	L\P
Param	Литера и пробел	Param, новая	LLLI
Param	Пустая	Garbage, новая	L0GI
Param	Все остальные	Garbage, сохраняется	LXG

Можно заметить, что новую строку требуется ввести, если текущая заведомо обработается этим Состоянием (Нов.Состояние равно старому), или текущая строка не несет никакой дополнительной информации, кроме "переключательной" (пустая, тип "листа"). Сохраняется непустая строка, если осуществляется переход из "чужого" для нее Состояния, в Нов.Состояние, способное ее обработать.

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

Что выбрать?
1. Ранее я чаше всего применял только один способ реализации этой машины - на Perl, визуализируя полученный результат на Html своей странички (реже на Tcl/Tk - см.выше).
По тем временам это был почти идеальный способ программирования "на голом Windows". Заведи себе бесплатный хостинг и программируй свои CGI-программы на Perl или даже C, не имея на своей машине ничего, кроме текстового редактора и средств доступа к Сети. К сожалению, эта холява кончилась - ТЕМА #7.


Это результат ОБЩЕЙ операции преобразования comp.txt в HTML путем построения в памяти полного "дерева".
(Обратите внимание на то, что кусачки 1PK-727 висят сразу на двух "ветках"):

Что можно сказать о "красоте" этой реализации? Она короткая и, по сравнению с другими, имеет минимальную избыточность и минимум ограничений на формат строк и размер файла. (Хотя, конечно, даже минимальная Perl-избыточность раздражает сильнее любой другой, т.к. язык-то позиционируется, как наиболее лексически совершенный).

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

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

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

Спойлер:

3. Наиболее же наглядной реализацией остается старый добрый GW-BASIC.
- BASIC был основным языком первой части заметок.
- Как ни крути, различные BASIC-и являются основными языками программирования на IBM PC. Их достаточно легко найти: скачать GWBASIC.EXE (и, если захочется графики - dosbox, который обычно используют для запуска DOS-овских игр); или скачать любой из MS Visual Basic-ов (например, Visual Basic 3.0); или воспользоваться VBA из MS Office; или просто воспользоваться имеющимся в наличии WHS...
- Из всех BASIC-ов, GW-BASIC самый простой. Если уж на нем удастся написать все, что нам надо, то переписать на чем угодно не будет проблемой. В нем нет такого обилия мусора, как в более поздних версиях, и программы могут остаться читаемыми.

1000 REM GARBAGE
1010 IF LEN(R$)=0 THEN 2100
1020 IF LEFT$(R$,1)="\" THEN 2000
1030 GOTO 2200
1100 REM PATH
1110 IF LEN(R$)=0 THEN 2300
1120 IF MID$(R$,2,1)=" " THEN 2400
1130 IF LEFT$(R$,1)="\" THEN 2500
1140 IF LEFT$(R$,5)="ТЕКСТ" THEN 2600
1150 IF LEFT$(R$,7)="ТАБЛИЦА" THEN 2700
1160 IF LEFT$(R$,6)="ЗАПИСИ" THEN 2800
1170 GOTO 2900
1200 REM HEAD
1210 IF LEN(R$)=0 THEN 3000
1220 GOTO 3100
1300 REM TEXT
1310 IF LEN(R$)=0 THEN 3200
1320 GOTO 3300
1400 REM PARAM
1410 IF LEN(R$)=0 THEN 3600
1420 IF LEFT$(R$,1)="\" THEN 3500
1430 IF MID$(R$,2,1)=" " THEN 3400
1440 GOTO 3700

2000 REM GARBAGE - ОБРАТНАЯ КОСАЯ - PATH
2090 GOTO 2500
2100 REM GARBAGE - ПУСТО - GARBAGE
2190 LINE INPUT#1, R$: GOTO 1000
2200 REM GARBAGE - ПРОЧЕЕ - GARBAGE
2290 LINE INPUT#1, R$: GOTO 1000
2300 REM PATH - ПУСТО - PARAM
2390 LINE INPUT#1, R$: GOTO 1400
2400 REM PATH - БУКВА+ПРОБЕЛ - PARAM
2490 GOTO 3400
2500 REM PATH - ОБР.КОСАЯ - PATH
2590 LINE INPUT#1, R$: GOTO 1100
2600 REM PATH - "ТЕКСТ" - TEXT
2690 LINE INPUT#1, R$: GOTO 1300
2700 REM PATH - "ТАБЛИЦА" - HEAD
2790 LINE INPUT#1, R$: GOTO 1200
2800 REM PATH - "ЗАПИСИ" - HEAD
2890 LINE INPUT#1, R$: GOTO 1200
2900 REM PATH - ПРОЧЕЕ - GARBAGE
2990 GOTO 2200
3000 REM HEAD - ПУСТО - TEXT
3090 LINE INPUT#1, R$: GOTO 1300
3100 REM HEAD - ПРОЧЕЕ - HEAD
3190 LINE INPUT#1, R$: GOTO 1200
3200 REM TEXT - ПУСТО - PARAM
3290 LINE INPUT#1, R$: GOTO 1400
3300 REM TEXT - ПРОЧЕЕ - TEXT
3390 LINE INPUT#1, R$: GOTO 1300
3400 REM PARAM - БУКВА+ПРОБЕЛ - PARAM
3490 LINE INPUT#1, R$: GOTO 1400
3500 REM PARAM - ОБР.КОСАЯ - PATH
3590 GOTO 2500
3600 REM PARAM - ПУСТО - GARBAGE
3690 LINE INPUT#1, R$: GOTO 1000
3700 REM PARAM - ПРОЧЕЕ - GARBAGE
3790 GOTO 2200

Данная реализация имеет ограничение на длину строк и, при использовании в ОБЩЕЙ операции, на размер файла, но, зато, самая понятная из всех, невзирая на все эти GOTO.

ОБЩАЯ операция  построения полного "дерева" в памяти выглядит тогда так:

100 OPTION BASE 1:DIM P$(1024),L(1024): P=1024
110 DEF FNH(I)=(H*17+ASC(MID$(R$,I,1)))AND 1023
200 DIM T(1024),C(1024),B(1024): Z=1

2510 GOSUB 6000

4000 REM ВСТАВКА ПОДСТРОКИ MID$(R$,N..K) В ХЭШ-ТАБЛИЦУ
4010 H=0
4020 FOR I=N TO K
4030 H=FNH(I)
4040 NEXT I
4050 H=H+1:Y=H
4060 IF MID$(R$,N,K-N+1)=P$(H) THEN RETURN
4070 H=L(H): IF H GOTO 4060
4080 IF P$(P)<>"" THEN P=P-1: GOTO 4080
4090 P$(P)=MID$(R$,N,K-N+1)
4100 L(P)=L(Y): L(Y)=P: H=P: RETURN

5000 REM ДОБАВЛЕНИЕ H К УЗЛУ T
5010 GOSUB 4000: C=C(T): B=0
5020 IF C GOTO 5060
5030 Z=Z+1: X=Z: T(X)=H
5040 IF B THEN B(X)=B(B): B(B)=X: T=X: RETURN
5050 B(X)=C(T): C(T)=X: T=X: RETURN
5060 IF T(C)=H THEN T=C: RETURN
5070 IF P$(T(C))<P$(H) THEN B=C: C=B(C): GOTO 5020
5080 GOTO 5030

6000 REM РЕГИСТРАЦИЯ ПУТИ
6010 T=1: N=2
6020 K=INSTR(N,R$,"\")
6030 IF K=0 THEN K=LEN(R$) ELSE K=K-1
6040 GOSUB 5000: N=K+2
6050 IF K<LEN(R$) GOTO 6020
6060 RETURN

Т.е. "дерево" строится в момент получения очередной "ветви" ("обратная косая" в состоянии Path). Дополнительные процедуры хранения строк (4000) и ветвей (5000) в ассоциативных массивах (и, особенно, большое количество связанных с этим служебных массивов - P$(), L(), T(), C(), B()) - на совести несовершенства GW-BASIC-а (и нашего желания писать на нем "правильно"). Очевидно, что более одной-двух таких "операций" BASIC-программа "не потянет" - станет слишком сложной для нашей игры.

Начало-конец программы:

500 OPEN "I",#1,"COMP.TXT"
510 ON ERROR GOTO 7000
520 LINE INPUT#1, R$

7000 CLOSE#1: END

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

4. Т.к. мне придется встраивать эту машину в НTML, уже без возможности нормального хостинга, то потребуется реализация на самом дебильном из всех известных мне языков программирования - на Java Script. Не хочу об этом говорить.

ОСНОВНАЯ ПОСЛЕДОВАТЕЛЬНАЯ ОПЕРАЦИЯ - ВЫРЕЗАТЕЛЬ

Просто так, приведенная пустая ПОСЛЕДОВАТЕЛЬНАЯ операция никому не интересна. Каким полезным смыслом ее можно наполнить?

Присмотревшись к проблемной части своей задачи, я обратил внимание на возможность наличия универсальной ПОСЛЕДОВАТЕЛЬНОЙ операции. Этот "кирпичик" - операция вырезания из файла куска информации. На входе - полный файл, а на выходе - остаток файла и вырезанный кусок. Это кажется естественным, ведь разбиение информации по отдельным файлам в этой задаче встречалось постоянно (объединение заметок, сделанных на разных машинах, ускорение загрузки в сеть, попытки реорганизации материала). Возражения против постоянного перелопачивания файла при вырезании/слиянии не существенны. При современных объемах/скоростях это все почти ничего не весит.

Наблюдается некоторая аналогия с SQL - там тоже операция SELECT выполняет львиную долю работы. Только ее результат не может быть слит с общим файлом. Приходится для изменения последнего использовать другие операции.

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

Вторая - вырезательная - машина, которая будет сортировать/вырезать строки (выдаваемые нашей первой - пустой - машиной, перебирающей символы-строки), тоже достаточно проста. Она должна уметь исполнять операции:
U - рассматривать текущую строку, как заведомо полезную;
S - рассматривать текущую строку, как заведомо бесполезную;
A - добавить текущую строку к потенциально полезным;
C - перевести потенциально полезные строки в заведомо полезные;
B - перевести потенциально полезные строки в заведомо бесполезные;
E - добавить пустую к заведомо полезным;
X - добавить пустую к  потенциально полезным;
T - добавить пустую к заведомо бесполезным.

(E и T вообще-то избыточны - можно, при отсутствии потенциально полезных, использовать XC и XB. Аналогично - U и S).

Сложность заключается не в командах, а в условиях их выполнения. Какая команда выполняется, зависит от...
... текущего Состояния и Символа (18 описанных выше ситуаций), в т.ч. обрабатывается ли текущая строка или передается для обработки далее,
... того, куда засунули предыдущую строку - команды U (C или E), A (X), S (B или T),
... того, закончен ли предыдущий блок пустой строкой - три флага: для E, A и T,
... того, подходит ли текущая строка (в ситуации A) под условие "вырезания" (*).

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

Ситуация	U	*	A	S	Новый флаг
G\P, G0GI	E	-	BT	-	A
GXGI, HXHI, TXTI	U	CU	A	-	По операции
P0LI, PLL	-	-	BT	-	По операции
P\PI, PTTI, P#HI, PRHI	-	-	A	-	По операции
PXG	-	-	BT	-	A
H0TI	E	-	X	-	По операции
T0LI	E	-	BT	-	По операции
LLLI	U	-	-	S	По операции
L0GI, L\P, LXG	E	-	-	T	A
Конец	E	-	BT	T	-

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

ОТРИСОВАТЬ(фигулька, условие, флаг)

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

5000 REM ОБРАБОТКА КОМАНД
5010 IF F<>384 THEN 5040 'СТОЛБЕЦ УСЛОВИЯ U
5020 IF O AND 256 THEN GOSUB 4500: GOTO 5120 'E
5030 IF O AND 128 THEN GOSUB 4000: GOTO 5120 'U
5040 IF F<>120 THEN 5100 'СТОЛБЕЦ УСЛОВИЯ A
5050 IF O AND 64 THEN IF INSTR(R$,"однако") THEN GOSUB 4300: GOTO 5120 '*
5060 IF O AND 32 THEN GOSUB 4200: GOTO 5120 'A
5070 IF O AND 16 THEN GOSUB 4600: GOTO 5120 'X
5070 IF O AND 8 THEN GOSUB 4400: GOTO 5120 'BT
5100 IF F<>6 THEN 5120 'СТОЛБЕЦ УСЛОВИЯ S
5110 IF O AND 4 THEN GOSUB 4100: GOTO 5120 'S
5120 IF O AND 2 THEN GOSUB 4700 'T
5120 IF O AND 1 THEN F=120 ' УСТАНОВКА УСЛОВИЯ A
5130 RETURN

Т.е. в примере будем искать слово "однако".

Сами операции - ровно то, что мы хотим сделать со строками. Константы в комментариях - те, что использованы в коде обработки.

4000 REM ОПЕРАЦИЯ U. ГРУППА 384(U). ФЛАГ 128.
4010 PRINT#2,R$: EI=1: F=384: RETURN
4100 REM ОПЕРАЦИЯ S. ГРУППА 6(S). ФЛАГ 4.
4110 PRINT#3,R$: TI=0: F=6: RETURN
4200 REM ОПЕРАЦИЯ A. ГРУППА 120(A). ФЛАГ 32. ФЛАГ УСТАНОВКИ 1.
4210 A=A+1: A$(A)=R$: AI=1: F=120: RETURN
4300 REM ОПЕРАЦИЯ CU. УСЛОВИЕ 120(A). ФЛАГ 64.
4310 IF A=0 GOTO 4000
4320 FOR I=1 TO A: PRINT#2,A$(I): NEXT I
4330 A=0: EI=AI: AI=0: GOTO 4000
4400 REM ОПЕРАЦИЯ BT. ГРУППА 120(A). ФЛАГ 8.
4410 IF A=0 GOTO 4700
4420 FOR I=1 TO A: PRINT#3,A$(I): NEXT I
4430 A=0: TI=AI: AI=0: GOTO 4700
4500 REM ОПЕРАЦИЯ E. ГРУППА 384(U). ФЛАГ 256.
4510 IF EI THEN PRINT#2,"": EI=0
4520 F=384: RETURN
4600 REM ОПЕРАЦИЯ X. ГРУППА 120(A). ФЛАГ 256.
4610 IF AI THEN A=A+1: A$(A)="": AI=0
4620 F=120: RETURN
4700 REM ОПЕРАЦИЯ T. ГРУППА 6(S). ФЛАГ 2.
4710 IF TI THEN PRINT#3,"": TI=0
4720 F=6: RETURN

Остается только для каждой строчки таблицы вставить в код "пустой" машины нужную шкалу:

2010 O=265: GOSUB 5000: REM G\P
2110 O=265: GOSUB 5000: REM G0GI
2210 O=224: GOSUB 5000: REM GXGI
2310 O=8: GOSUB 5000: REM P0LI
2410 O=8: GOSUB 5000: REM PLL
2510 O=32: GOSUB 5000: REM P\PI
2610 O=32: GOSUB 5000: REM PTTI
2710 O=32: GOSUB 5000: REM P#HI
2810 O=32: GOSUB 5000: REM PRHI
2910 O=9: GOSUB 5000: REM PXG
3010 O=272: GOSUB 5000: REM H0TI
3110 O=224: GOSUB 5000: REM HXHI
3210 O=264: GOSUB 5000: REM T0LI
3310 O=224: GOSUB 5000: REM TXTI
3410 O=132: GOSUB 5000: REM LLLI
3510 O=259: GOSUB 5000: REM L\P
3610 O=259: GOSUB 5000: REM L0GI
3710 O=259: GOSUB 5000: REM LXG

и начало-конец

100 DIM A$(100)
110 TI=0: EI=0: AI=0
120 A=0: F=120

500 OPEN "I",#1,"COMP2.TXT"
510 OPEN "O",#2,"COMP3.TXT"
520 OPEN "O",#3,"COMP4.TXT"
530 ON ERROR GOTO 7000
540 LINE INPUT#1, R$

7000 O=266: GOSUB 5000: REM КОНЕЦ

7010 CLOSE#1,#2,#3: END

Конечно, можно упростить, перенести безусловную установку флага A в блок "вызовов", поджать разреженные шкалы... Но, здесь, нам важнее понять, что "табличное" решение гораздо проще "елочек" if-then-else и case... Пусть, даже и придется исписать пару салфеток в "Метрополе".
***

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

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

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

Наоборот, для выдачи полной информации о листе: всех его предках и потомках по всем путям, наследовании параметров по текущему пути, одной ПОСЛЕДОВАТЕЛЬНОЙ операции мало. Проще использовать ту же ОБЩУЮ операцию с построением полного дерева.
***

Как работает вырезатель, когда под рукой нет BASIC:


Из книги Акентьев В.С. Механизация инженерно-технического и управленческого труда.

ЕЩЕ ОДНА УТИЛИТА

Выше были рассмотрены простейшие "навигатор" и "вырезатель" из базы данных.
Осталось чисто формально добавить к ним "добавлятор".
Теперь полный цикл работы ОБЩИХ, ПОСЛЕДОВАТЕЛЬНЫХ и ЧАСТНЫХ операций будет замкнут.
***

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


На заднем плане - просмотрщик базы, слева - "эрзац-вырезатель" - Perl-скрипт вырезал кусок, который я засунул в текстовый редактор, справа - "добавлятор". Кроме того, текстовый редактор, сам играет роль ОБЩЕГО супер-управлятора (пока база мала, его хватает).
Пока это очень мало похоже на игру.
***

Сколько всего текстовых машин приходит в голову? (Список обновляется).
1. Рассмотренный выше разборщик базы. Конечный автомат, разбирающий наш текст на логически-обособленные фрагменты. В большинстве примеров этой и следующей главы я встраивал его внутрь других машин, например, вырезателя. Однако, можно и проще. Он может просто заменять каждую строку текста на строку, начинающуюся с команды (18 штук, от G\P до LXG, можно просто номер) и заканчивающуюся, если надо, текстом введенной строки. Т.е. взяли файл - вернули спец.файл.
2. Рассмотренный выше вырезатель. Выполняет команды разборщика, как понимает. Разбивает спец.файл на два обычных.
3. Машина переупаковки базы. Берет спец.файл и выполняет некие действия с базой. Например, для моего формата данных, удобной оказалась машина, удаляющая, перемещающая, копирующая и клонирующая узлы дерева (и почти все - просто макроподстановкой в заголовках листьев). Возвращает файл.
4. Машина работы с файлами (не вникая в их содержимое). Удобнее всего организовать стек файлов и реализовать обычный набор стековых операций (DUP, SWAP, ROT и т.д.). Если ваш формат данных, подобно моему, чисто последовательный, то можно сливать несколько файлов в один простым копированием.
5.  Отображающая машина - переводящая спец.файл в визуальную форму (например, html-файл).
6. Машина, умеющая интерпретировать команды пользователя в вызовы других машин. См. на картинке "добавлятор". Вопрос о способе прицепления к ней других машин (в т.ч. отображателя) оставляем открытым до второй главы.
...
7. Виртуализатор.  (Разновидность (5)). По опыту постоянного перетаскивания с настольника на наладонник и обратно. Удобно представлять большой файл, как набор маленьких (в стиле старого доброго QBASIC), производя сборку-разборку на лету.
8. Архиватор. Что удобнее хранить: версии или изменения (как в классическом скрипте К&П)? Как, вообще, делать это удобно? (У меня чаще организовано как просто набор напоминалок...)
...
9. Настройщик. (Разновидность (5)). Запрашивает у пользователя адрес хранилища файлов, стека и т.д.
10. Преобразователь (спец.файлов). Какое-либо промежуточное действие.
...
11. Разархиватор. (Обратная операция к (8 )). Нужен в случае, если используется отличный от текстового формат хранения.


***

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

Н.М.Никитюк / Программно-управляемые блоки в стандарте КАМАК / 1977

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

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

Еще немного рискованных аналогий...

Особенности стандарта КАМАК заключаются в следующем:
1) система КАМАК может работать как совместно с ЭВМ, так и без нее (при наличии специального генератора команд);
2) стандартизованные межблочные соединения позволяют осуществить передачу информации и управления при помощи системы внутренних команд;
3) применение интегральных микросхем;
4) учтены основные механические и электрические характеристики уже существующих стандартов ...;
5) универсальность, т.е. возможность использования и в других областях, где применяются ЭВМ.
Система КАМАК имеет стандартизацию трех типов: механическую, электрическую и логическую.

1) В смысле, наши модули должны работать без глубокого погружения в их программирование...
2) Нужно разработать некие "механические, электрические и логические" стандарты на совместимость - команд, параметров, файлов...
3) Хорошо бы не пойти поперек современных тенденций программирования...
4) Да и существующие средства ОС не хочется переписывать заново...
5) А, вот, на счет универсальности, как писал выше, сомневаюсь. Пока это еще никому не удавалось...

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

ПРИМЕР УНИВЕРСАЛЬНОЙ НАВИГАЦИИ В БАЗЕ ДАННЫХ

Оставшись без сервера, я остался и без естественного способа визуализации - HTML. Но, нет худа без добра. Появился повод подумать и о том, что и как выводить на экран.
***

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

Во-вторых, отказ от очевидности WYSIWYG требует изобретения некоторой системы выдачи ровно того, что нас в данный момент интересует, в наиболее удобной форме. И чем беднее наши визуальные возможности, тем более формализованной должна быть эта система. По крайней мере, мне нравится так думать и изобретать такие штуки.

ПРИМЕР
Для больших баз данных я давно придумал систему "точек зрения". Т.е. сеть запросов, между которыми возможны переходы согласно логики работы с данными. На SQL-баз оказалось достаточным добавить к любой базе данных всего две таблицы:

9. Общие сведения.
Система интерактивной навигации в базе данных ГЛЮК основана на использовании двух служебных таблиц - СОСТОЯНИЙ и СВЯЗЕЙ. В каждый момент времени пользователь имеет какую-то информацию о текущей точки зрения на базу, список сущностей, видимых из этой точки, возможность получить доступ к любой из этих сущностей и, наконец, возможность изменить точку зрения, обычно, опираясь на текущую сущность. Таблица СОСТОЯНИЙ содержит описания этих точек зрения а таблица СВЯЗЕЙ - переходы между ними. Здесь приведен пример реализации системы ГЛЮК в рамках ВАСЕЦ-Jet.

10. Таблица СОСТОЯНИЙ.
ЗАГ - заголовок точки зрения.
ТИП - наличие иерархии в списке сущностей (поля ИЕР в запросе ВЫБ).
ВЫБ - SELECT *,... AS ИД, ... AS ИМЯ [, ... AS ИЕР] FROM ... - начало запроса для получения списка объектов (ИД - первичный ключ;
ИМЯ - терминал - имя сущности; ИЕР - внутренняя ссылка).
ГДЕ - WHERE ... - внутренние условия.
ПРД - ORDER BY имя поля ИМЯ или ИЕР - упорядочение списка сущностей.
ОБЪ - запрос для получения доступа к выбранной сущности.

11. Таблица СВЯЗЕЙ.
СТАР - точка зрения - родитель (номер в СОСТОЯНИЯХ).
НОВ - точка зрения - потомок (номер в СОСТОЯНИЯХ).
ЗАГ - новый заголовок потомка.
ТИП - сохранит ли потомок иерархию.
ИЗ - довесок к ВЫБ - имена промежуточных таблиц.
ДОБ - довесок к ГДЕ - условия порождения.
ПВБ - запрос вспомогательной выборки.

12. Пример кортежа из таблицы СВЯЗЕЙ.
Идя от сотрудника подразделения, получить список сотрудников всех подчиненных подразделений:
ЗАГ = "СОТРУДНИКИ ПОДЧИНЕННЫХ ПОДРАЗДЕЛЕНИЙ";
СТАР = СОТРУДНИКИ;
ТИП = безразлично, т.к.  СОТРУДНИКИ.ТИП=НЕТ;
НОВ = СОТРУДНИКИ;
ИЗ = "ПОДРАЗДЕЛЕНИЯ,СТАВКИ";
ДОБ = "СТАВКИ.СОТРУДНИК=СОТРУДНИКИ.СОТРУДНИК AND СТАВКИ.ПОДРАЗДЕЛЕНИЯ=ПОДРАЗДЕЛЕНИЯ.ПОДРАЗДЕЛЕНИЕ AND ПОДРАЗДЕЛЕНИЯ.ИЕРАРХИЯ LIKE '<ВРМ>*'";
ПВБ = "SELECT ПОДРАЗДЕЛЕНИЯ.ИЕРАРХИЯ AS ВРМ FROM ПОДРАЗДЕЛЕНИЯ, СТАВКИ WHERE ПОДРАЗДЕЛЕНИЯ.ПОДРАЗДЕЛЕНИЕ=СТАВКИ.ПОДРАЗДЕЛЕНИЕ AND СТАВКИ.СОТРУДНИК=<СОТРУДНИК>".

Результаты запросов легко втюхивались в универсальную форму-просмотрщик:

16. ВЗГЛЯД - окно просмотра БД, базирующееся на ГЛЮКЕ.
Взгляд на БД с какой-либо позиции, может быть, ограниченный ранее сделанным выбором, выглядит как список сущностей. ТЕМЫ - список связанных СОСТОЯНИЙ; выбор темы из списка помещает ссылку на текущую точку зрения в стек ПУТЬ и выполняет процедуру ВВЕРХ. ПУТЬ - пройденные точки зрения -  экранное отображение КОЛЛЕКЦИИ без последней строки; выбор из списка приводит к возврату к одной из старых точек зрения и удалению хвоста списка (и, соответственно КОЛЛЕКЦИИ, из которой и берутся данные, необходимые для возврата). ОБЪЕКТЫ - экранное отображение СПИСКА сущностей; выбор текущей сущности. СВОЙСТВА - список атрибутов текущей сущности. Кнопки <Открыть> - передать менеджеру пожелание что-либо сделать с текущей сущностью (обычно открыть соответствующую КАРТОЧКУ) или всем списком. Кнопки <Новая> и <Удалить> -  конечно сущность. ВЗГЛЯД может также применяться для расширенного выбора сущности.

Оказалось, что схожая механика работает и для описанного выше формата данных (кстати, он называется ГЛЮКВА). ПУТЬ - он и там, и там путь, ОБЪЕКТЫ - листьев-наследников, СВОЙСТВА - текст и параметры листа, ТЕМЫ - альтернативные пути к этому листу... Эта штука работала у меня на страничке. Правда, кроме удобства навигации, она с успехом служила эффективной "защитой от дурака"...

Дальнейшее совершенствование этого подхода должно бы привести к функциональному разделению экранных форм, навроде "комнатной модели" ТЕМА #34...

Я ОПЯТЬ ЗАБЕЖАЛ ВПЕРЕД

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

К чему все эти кодировки-раскодировки и стройные ряды GOTO?

Для обеспечения вашей программе трех возможностей, без которых она не поумнеет:
1. работать с текстовыми данными,
2. работать со структурами данных,
3. работать с программой как с данными.

Те языки, в которых такие возможности представлены изначально, всегда считались "для искусственного интеллекта", например, LISP. Встраивание же элементов этих "высоких технологий" в "обычные" языки часто подается как "прорыв, открывающий бескрайние горизонты". Например, работы того же Вирта, вроде "Алгоритмы + структуры данных = программы".

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

ТЕКСТ

Сколько есть языков работы с текстом, столько есть методик этой самой работы.

Вариант первый: текст - это просто массив, массив символов.
Это не просто, но очень просто. Поэтому программы работы со строками на языке C выглядят зачастую проще, чем аналогичные программы на его потомках, имеющих специальный "строковый тип".

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

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

Вариант второй. Строки, разбитые на поля фиксированной длины. Как это обычно практикуют в базах данных. Этот вариант даже проще первого, т.к. строки произвольной длины не допускаются. Но, все равно, его умудряются еще немного упростить, подменяя строковые значения числовыми (индексы в тех же базах данных), т.к. обычно разнообразие строк ограничено.

Вариант третий. Регулярные выражения. Если во втором варианте строки описывались списком полей, то здесь они описываются специальной "регулярной формулой". Это понятие математическое и разобраться с сопутствующей математикой гораздо проще, чем запомнить подробности конкретной реализации (например, в Perl). Знание математики сводится к построению конечного автомата, соответствующего данному выражению, что настолько просто, что может быть поручено самой программе. Что дают регулярные выражения? Одно из двух: либо разбор строки на значимые части (как выше поля, но гораздо гибче), либо изменение состояния программы, в зависимости от ввода (например, распознать текущий символ как префикс другого, сложного символа, см. выше многобайтовые символы).

Вариант четвертый.  Макроподстановки. Самый, что ни на есть классический. Строим машину, единственной функцией которой будет замена некоторых слов строки на другие. И получается самая настоящая вычислительная машина. Есть даже забавный язык программирования, на этом основанный - Trac, в котором макроподстановка вполне заменяет подстановку фактических параметров при вызове процедур. Дополнительным бонусом идет возможность сравнения строк "из которых выкинуто все лишнее", т.н. унификация в языках искусственного интеллекта (например Planner).

Отдельно идет возможность распознать начало строки и оставить остаток на потом. Например, прочесть одно слово (до пробела) и исполнить его - в FORTH. Или читать от скобки до скобки - в LISP.

Что из всего этого нам надо прямо сейчас, и что умеет наш BASIC?

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

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

1100 REM PATH
1110 IF LEN(R$)=0 THEN 2300
1120 IF MID$(R$,2,1)=" " THEN 2400
1130 IF LEFT$(R$,1)="\" THEN 2500
1140 IF LEFT$(R$,5)="ТЕКСТ" THEN 2600
1150 IF LEFT$(R$,7)="ТАБЛИЦА" THEN 2700
1160 IF LEFT$(R$,6)="ЗАПИСИ" THEN 2800

Строковые операции GWBASIC рассчитаны на строки, разбитые на поля и немножко, на макроподстановку. Две основные: MID$ - извлечение и подстановка подстроки, считая по символам и INSTR - поиск подстроки. Плюс - танцы с бубном для нетривиальных случаев. К счастью, не надо беспокоиться об управлении памятью, но, к несчастью, ограничения ресурсов не позволяют полностью разместить распознанный текст в памяти.
***

СТРУКТУРЫ ДАННЫХ

В наследство от Машины Тьюринга нам достался вывод о том, что, в принципе, данные и код взаимозаменяемы. Что сложная программа с простыми данными, что простая со сложными. Например, навигация по нашей базе путем перебора всех строк и накопления результатов во временных файлах (последовательные операции) гораздо сложнее, чем перемещение по представляющему ее в памяти дереву (общая операция). Однако, ограниченные возможности GWBASIC не позволяют сложных данных. Приходится компенсировать кодом. Какие тут хитрости?

1. Любая сложная структура моделируется массивами.

В общей операции построения дерева

100 OPTION BASE 1:DIM P$(1024),L(1024): P=1024
200 DIM T(1024),C(1024),B(1024): Z=1

Здесь массивы P$ и L - это ассоциативное хранилище строк (массив структур с полями "строка" и "ссылка на следующую").
T, C и B - "дерево узлов" (массив структур с полями "ссылка на строку", "ссылка на старшего сына", "ссылка на младшего брата").

2. Никаких структур про запас. Все промежуточные результаты скидывать в файлы (только последовательные операции).

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

Отсюда и пошли у меня все эти вырезатели и добавляторы.

3. Заменять структуры операциями, операции обозначать кодами, коды сохранять в данных.

5040 IF F<>120 THEN 5100 'СТОЛБЕЦ УСЛОВИЯ A
5050 IF O AND 64 THEN IF INSTR(R$,"днако") THEN GOSUB 4300: GOTO 5120 '*
5060 IF O AND 32 THEN GOSUB 4200: GOTO 5120 'A
5070 IF O AND 16 THEN GOSUB 4600: GOTO 5120 'X
5070 IF O AND 8 THEN GOSUB 4400: GOTO 5120 'BT

Т.е. я не поддерживаю структуру файлов строк, следящих за правильным порядком узлов, а вызываю нужные для правильной записи узлов команды, "прошитые" в переменную О.
***

КОД КАК ДАННЫЕ

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

Есть две основные возможности:

1. Добавлять код в программу по мере надобности (может, руками, может, автоматически).

В BASIC этот прием используется очень широко: в программе легко зарезервировать номера строк, куда программист будет вставлять свой код.

2300 REM PATH - ПУСТО - PARAM
2390 LINE INPUT#1, R$: GOTO 1400
2400 REM PATH - БУКВА+ПРОБЕЛ - PARAM
2490 GOTO 1400
2500 REM PATH - ОБР.КОСАЯ - PATH
2590 LINE INPUT#1, R$: GOTO 1100
2600 REM PATH - "ТЕКСТ" - TEXT
2690 LINE INPUT#1, R$: GOTO 1300
2700 REM PATH - "ТАБЛИЦА" - HEAD
2790 LINE INPUT#1, R$: GOTO 1200
2800 REM PATH - "ЗАПИСИ" - HEAD
2890 LINE INPUT#1, R$: GOTO 1200
2900 REM PATH - ПРОЧЕЕ - GARBAGE
2990 GOTO 1000

Т.е. нужный "пользовательский" код вставляется здесь между строками 2x00 и 2x90. С таким приемом мы уже встречались в главе про "искусственный интеллект"ТЕМА #63, АБЗАЦ #691 (там можно посмотреть и примеры работы со строками).

2. Создать свой простой "язык", который можно прошить в обычный массив.

В языках с адресной арифметикой (например, C) можно хранить адреса функций, но в BASIC приходится ограничиться набором IF-ов.

См. выше "чтение программы" из переменной O.
***

К сожалению, правка кода "на лету" не только вызывает иногда проблемы со стороны "систем безопасности ОС", но и порождает очевидные сложности в определении момента превращения данных в код... Поэтому можно использовать промежуточное представление в виде временного исполняемого файла. Такое возможно даже в BASIC - создать новый BASIC-файл и подгрузить его оверлеем или новым процессом.
Это превращает задачу обработки кода в задачу обработки строк. Но.. Технология интерпретации строк проработана только в LISP-подобных языках, обитающих в области программистской эзотерики. Это связано с одной из жутких несуразностей "нормальных языков программирования". В них под-языки "выражений" и "операторов" - это по-сути два разных языка программирования (вспомните, например, как в BASIC сильно отличались функции - вычислители выражений - от подпрограмм - наборов операторов). И, программируя на лету, я не просто должен описать операторы в виде выражений, но и следить когда я перескакиваю с языка на язык. Что в данном случае проще: создать мощный [макро]язык работы со строками или "простой" прошиваемый язык?

Вот, как-то так...
А в "настоящих" языках? Да, так же...

К сожалению, жонглирование информационными структурами - это только часть проблемы. Точнее, это то, что относится, собственно, к программированию. Но нам надо еще это и запустить на своей машине. И тут начинается самое неприятное. Цепочка действий тут совершенно не такая, как в программировании. Не надо никакой математики. Не надо видения задачи. Надо только обвесить программу кучей всякой лабуды. Это не то, чтобы сложно, но очень нудно - по причине применения метода постепенной отладки.
Т.е. начинаем с пустой программы или примера из учебника. Добавляем какой-нибудь новый интерфейс. Валится? Лезем в Сеть, узнаем, почему. Исправляем. Работает? Добавляем еще один. Валится?.. Например, желание прицепить к этому форуму картинку с возможностью ее редактирования (чтобы обойти ограничения форума на хранение информации) вызвало три большие JavaScript-проблемы: как прицепить внешний файл, как работать с байтами, как создать картинку из текста. Вроде, работает, но не везде и не поручусь, что работает правильно.
Кроме нудности и неопределенности процесса, мешает и еще одно неприятное свойство системных интерфейсов - их нельзя выделить в компактные модули, которые можно написать один раз и потом просто прицеплять к разным программам. Например, когда вы пишете WIN-программу на MS Visual Studio C++, вас сначала долго мучают вопросами о необходимых интерфейсах (как и каким местом вы будете прицеплять вашу программу к MustDie). Затем вы получите набор файлов, в которые нужно вставлять вашу программу по кускам в специально выделенные места. И основное назначение "обезьянников" - скрыть от программиста код интерфейсов, который трогать нельзя. В случае с цеплянием файла к HTML оказалось, что все запихивать прочитанное из файла в документ можно только из той же функции, которая этот файл читает (из-за асинхронности чтения).

Итак, (написанная ранее) программа, из которой я буду делать JavaScript просмотрщик базы данных, состоит из плясок с бубном вокруг пяти интерфейсов:
1. XMLHttpRequest - открытие файла для чтения.
2. DataView - работы с байтовым массивом.
3. data:image/gif;base64 - вывода картинки прямо из текста.
4. base64 - перекодировки байтов картинки в этот формат.
5. Свойства объекта document - формирование нового содержимого документа.

Для просмотрщика (4) пока не нужно. Отрезаю. Вместо него вставляю
6. Самописный перекодировщик байтов из файла в кодировку utf-8.

Ну, пока можно остановиться и переписать на JavaScript, то, что мы писали на BASIC.
Конечно, после каждой новой строки перевыводил HTML для проверки. Стоило изменить зараз несколько строк, все падало замертво, и приходилось откатывать назад.
Попытался, заодно, почитать книжку по JavaScript, но меня быстро вытошнило.

Пришлось вспомнить как рисовать в HTML деревья:
7. Всякие style, onclick и прочая фигня (когда-то очень давно выломал из какой-то гостевой).

Вроде, дерево грузится. Можно грузить остальной HTML-обвес.
8. Все делаю самым простым способом - HTML-рамочками.

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

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

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

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

<!-- ТЕХНОЛОГИЯ #8 - HTML-рамочки. Обратите внимание, весь этот текст набран в Юникоде, дальше это будет важно -->

<html><head>
<meta http-equiv="Content-Type"; content="text/html; charset=utf-8"></head>
<body bgcolor=#ccac9c text=#000000>

<!-- ТЕХНОЛОГИЯ #7 - стили для сокрытия/показа выпадающих списков -->

<style type="text/css">.S1 { display: none }</style>
<style type="text/css">.S2 { }</style>

<!-- ТЕХНОЛОГИИ #8 и #5 - HTML-рамочки, в которых метками I1-I3 отмечены места для вставки текста -->

<hr><table border=0 width=100%><tr><td valign=top>
<span id=I1>Файл будет грузится долго...</span>
</td><td align=right><table border=1><tr><td bgcolor=#9c8c7c>
<div id=I2>Ждите...</div>
</td></tr></table></td></tr></table><hr>
<div id=I3></div>

<SCRIPT language=javascript>
var A, B, D, F, G, J, K, L, O, P, Q, R, U, V, W, X, Y, Z;

// ТЕХНОЛОГИЯ #5 - свойства объекта document

F=String(document.location).match(/F=([^&]*)/);
document.title=F[1];

// Собственно то, что было в BASIC

function A1 () {
P = 0;
W = R.split("\\");
for (var V=1; V<W.length; V++) {
if (!Y[P][3]) Y[P][3] = {};
if (Y[P][3][W[V]]) P = Y[P][3][W[V]]
else {
Y.push([P, W[V], 0, 0]);
Y[P][3][W[V]] = Y.length-1;
P = Y.length-1 } }
Y[P][2] = L;
L[0][R] = P }

A = [[[/^\\/, function () { L = [{}, 0, [], [], {} ]; }, 1, 0],
[/^\s*$/, function () { }, 0, 1],
[0, function () { J.push(R) }, 0, 1]],
[[/^\s*$/, function () { }, 4, 1],
[/^[A-Za-z] /, function () { }, 4, 0],
[/^\\/, function () { A1() }, 1, 1],
[/^ТЕКСТ/, function () { L[1] = 1 }, 3, 1],
[/^ТАБЛИЦА/, function () { L[1] = 2 }, 2, 1],
[/^ЗАПИСИ/, function () { L[1] = 3 }, 2, 1],
[0, function () { }, 0, 0]],
[[/^\s*$/, function () { }, 3, 1],
[0, function () { L[2].push(R) }, 2, 1]],
[[/^\s*$/, function () { }, 4, 1],
[0, function () { L[3].push(R) }, 3, 1]],
[[/^[A-Za-z] /, function () { L[4][R[0]] = R.slice(2) }, 4, 1],
[/^\\/, function () { L = [{}, 0, [], [], {} ]; }, 1, 0],
[/^\s*$/, function () { }, 0, 1],
[0, function () { }, 0, 0]]];

// ТЕХНОЛОГИЯ #3 - хранение GIF-ов в тексте HTML

O = ["<img src=\"data:image/gif;base64,"+
"R0lGODlhEAAQANIAABw8ADxsDGyMANzMvP///7ysnAAAAAAAAC"+
"H5BAlkAAQALAAAAAAQABAAAAM4SLrc/pCIKYKIdIb9ZinaFjTe"+
"F27XUlIip2ZVO75sANzArMg2njM8HyC1kPl0QBEOSWoRI9AoIw"+
"EAOw==\"/>",
"<img src=\"data:image/gif;base64,"+
"R0lGODlhEAAQANIAABw8ADxsDGyMALysnP///wAAAAAAAAAAAC"+
"H5BAlkAAQALAAAAAAQABAAAAMrSLrc/pCJ6ESgMlxMrK7CMAik"+
"9klkapqoGgAwsCmrFsPYzcUcgfeznjCSAAA7\"/>",
"<img src=\"data:image/gif;base64,"+
"R0lGODlhEAAQANIAABw8ADxsDGyMALysnP///wAAAAAAAAAAAC"+
"H5BAlkAAQALAAAAAAQABAAAAMrSLrc/lCJGeKaoloy6ObehmkW"+
"RTaYCazASQQwzK5PHMxRzG4y8L2un/CRAAA7\"/>",

// ТЕХНОЛОГИЯ #7 - рамочки

"<table border=0 cellspacing=0 cellpadding=0><tr>"+
"<td bgcolor=#bcac9c>&nbsp;</td><td bgcolor=#8c7c6c><b>",
"</td><td bgcolor=#5c4c3c>&nbsp;&nbsp;</td></tr><tr>"+
"<td bgcolor=#dcccbc>&nbsp;</td><td bgcolor=#9c8c7c>",
"</td><td bgcolor=#5c4c3c>&nbsp;</td></tr>"+
"<tr bgcolor=#5c4c3c><td bgcolor=#8c7c6c>&nbsp;&nbsp;"+
"</td><td colspan=2>&nbsp;</td></tr></table>"];

// ТЕХНОЛОГИЯ #7 - ф-ии сворачивания/разворачивая списка

function C(P) {
Q = document.getElementById("N"+P);
if(Q.className == "S1") {
Q.className = "S2";
document.getElementById("M"+P).innerHTML = O[2]
} else {
Q.className = "S1";
document.getElementById("M"+P).innerHTML = O[1] }
return false }

// ТЕХНОЛОГИЯ #8 - заполнение табличек

function T2(Z,P,W) {
return "<a  style=\"cursor:pointer\" "+
"onclick=\"return "+Z+"("+P+");\"><font color=#dcccbc>"+
"<u>"+W+"</font></u></a>" }

function T1(P) {
W = "";
while (P) {
if (Y[P][2])
W = "\\"+T2("T",P,Y[P][1])+W
else
W = "\\"+Y[P][1]+W
P = Y[P][0] }}

function T(P) {
B = "<h3>"+T2("T",0,(J.length?J[0]:F[1]))+"</h3>"
if (P) {
B += O[3]+"ТЕКУЩИЙ ПУТЬ:"+O[4];
B += O[0]+Y[P][1]+"<br>";
T1(Y[P][0]);
if (W) B+= O[1]+W+"<br>";
B += O[5] + "<br>" + O[3] + "ОСТАЛЬНЫЕ ПУТИ:" + O[4];
for (V in Y[P][2][0]) if (Y[P][2][0][V]!=P) {
T1(Y[P][2][0][V]);
B += O[1]+W+"<br>" }
B += O[5] + "<br>" + O[3] + "БРАТЬЯ:" + O[4];
for (V in Y[Y[P][0]][3]) if (Y[Y[P][0]][3][V]!=P && Y[Y[Y[P][0]][3][V]][2])
B += O[1]+T2("T",Y[Y[P][0]][3][V],V)+"<br>";
B += O[5] + "<br>" + O[3] + "СЫНОВЬЯ:" + O[4];
for (V in Y[P][3]) if (Y[Y[P][3][V]][2])
B += O[1]+T2("T",Y[P][3][V],V)+"<br>";
B += O[5]; }
document.getElementById("I1").innerHTML = B;
B = "";
if (P) {
L = Y[P][2];
for (V = 0; V<L[2].length; V++) B += L[2][V]+"<br>";
B += "<hr>";
for (V = 0; V<L[3].length; V++) B += L[3][V]+"<br>";
B += "<hr>";
for (V in L[4]) B += "["+V+"] "+L[4][V]+"<br>" }
else for (V = 0; V<J.length; V++) B += J[V] ;
document.getElementById("I3").innerHTML = B;
return false }

function H(P, Z) {
var W = [];
B += "<div style=\"margin-left: "+Z+"px\">";
if (Y[P][3]) {
B += T2("C",P,"<span id=M"+P+">"+O[1]+"</span>");
} else B += O[0];
if (Y[P][2]) {
B += T2("T",P,Y[P][1])
} else B += Y[P][1];
B += "</div>";
if (Y[P][3]) {
B += "<div class=S1 id=N"+P+">";
for (var V in Y[P][3]) W.push(V);
W.sort();
for (var V=0; V<W.length; V++) H(Y[P][3][W[V]], Z+20);
B += "</div>" }}

// ТЕХНОЛОГИЯ #1 - пляски с бубном. Спасибо, добрым людям, подсказали.
// Насколько хорошо и в каких версиях разных Браузеров это работает - не знаю.

X = new XMLHttpRequest();
X.open("GET", F[1], true);
X.responseType = "arraybuffer";
X.send(null);

// ТЕХНОЛОГИЯ #9 - расковыривание GIF

function D2 () {
V = 13;
K = D[0].getUint8(10);
if (K&128) V += ((1<<((K&7)+1))*3);
do {
K = D[0].getUint8(V);
if (K==44) {
K = D[0].getUint8(V+9);
V += 11;
if (K&128) V += ((1<<((K&7)+1))*3);
while (K=D[0].getUint8(V)) V += K+1;
V++ }
} while (K!=33);
V += 2 }

// Ф-ия, которая все и делает

function D1 () {
Y = [[0 , "СОДЕРЖАНИЕ", 0, 0]];
J = [];
R=""; G=0;
while (K=D[0].getUint8(V++)) {
D[1]=V+K;
for (; V<D[1]; V++) {
K=D[0].getUint8(V);
if(K==10) { }
else if(K==13) { do {
for (var U=0; U<A[G].length; U++) {
if (!A[G][U][0]||A[G][U][0].exec(R)) {
A[G][U][1]();
if (A[G][U][3]) R = "";
G = A[G][U][2];
break }}} while (R) }

// ТЕХНОЛОГИЯ #6 перекодировщик из Win-1251 в Юникод
// (вот где важна кодировка нашего HTML)

else R += ("*********\t**********************"+
" !\"#$%&'()*+,-./0123456789:;<=>?"+
"@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\\]^_`abcdefghijklmnopqrstuvwxyz{|}~ "+
"****************************************************************"+
"АБВГДЕЖЗИЙКЛМНОПРСТУФХЦЧШЩЪЫЬЭЮЯабвгдежзийклмнопрстуфхцчшщъыьэюя")[K] } } }

// ТЕХНОЛОГИЯ #1 - проверка, готов ли файл.
// Обратите внимание: все считывание и отрисовка происходят внутри этой
// ф-ии, вызываемой асинхронно, по готовности файла.

X.onreadystatechange = function () {
if (X.readyState == 4) {
D = [X.response];

// ТЕХНОЛОГИЯ #2 - получение доступа к готовому файлу

D[0] = new DataView(D[0]);
D2();
D1();
B="";
H(0, 0);
document.getElementById("I2").innerHTML = B;
T(0)}}

</SCRIPT>
</body></html>

Что получилось (для навигации по СОДЕРЖАНИЮ, жмите на стрелочки): Кусок редактируемой БД в сыром виде

Я все пытаюсь доказать, что на самом убогом компьютере и при любом уровне программирования можно сыграть в игру - построение информационной модели некоего процесса (в т.ч. другой игры). Это называется:

Гете пишет:МОРФОЛОГИЯ еще должна легитимироваться, как особая наука, делая своим главным предметом то, что в других трактуется при случае и мимоходом, собирая то, что там рассеяно, и устанавливая новую точку зрения, позволяющую легко и удобно рассматривать вещи природы. Явления, которыми она занимается, в высшей степени значительны; те умственные операции, при помощи которых она сопоставляет явления, сообразны с человеческой природой и приятны ей, так что даже неудавшийся опыт все-таки соединит в себе пользу и красоту.

Эту цитату я выдрал из книги Проппа Морфология ВОЛШЕБНОЙ СКАЗКИ.
А вот еще пара цитат из этой книги:

Приведенный здесь фрагмент взят из книги: М.Г.Гаазе-Раппопорт, Д.А.Поспелов, "От амебы до робота: модели поведения", М., Наука, 1987.

В конце двадцатых годов XX века советский исследователь В.Пропп пришел к выводу, что все волшебные сказки состоят из одного и того же небольшого набора базовых элементов, а любая сказка - одно из возможных их сочетаний. Более того, Пропп описал все возможные сочетания базовых элементов и построил сюжет универсальной волшебной сказки, который и исчерпывал весь мир сказок. Рассмотрим его подробнее.
***

Персонажи волшебных сказок действуют в особом мире, мало похожем на реальный. В сказочном мире нет привычного для нас времени, нет и того пространства, которые определяют наши перемещения. Сказочные герои перемещаются в своем мире как бы мгновенно. И лишь традиционные формулы типа "Скоро сказка сказывается, да не скоро дело делается" или "Долго ли, коротко ли, но прибыл Иван в Кащеево Царство" очерчивают все эти передвижения в пространстве и бег времени. Для волшебных сказок характерна еще одна особенность. Их персонажи не рассуждают, а действуют, как это предписывается их ролями. Герой всегда преследует врага, борется с ним и побеждает; глупый царь всегда остается в проигрыше, а Баба-Яга всегда оказывается обманутой. В поступках действующих лиц как бы нет той части, которая относится к замыслу, и в повествование включается лишь реализация поступка с априорно предсказуемыми оценками. Далее, каждый персонаж не имеет выбора при необходимости совершить поступок. Ритуальность поведения в волшебной сказке доведена до своего логического завершения. Немыслимо, чтобы герой, проанализировав возможные отрицательные последствия, отказался от битвы со своим противником, и столь же невозможно раскаяние антигероя.

(->)	Появление Героя с богатыми подарками и рассказ его о том, как это получилось
(?)	Встреча Ложного Героя с Дарителем
(!)	Если Даритель просит что-нибудь сделать, то отказаться сделать это
(->)	Отказ Дарителя от оказания помощи

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

(->)	Погоня Помощника Антигероя за Героем
(?)	Наличие волшебных даров. Их больше одного
(!)	Если Помощник Антигероя догоняет Героя, то использовать очередной волшебный дар
(->)	Задержка Помощника Антигероя. Уменьшение числа волшебных даров на единицу

(->)	Погоня Помощника Антигероя за Героем
(?)	Наличие одного волшебного дара
(!)	Если Помощник Антигероя догоняет Героя, то использовать волшебный дар
(->)	Гибель Помощника Антигероя или отказ его от погони

(->)	Погоня Помощника Антигероя за Ложным Героем
(?)	Отсутствие волшебных даров
(!)	Если Помощник Антигероя догоняет Ложного Героя, то гибель
(->)	Прекращение линии Ложного Героя

И еще - все фунции (31 штука), допустимые в сказках (причем только в приведенной ниже последовательности):

ПОДГОТОВИТЕЛЬНАЯ ЧАСТЬ
1	Отлучка	Уезжают родители; царь идет на войну
2	Запрет	"Не заходи только в десятую комнату"
3	Нарушение	Побежала Аленушка на улицу, заигралась
4	Выведывание	Стала ведьма вызнавать...
5	Выдача	"Но царевна все ж милее..."
6	Подвох	Волк подражает голосу мамы-козы
7	Пособничество	Царевна ест предложенное старухой яблочко
8	Вредительство или недостача	Схватили гуси-лебеди Иванушку,заболел царь тяжелой болезнью
ЗАВЯЗКА
9	Посредничество	"Иди, Марьюшка, братца искать..."
10	Начинающееся противодействие	"Позволь мне, царь, попытать счастья..."
11	Отправка	Царевич отправился в путь
ОСНОВНАЯ ЧАСТЬ
12	Первая функция дарителя	Стала Баба-Яга вопросы спрашивать
13	Реакция героя	"Ты б меня сперва накормила..."
14	Получение волшебного средства.	Дал старичок Ивану коня;"Скажи: по щучьему велению..."
15	Перемещение в иное царство	Долго ли шла Марьюшка, коротколи...
16	Борьба	Стал Иван биться со Змеем
17	Клеймение	Расцарапал ему Змей всю шею
18	Победа	Завертелся Кощей и сгинул
19	Начальная беда или недостача ликвидируется	Вышла к Ивану из подземелья Царь-девица.
20	Возвращение	Сели на ковер-самолет, полетели домой
21	Погоня	Бросились гуси-лебеди вдогонку
22	Спасение	Бросила она зеркальце, разлилось море.
На этом сказка может кончиться, но часто встречается дополнительный сюжет, в котором действует лжегерой (чаще всего брат или братья главного персонажа). Первая его часть новое вредительство -аналогична функциям 8-15
8а	Лжегерой похищает добычу
10а-11а	Герой снова отправляется на поиски
12а-14а	Герой снова находит волшебное средство.
Далее при таком развитии появляются новые функции:
23	Неузнанное прибытие	Приехал в родной город, но домой непошел, стал учеником портного.
24	Необоснованные притязания	Генерал заявляет царю: "Я - змеевпобедитель"
25	Трудная задача	"Кто поднимет змеиную голову..."
26	Решение	Подошел Иван, только тронул...
27	Узнавание	Показал он заветное колечко
28	Обличение	Рассказала все царевна, как было
29	Трансфигурация	Искупался Иван в молоке, вышел лучшепрежнего
30	Наказание	Посадили служанку в бочку...
31	Свадьба, воцарение	Получил Иван царевну и полцарства

Игра или не игра?

ПОЗНАЙ СЕБЯ ЧЕРЕЗ КОМПЬЮТЕР / ТЕХНИКА - МОЛОДЕЖИ 06/88
Александр КРОНИК, кандидат психологических наук, Алексей ПАЖИТНОВ

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

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

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

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

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

Программа создает основу для разработки различных компьютерных биографических игр, одна из которых уже реализована и включена в состав самого БИОГРАФА. Она называется МУДРЕЦ, поскольку помогает более реалистично взглянуть на свою жизнь, оценить ее отдельные эпизоды.

На дисплее перед вами появляются в хронологическом порядке события, о которых вы беседовали с БИОГРАФОМ, в ваших собственных формулировках. Например:

1. Первые впечатления.
2. Прибытие в Москву.
3. Школа.
4. Кузнец.
5. Лето 1939 года.
6. Монголия.
7. Начало войны.
8. Снаряд.
9. Кафедра.
10. Галя.
11. Рождение дочек.
12. Нейтрон.
13. Мир.

МУДРЕЦ предлагает: "События - перед вами - в хронологическом порядке. Выберите самое важное - то, которое сильнее всего изменило вашу жизнь или изменит ее в будущем".

Вы указываете номер самого важного, на ваш взгляд, события. Пусть это будут "Первые впечатления" (#1). МУДРЕЦ тут же сообщает свое веское мнение: "Вы немного ошибаетесь. Это событие 3-е по важности. А какое все же на 1-м месте?"

Вы удивлены: как он может судить о вас? Скажем по секрету, что о важности событий вы сообщили ему сами в косвенной форме во время предшествующего диалога с БИОГРАФОМ. В этом интервью вы подробно проанализировали причинные (почему?) и целевые (для чего?) связи между событиями, а компьютер подсчитал, сколько связей имеет каждое. А чем больше таких связей, тем важнее событие, хотя мы это не всегда осознаем. Различные психологические барьеры и защитные механизмы приводят к иллюзиям: иногда мы "из мухи делаем слона", а порой действительно значимые события считаем мелочами. МУДРЕЦ же объективен. Какое же все-таки на первом месте? "Начало войны",- волнуясь, решаете вы. МУДРЕЦ бесстрастно констатирует: "Вы близки к истине, но это событие для вас 2-е по важности. А какое все же на 1-м месте?"

Наконец, ответив "Мир", получаете долгожданный вердикт: "Вы абсолютно точны. Это событие 1-е по важности. Подумайте теперь: какое событие на 4-м месте?"

Игра продолжается до исчерпания списка. В результате на экране получается, например, такая картина:

XXXXXXXXXX 3. Первые впечатления.
XXXXXXXXXXX 2. Начало войны.
XXXXXXXXXXXX 1. Мир.
XXXXXX 7. Лето 1939 года.
XXX 10. Прибытие в Москву.
XXXXXXXXX 4. Монголия.
XXXX 9. Кафедра.
XXXXXXXX 5. Снаряд.
XXXXXXX 6. Галя.
X 12. Нейтрон.
XXXXX 8. Рождение дочек.
XX 11. Школа.
13. Кузнец.

Сверху вниз события расположены от самого важного до неимение важного (с вашей точки зрения); справа налево - по мнению МУДРЕЦА (самое важное - правее всех, оно обозначено цифрой 1).
Если бы оценки сторон совпадали, события на экране расположились бы строго по диагонали - из правого верхнего угла в левый нижний. Степень близости к этой диагонали - показатель реалистичности вашего взгляда на собственную жизнь. Он измеряется в баллах, от -100 до +100. Отрицательные значения получит тот, кто не замечает действительно важного в своей жизни, а мелочи переоценивает. Положительные значения характеризуют человека как более-менее трезво мыслящего. (Очевидно, вычисляется коэффициент ранговой корреляции.- Ред.) С МУДРЕЦом играли десятки людей. В среднем лишь одному из трех удавалось набрать свыше 60 баллов.

В результате многочисленных диалогов с БИОГРАФом самых разных людей психологами создан своеобразный "банк человеческих судеб". Данные биографических обследований хранятся в нем в тех формулировках, с помощью которых человек счел возможным приоткрыть свою жизнь постороннему взгляду. Это в сочетании с анонимностью самообследования позволяет воспользоваться характерными вариантами жизненного пути для создания еще одной биографической игры - ИНКОГНИТО. Вот ее сценарий.

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

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

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

На этом заканчивается первое знакомство с героем-инкогнито. Ваши представления о нем пока весьма фрагментарны: в лучшем случае вы видите на экране два-три события.

Но игра не закончена. С помощью прежней процедуры вы последовательно выбираете самые важные возрасты, создавая более богатую и точную картину жизни героя. Третья попытка, четвертая... И так до тех пор, пока рядом с каждым возрастом не появится название события. Ваша проницательность оценивается очками: на первом этапе по 20 за правильный ответ, затем - 15, 11, 8, 6, 5, 4, 3, 2, 1.

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

На основе биографического материала можно создавать и конструктивные игры, позволяющие строить в воображении жизненный путь. Вот достаточно простая схема такой игры, назовем ее ИГРА СУДЬБЫ.

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

Как ее оценить? Первый критерий - разумное распределение радостных и печальных событий. Длительная "черная полоса" ведет к подрыву жизненных сил и прочим несчастьям. С другой стороны, продолжительный "радужный период" расслабляет человека, делает его беззащитным перед невзгодами.

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

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

Каждый "дисбаланс" по-своему влияет на учитываемые в ИГРЕ СУДЬБЫ ресурсы жизненных сил, здоровья, опыта. В зависимости от их состояния меняется продолжительность получившейся "жизни". Серия тяжелых ударов может трагически прервать ее в самом расцвете, оптимальная же стратегия позволит вам достичь библейского возраста...

Одно из интереснейших направлений - разработка биографических игр с включением других лиц, спутников вашей жизни. Вот, например, сценарий такой персонажной игры - СВОЕ ЛИЦО.

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

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



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

Первый этап игры кончается в тот момент, когда вы достигаете границы экрана. Результат оценивается по сходству реализованного и целевого выражения лица. Но игра предусматривает несколько этапов. На втором ("детство") ваши спутники разделяются на друзей и врагов. Дружественные персонажи изображаются тем же цветом, что и ваш. Взаимное влияние усложняется: соседи-друзья становятся похожими друг на друга, соседи-недруги - более непохожими. Цель прежняя - достичь заданного выражения лица.

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

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

Каталог биографических компьютерных игр далеко не исчерпан. Будем рады, если эта статья побудит вас к собственным разработкам.
***

Кому интересно, это называется Каузометрия...

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

ТМ 8/83

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


Информационный терминал будущего. Цифрами обозначены: 1 - изображение заказанных в библиотеке книг, 2 - экран, 3 - видеотелефонное изображение собеседника, 4 - графики, 5 - материалы периодической печати, 6 - указатели, 7 и 17 - кнопии управления экраном, 8 - панель микро-ЭВМ, 9 - микрофон и громкоговоритель, 10 - телекамера, 11 - таблица для записи информации в цифровой форме, 12 - ввод и вывод информации на бумаге, 13 - клавиатура, 14 - кнопки управления каналами, 15 - кнопна управления вводом, 16 - устройство подключения к каналам передачи речи и изображения.

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

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

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

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

ТМ 2/76

КАБИНЕТ ДЕЛОВОГО ЧЕЛОВЕКА
АЛЕКСЕЙ КОЛОСОВ

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

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

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

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

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

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


На снимках: кабинет руководителя подразделения, директора объединения, министра, рабочее место секретаря и помещение планового отдела.
1 - видеотелефон ВИД-10, 2 - установка оперативной телефонной связи "Псков-2", 3 - система телеобработки данных "Экран-М", 4 - установка телефонной связи "Элетап", 5 - пишущая машинка системы "Экран-М", 6 - доска с показателями, 7 - конторское дежурное устройство, 8 - оперативно-переговорное устройство "Гарсас", 9 - папки с документами, 10 - рабочее место начальника планового отдела, 11 - формулярная машина типа "Аскота", 12 - настольная электронно-вычислительная машинка, 13 и 14 - ящики для документов.

В случае вызова на том или ином пульте загорается световой сигнал. По желанию руководитель может включить громкоговорящую связь между пультами, вести разговор сразу с тремя подчиненными и одним абонентом АТС. Если руководитель занят, то звонящий абонент ожидает, а потом вторично подключается. С пультом руководителя соединено табло с надписью "Не входить".

В кабинете директора предприятия, института тоже находится оперативно-переговорное устройство. Только называется оно "Кристалл-70" и по сравнению с установкой "Псков-2" имеет более широкие возможности. Прямая связь - почти с шестьюдесятью абонентами, восемь соединительных линий от АТС и РТС. В комплект установки входит до 100 телефонных аппаратов. К "Кристаллу-70" можно подключить громкоговорящее устройство, магнитофон или диктофон для записи переговоров. Связь включается практически немедленно простым нажатием клавиши.

На этом сходство кабинета директора с кабинетом руководителя подразделения практически заканчивается.

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

Рабочая зона находится в наиболее освещенной части кабинета. Здесь находятся стол и кресло для посетителей. В зоне для совещаний обращает на себя внимание длинный стол с рядами стульев. А третья зона, предназначенная для неофициальных переговоров, хотя и не отличается по общему стилю оформления от предыдущих, выглядит несколько легкомысленно: журнальный столик, мягкие удобные кресла, цветы. Так и должно быть. Это зона не только неофициальных переговоров, но и отдыха.

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

Любопытно, что на рабочее место секретаря вынесены даже некоторые виды аппаратуры связи, например, оперативно-переговорное устройство "Гарсас", которое мы видели на столе руководителя подразделения, факсимильный аппарат "Штрих-М", директорский коммутатор, телефонный городской автоответчик. Последнее приспособление интересно тем, что оно представляет собой сочетание телефона и магнитофона. Вы уходите, скажем, из дому, но хотите передать что-то друзьям, которые будут звонить по телефону, может быть, назначить им место встречи. За вас это сделает автоответчик, включив пленку с заранее записанным текстом.

А если вы подсоедините к автоответчику дополнительно магнитофон или диктофон, то он сможет записать для вас сообщение от ваших друзей. Автоответчик имеет шесть режимов работы: "Телефон", "Запись", "Контроль", "Ответчик", "Секретарь", "Разговор".

Конечно, сообщение, передаваемое автоответчиком, должно быть коротким, не более 20-25 секунд. В производственной практике этого вполне достаточно, чтобы в отсутствие директора все звонящие приняли к сведению какое-то важное его сообщение. Если есть необходимость, директор может и сам связаться со своими подчиненными, минуя секретаря. Дело в том, что наиболее эффективную технику с широкими возможностями он оставил у себя на столе. Для телефонной связи директор использует устройство программированного набора "Элетап", разработанное с учетом новейших достижений электронной техники. Для вызова нужного абонента достаточно нажать соответствующую кнопку, и аппарат сам произведет набор любого из 60 предварительно запрограммированных номеров. Если номер занят, то устройство автоматически будет повторять набор до тех пор, пока не осуществится соединение. Аппарат имеет и еще одно удобство - в него можно включить две линии и вести разговор одновременно с двумя абонентами.

Директор может не только услышать, как идут дела на производстве, но и увидеть с помощью видеотелефона ВИД-10, который также установлен у него на рабочем столе. Его аппарат - только часть комплексной системы внутренней видеотелефонной связи, состоящей из десяти аппаратов. Видеотелефоны могут принимать широковещательные передачи по 12 телевизионным каналам, сохраняя готовность принять вызов абонента.

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

И все-таки, "выходя" из кабинета, человек (в буквальном смысле слова) остается в нем. Ему помогает сделать это видеотелефон, о котором уже говорилось, а еще в большей степени система телеобработки данных "Экран-М".

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

Помощник исключительно многогранный. М-4030 как управляющий вычислительный комплекс используется в автоматизированных системах управления технологическими процессами, в автоматизированных системах управления предприятиями и отраслями, системах автоматизации проектирования, инженерных расчетах.

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

ТАМ ЖЕ
... попытка разнести органы управления оператора для гармонизации нервной и физической нагрузки.

ЧЕЛОВЕК И ПУЛЬТ
СЕВЕРИН ДРОБЯЗКО, кандидат технических наук; ИГОРЬ ГЕНИС, студент (Киев)

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

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

Цикл работы станка занимает 12 мин, что за восьмичасовую рабочую смену дает 40 циклов Каждый из них состоит из ряда операций, занимающих определенное время и требующих воздействия оператора на органы управления. Исходя из потребности рациональной загрузки мышечного аппарата, предлагается установить следующую систему движений оператора (рис.2). Поскольку органы управления первыми четырьмя подготовительными операциями, длящимися 3мин. (установка рулона и подвод режущих органов), выносятся на панели 1 и 2, то оператор работает в вертикальной позе (положения А и Б), поворачиваясь вправо и влево. При этих движениях наиболее загружены мышцы ног (четырех- и двуглавые мышцы бедра, мышцы голени), спины и прямые и косые мышцы брюшного пресса.

Так как органы управления наладочными операциями, длящимися 2мин., выносятся на панели 3 и 4, то при этом оператор работает сидя, поворачиваясь и нагибаясь в правую и левую стороны (положения В и Г). В этот период оператор должен также нажимать на педаль 5. При этом загружены мышцы ног: полуперепончатая, двуглавая и наружная мышцы бедра, икроножная мышца.

Операции управления основным процессом резки рулонного материала (4мин.) выполняются сидя. Органы управления и сигнализации находятся на пультах 6 и 7 (положение оператора Д). По сравнению с привычным пультом управления усиленно работает мускулатура шеи.

И наконец, операция управления выгрузкой материала и приведением механизма в исходное положение (3мин.). Оператор сначала работает в положении В и Г, воздействуя на органы управления панелей 3 и 4, а затем встает и, сгибаясь (Е), дотягивается до переключателей панели 8, переводящих механизмы в исходное положение. При этом работают мускулы рук (кисть, предплечье), спины (трапециевидная, широчайшая мышца), брюшного пресса, а при сгибании - поясничная мышца и прямая мышца живота.

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

Еще немного пустопорожнего ретро-футуризма:

ТЕХНИЧЕСКАЯ ЭСТЕТИКА 9/87

"СФИНКС" - РАДИОЭЛЕКТРОННОЕ ОСНАЩЕНИЕ ЖИЛИЩА БУДУЩЕГО
"Техническая эстетика" в #6 за этот год уже рассказывала о дизайнерской концепции и основных структурных и формообразующих идеях бытовой радиоэлектроники ближайшего будущего. Предлагаемая статья демонстрирует одно из возможных проектных решений домашнего телерадиокомплекса 2000 года.


Комплект блоков "СФИНКС". Верхний ряд, слева направо: сферические акустические колонки, экран для коллективного пользования. Средний ряд: плоские акустические колонки. дисплей 240*400. Нижний ряд: головные телефоны, ручной пульт с дисплеем, большой пульт с телефонной трубкой, диски, процессор с тремя блоками памяти.

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

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

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

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

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

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

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

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

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

Здесь происходит просмотр фильмов, видеопрограмм, телепередач, произведений искусства, других изображений и фонограмм, коллективные компьютерные игры, сюда же могут выводиться фрагменты "семейного альбома". Семья может устраивать - почему бы и нет?- дружеские телемосты или деловые встречи. В соответствии с тенденциями развития телевидения высокой четкости выбраны пропорции экрана - 3:5. Дополнительная информация (время, погода, справки, другие каналы и т.п.) может предъявляться на врезном кадре. Плоские экраны жидкокристаллического или газоплазменного типа уже сегодня активно разрабатываются за рубежом. В СССР освоение плоских экранов больших размеров ожидается в 1989-1995 годах.

Менее крупные дисплеи (240*400мм) больше всего подойдут для индивидуальных занятий и досуга, хотя смогут использоваться и двумя-тремя людьми одновременно. Экран и плоские колонки могут стоять на столе, в мебельных стеллажах, стенках, подвешиваться на стену или вертикальные элементы мебели. Углы наклона переменны. Для занятий дисплей может применяться без колонок, так как имеет небольшую встроенную акустику. Он легко совмещается с интерфейсом - пультом большой функциональной насыщенности и, таким образом, может работать как дисплей персонального компьютера (роль собственно ЭВМ выполняется здесь центральным квартирным процессором) для ученого, писателя, инженера, журналиста, архитектора, студента, школьника, а в свободное время использоваться как экран для просмотра ТВ-программы или видеозаписей, слайдов и т.п.

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

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

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

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

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

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

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

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


Центральный процессор


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


Малый ручной пульт с пристыкованным дисплеем. Под дисплеем контрольная акустика и микрофон. В правом нижнем углу - клавиши "большие-меньше".

Авторы проекта Д.А.АЗРИКАН, А.В.КОЛОТУШКИН, И.Н.ЛЫСЕНКО, Е.И.РУЗОВА, М.М.МИХЕЕВА. ВНИИТЭ
Фото В.П.КОСТЫЧЕВА

HTML И МАКРОСЫ


О ЧЕМ НЕ ЗНАЛ ШЕКСПИР / ВОКРУГ СВЕТА 4/77
Всем известно: Эльсинор - это место действия знаменитейшей пьесы Шекспира "Гамлет". Правда, читатель может не знать, что замок построен в 1585 году, а реальный Гамлет - или, правильнее, Амлет - был викингом и жил за несколько столетий до этого, но упрека Шекспиру здесь, разумеется, нет: право автора на некоторую вольность неоспоримо.
Эльсинор (Хельсингер) интересен еще и тем, что с ним связано любопытное, предание. Городок и замок стоят на берегу узкого пролива Эресунн, отделяющего датский остров Зеландию от Швеции. С XV по XIX век датчане взимали дань с каждого судна, проходившего по проливу, в виде определенного процента стоимости груза. Капитаны не могли пожаловаться на жестокие поборы: каждый сам имел возможность оценить свой груз "на глазок". Но беда, если они начинали жульничать. Датский король оставлял за собой право скупить любой товар по заявленной стоимости, поэтому, как только хитрец шкипер называл чрезмерно заниженную цифру, король - еще больший хитрец - тут же выкладывал деньги на бочку, и судно покидало знаменитый Эльсинор... с пустыми трюмами.

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

JavaScript, как язык программирования обладает следующими недостатками:
1. Зачем-то его сделали объектно-ориентированным. Им, что, было мало HTML-объектов?
2. На нем нельзя "просто взять и написать", надо искать объекты, которые "делают примерно то, что надо".
3. Зависимость от версий браузеров очень велика.
4. Количество "технологий", которые нужно прицепить к простейшему коду для его выкладывания в Сеть, зашкаливает.
5. Интернет-спецы по этому языку могут обсуждать только "кубические объекты в вакууме", но не конкретные вопросы.

Хотелось бы написать, мол, нам все это не надо, т.к. нашу простейшую задачу можно решить просто... но не напишу. Ибо даже для такой фигульки нам пришлось, как я показывал выше, городить еще тот огород. А, казалось бы, чего проще. Берем из Сети обычные файлы (формат HTTP - это просто набор типовых операций с сетевыми файлами) и считаем их HTML-текстами... По мере необходимости подгружаем картинки...

Единственное, что может нас радовать, вся наша программа визуализатора представляет из себя обычный текстовый файл и ее можно создать в обычном текстовом редакторе Notepad, не забыв только при сохранении файла на диске указать, что используется юникодовская кодировка (UTF8) - по прихоти движка моего форума (я просто не могу ввести в нем не-юникод-текст в окошке правки HTML).

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

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

Итак, мы отправляем наш кораблик в Эльсинор... Нет, не кораблик. Целый их караван. Если вы посмотрите на "код страницы", нажав соответствующую кнопочку браузера, то вместо, красивого HTML-документа увидите много-много текста. И этот текст явно разбит на очень много маленьких кусочков. Можно заметить, что большая часть кусочков заключена в угловые скобки, а остальные зажаты между ними. Текстовых корабликов, которые так и останутся текстовыми при показе HTML в нормальном виде, очень мало. Остальные должны как-то быть интерпретированы по пути каравана от автора к экрану вашего компьютера.

Перво-наперво ГАМЛЕТ должен помочь автору собрать правильный документ. Рассматривая авторский поток сознания как караван отдельных корабликлов, он некоторые кораблики пропускает (это авторский текст, текст, который предназначен для чтения пользователем), назовем их НАШИМИ. Остальные кораблики ГАМЛЕТ грабит. Поделим их на БОГАТЫЕ и БЕДНЫЕ. БОГАТЫЕ ГАМЛЕТ забирает себе, а БЕДНЫЕ, как благородный викинг загружает из собственной казны.


Самодельный "МОРСКОЙ БОЙ" из Приложения к ЮТ 9/85

БОГАТЫЕ попадают к наставнику ГАМЛЕТА - ЙОРИКУ, который добывает с них средства для пополнения БЕДНЫХ. Такая схема позволяет настраивать ГАМЛЕТА на каждый караван по-особому.


Я не Йорик, я - сервочереп из Вархаммер 40К

Прорвавшийся караван прибывает в богатую ЛАДОГУ (сетевой сервер).



Теперь в дело вступает ДЬЯК (браузер пользователя), требующий товаров для царского двора. Он посылает в ЛАДОГУ ГРАМОТУ (т.е. Интернет-запрос) и оттуда идет новый караван. Но тут возможна хитрость.



Караван может ДАТСКИЙ, от ГАМЛЕТА, или ШВЕДСКИМ - собранным хитрыми купцами прямо в ЛАДОГЕ из разных частей ДАТСКИХ караванов (но сейчас такое практически не встречается). Возможны и ВОРОВСКИЕ караваны, когда хитрый ДЬЯК требует что-то особое в обход обычной системы комплектования караванов. ДЬЯК тоже делит корабли на НАШИ, БЕДНЫЕ и БОГАТЫЕ, производя с ними те же махинации, что и ГАМЛЕТ. Только, вместо ЙОРИКА ему помогают записи ВЕЛЕСА. Смысловое отличие состоит в том, что экипажи БОГАТЫХ кораблей часто сами участвуют в перегрузке товара (JavaScript-ы). Наконец, особым способом работы является КРЕМЛЬ, когда весь обмен идет только через царские кладовые, сервер не доступен, ЛАДОГА только имитируются. Пусть этим занимаются местные аналоги ГАМЛЕТА и ЙОРИКА - ФАУСТ и ДИАВОЛ.



Насколько сложно имитировать работу этих персонажей ручными операциями? Ведь изначально нам дают только ДЬЯКА (наш браузер, умеющий выполнять HTML- и JavaScript-команды, основные из которых нам придется выучить и вставлять в текст, чтобы получить красивый документ). А программного доступа к ЛАДОГЕ (серверу) нам в нынешние времена не дают.

Итак, начнем с ГАМЛЕТА. В его роли обычно выступает обычный текстовый редактор. Автор честно запускает все свои кораблики, включая HTML и JavaScript. В простейшем случае все корабли - НАШИ, а все караваны ДАТСКИЕ. ЙОРИКА нет. ДЬЯКУ никто не мешает работать. ВЕЛЕСА нет. КРЕМЛЬ создается просто копированием окон ДЬЯКА -  кнопкой "Сохранить..."

В описанной несколькими постами выше ситуации - построения просмотрщика базы данных - все намного сложнее. Доступ к ЛАДОГЕ стал даже еще окольнее. ГАМЛЕТ усложнился настолько, что программрование его основной части я отложил до третьего тома заметок. Практически вся нагрузка легла на ВЕЛЕСА. Пойдем по списку перечисленных там технологий:
1. XMLHttpRequest - это ВОРОВСКОЙ способ доступа к ЛАДОГЕ. По сути "просмотрщик" - это довесок к ДЬЯКУ, позволяющий тому научиться языку ГЛЮКВЫ. Довесок сформирован в виде БОГАТОГО JavaScript корабля (т.е. скрипта) - флагмана ДАТСКОГО каравана. ДЬЯК его заглатывает и посылает ГРАМОТУ, требуя ВОРОВСКОГО каравана.
2. DataView - эта часть нужна т.к. ДЬЯК отказывается иметь дело с ВОРОВСКИМ караваном, разгружать его придется экипажу флагмана. Разгруженное отмечается ВЕЛЕСОМ.
3. data:image/gif;base64 - маленький кусочек груза, загружаемый в БЕДНЫЕ ДАТСКИЕ корабли, если нужно нарисовать картину.
4. base64 - иногда перед тем груз приходится переупаковывать.
5. Свойства объекта document - изначально в ДАТСКИЙ входит несколько совсем пустых БЕДНЫХ кораблей.
6. Самописный перекодировщик байтов из файла в кодировку utf-8 - перевод с ВОРОВСКОГО на ДАТСКИЙ.
7. Всякие style, onclick и прочая фигня - разные части груза. Сложность состоит в том, что после выгрузки на экран всех привезенных товаров, ДЬЯК не заканчивает своей работы, а ожидает новых приказаний пользователя. Поэтому наготове всегда стоит новый караван кораблей, готовый к повторению перегрузки. Экипаж флагмана бдит.
8. HTML-рамочки - формируемые ВЕЛЕСОМ на лету караваны БОГАТЫХ кораблей, с которым ДЬЯК может справиться самостоятельно.
9. GIF-формат - то, что делает ГАМЛЕТА столь сложным. ВОРОВСКОЙ караван идет на ЛАДОГУ кружным путем. Требуется специальная упаковка кораблей.

Зачем я кроме сложных технологий придумал сложные обозначения операций? Только для одного - возможности наглядного представления HTML-программы в виде таблицы. Чтобы было наглядно, что в какой клетке нужно менять.

По идее, для этих замен достаточно было бы всего двух "операторов": ЗАПОМНИТЬ (разгрузить БОГАТЫЙ корабль) и ВСПОМНИТЬ (загрузить БЕДНЫЙ). Единственная трудность - ВСПОМНИТЬ должен уметь вставлять в текст новые ЗАПОМНИТЬ и ВСПОМНИТЬ, которые будут обеспечивать новые обработчики событий (БЕДНЫЙ корабль вдруг оборачивается целым караваном, включающим новые БЕДНЫЕ и БОГАТЫЕ корабли). Однако, в JavaScript не бывает простого способа сделать простые вещи... (Если запутаетесь, сверяйтесь с текстом визуализатора).

ДАТСКИЙ караван просмотрщика базы:

<html><head>
БЕДНЫЙ КОРАБЛЬ "NOMA"
<meta http-equiv="Content-Type"; content="text/html; charset=utf-8"></head>
<body bgcolor=#ccac9c text=#000000>
<style type="text/css">.S1 { display: none }</style>
<style type="text/css">.S2 { }</style>
<hr><table border=0 width=100%><tr><td valign=top>
<span id=I1>
БЕДНЫЙ КОРАБЛЬ "TESTA"
</span>
</td><td align=right><table border=1><tr><td bgcolor=#9c8c7c>
<div id=I2>
БЕДНЫЙ КОРАБЛЬ "STOMA"
</div>
</td></tr></table></td></tr></table><hr>
<div id=I3>
БЕДНЫЙ КОРАБЛЬ "CODA"
</div>
<SCRIPT language=javascript>
... БОГАТЫЙ ФЛАГМАН ...
</SCRIPT>
</body></html>

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

О программах, которые могут делать подобное, см. ТЕМА #116, АБЗАЦ #1912 и ссылки в конце первого поста темы.

Зачем нам столько механизмов для работы с простыми файлами? Правильно, незачем. Достаточно глубокое проникновение в работу одного из звеньев может во многом компенсировать потребность разбираться с остальными. Например, можно иметь сложную базу данных, которую ВЕЛЕС будет перелопачивать на каждом ходу, а можно просто иметь много-много HTML-страниц на все случаи жизни с которой ДЬЯК справится самостоятельно. А пользователь даже не догадается, с чем он имеет дело.

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

ГАМЛЕТ. Если ГАМЛЕТ совсем прост (обычный текстовый редактор), нам придется писать на чистом языке ДЬЯКА (HTML и JavaScript). Это слишком муторно, поэтому снабдить ГАМЛЕТА простеньким макрогенератором сам бог велел. Хотя бы "ручным" - набором заготовок, которые можно копипастить в текст по месту. Т.е. нужен объемный ЙОРИК. Можно упростить входные тексты и за счет хранения заготовок в ЛАДОГЕ или у ВЕЛЕСА.

ЙОРИК. Естественное средство для добавления нетривиальных HTML. Для обычных можно хранить единые таблицы подстановки, например, у ВЕЛЕСА.  А для макросов, которые нужны только в одном HTML нужен именно способный запоминать макросы ЙОРИК. При "ручных" операциях это не имеет значения: нет разницы, копипастить из отдельного библиотечного файла или из того же самого HTML, раз нет экономии универсальности.

ЛАДОГА. К сожалению, лучшая часть ЛАДОГИ - формирование ШВЕДСКИХ караванов - для дешевых хостингов недоступна. А как бы было удобно иметь набор простых кораблей на сервере и комплектовать из них караваны по запросу пользователя, внося по ходу дела все правки и доделки. Остаются только ДАТСКИЕ и ВОРОВСКИЕ караваны, проходящие через ЛАДОГУ как есть.

ГРАМОТА. Запрос на получение каравана. Насколько просты запросы на ДАТСКИЕ и ШВЕДСКИЕ, настолько сложны они для ВОРОВСКИХ. Впрочем, на это я уже жаловался.

ДЬЯК. Заставить его делать что-то полезное, можно только загрузив один из БОГАТЫХ кораблей программой на JavaScript. Без нее, он будет способен только на показ самых простых HTML-документов. Т.о. как ни крути, а без некоторого программирования, все равно, не обойтись. Причем, программирования "удаленного", ведь этот БОГАТЫЙ корабль должен быть загружен еще ГАМЛЕТОМ.

ВЕЛЕС. C точки программирования он должен бы быть прост, являясь просто набором переменных для программы перегрузки кораблей, но это не так. Ведь, значением переменной может быть кусок программы, которая будет выполняться на лету, порождая определения новых переменных, которые тоже являются кусками программы.... Макросы, они такие.

Таким образом, кажется наиболее простым отстроить свой собственный КРЕМЛЬ, наплевав на все эти HTML-изыски, т.е. создать среду обмена кусками текста какими-нибудь доисторическими или даже офисными средствами околопрограммирования.

Для прикола - немного зауми из книги

Б.ХИГМАН
СРАВНИТЕЛЬНОЕ ИЗУЧЕНИЕ ЯЗЫКОВ ПРОГРАММИРОВАНИЯ
BRYAN HIGMAN
A COMPARATIVE STUDY OF PROGRAMMING LANGUAGES
Перевод с английского Л.В.Ухова М., "МИР", 1974

ГЛАВА 8. МАКРОГЕНЕРАТОР

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

Макрогенератор (Стрейчи, 1965) - это функциональный язык, предоставляющий пользователю возможность выразить в сокращенной форме многократное повторение определенных "узоров" [Под узорами понимаются произвольные тексты.- Прим. ред.], если даже узоры повторяются со значительными изменениями. Язык, в котором имеются описания узоров, мы будем называть языком узоров. Повторяемому узору с возможными изменениями может быть приписано общее имя следующим образом:

$DEF, <имя>, {{ <полное описание узора> }}; (А)

где символы < и > - металингвистические скобки в их общепринятом значении; сам Стрейчи использует эти скобки вместо символов {{ и }}. (Иногда кавычки в (А) оказываются необязательными и могут быть опущены, но они необходимы, если например, описание узора содержит символ ; ) [В исходном тексте книги используются символы "параграф" и "парные угловые кавычки", я их заменил на "доллар" и "двойные фигурные скобки" (не путать с одинарными).- G.] Переменные части описания узора обозначаются через ~1, ~2 (читать как "параметр #1" и т.д.), поэтому в сокращенной форме узор [То есть обращение к описанию узора.- Прим. ред.] имеет вид

$<имя>, <~1>, <~2> ...; (В)

где <~n> указывает строку, подставляемую вместо ~n с учетом конкретного использования. При практическом употреблении язык узоров, по-видимому, имеет вид машинного кода и, в каком-то смысле, аналогичен семантическим элементам Айронса; однако Макрогенератор не накладывает на узоры никаких ограничений, кроме запрета непарных кавычек. В конце этого раздела (п.8.4) Мы приведем примеры использования Макрогенератора при описании трех детских английских песенок; в первой из них демонстрируется элементарное использование языка.

С точки зрения функционального языка структура $Х, А, В, С; эквивалентна структуре Х(А, В, С) в общепринятых математических обозначениях, и, в случае когда X не есть DEF, ее можно интерпретировать как "функцию X от А, В и С". Важно понять, что (А) и (В) идентичны по синтаксической структуре, но отличаются семантически; мы будем одинаково называть их функциональными формами, но при необходимости первые будем называть определениями, а вторые - аббревиатурами. Функциональные формы могут содержать друг друга; в случае определений это обычно соответствует математической конструкции "... где... есть ...". Например

$A, B, $DEF, A, "Q~l";;

означает "A(В) где А(х) есть Qx".

8.1. СИНТАКСИС

Для наглядности запишем, следуя за Бэкусом, формальный синтаксис следующим образом:

Код:

1. <полный текст> ::= <текст> <символ конца>
2. <текст> ::= <элемент текста> | <элемент текста> <текст>
3. <элемент текста> ::= <цитата> | <функция> | <открытый текст>
4. <цитата> ::= {{ <текст> }}
Это определение несколько ограничено (см. ниже)
5. <функция> ::= <начало функции> <остаток функции>
6. <начало функции> ::= $ <элемент>
7. <остаток функции> :: = ; | , <элемент> <остаток функции>
8. <элемент> ::= <атом> | <атом> <элемент>
9. <атом> ::= <цитата> | <функция> | <простой текст>
10. <открытый текст> ::= <символ> | <символ> <открытый текст>
11. <простой текст> ::= <простой символ> | <простой символ> <простой текст>
12. <символ> ::= <любой символ, за исключением $, {{ или }} >
13. <простой символ> ::= <любой <символ>, за исключением , или ; >
14. <символ конца> ::= }}

Хотя эти правила подстановки достаточны для того, чтобы проанализировать сообщение на рассматриваемом языке, они не гарантируют семантическую осмысленность сообщения; в частности, не подчеркивается различие между определениями и аббревиатурами, не определяется синтаксис параметров. Правила подстановки 1, 2 и 3 равноценны утверждению, что полный текст состоит из строки открытых текстов, цитат и функциональных форм, оканчивающейся символом конца. Правила 4, 12 и 13 указывают на то, что между открывающими и закрывающими кавычками всегда можно установить соответствие и что закрывающая кавычка, для которой нет соответствующей ей открывающей, может появиться лишь при использовании правила 14. Так как правила 2, 3 и 4 рекурсивны, цитаты могут содержать вставленные цитаты, и поэтому конец сообщения обнаруживается по "отрицательной глубине вложенности по цитатам". Правила 5, 6 и 7 определяют функцию так:

$ <элемент>;

или

$ <элемент>, ... <элемент>;

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

8.2. СЕМАНТИКА

Начнем с того, что рассмотрим семантику неформально. Семантически БЕСПОЛЕЗНО писать определение, которое не используется, или задавать параметры, без которых можно обойтись (за исключением определений where [where - где]), но совершенно бессмысленно писать функциональные формы, в которых не определен первый (элемент) или не согласовано число параметров. Если первое только неразумно, то второе, хотя и удовлетворяет синтаксическим правилам подстановки, повлечет передачу управления на процедуры обработки ошибок.

Интерпретация строки <полный текст> производится в процессе последовательного выбора элементов текста. Строки <открытый текст> и <цитата> копируются в результирующий текст полностью в том виде, как они записаны. При считывании цитаты заключающие ее кавычки опускаются, но сохраняются кавычки, находящиеся внутри цитаты; то же самое относится и к запятым, знаку $ или любому другому символу, который может потребовать специальной интерпретации. Интерпретация функциональной формы происходит сразу после ее выбора; при изготовлении промежуточной копии этой формы каждый (элемент) копируется в соответствии с теми же правилами. Из этого следует возможность рекурсивной интерпретации. После завершения копирования ищется определение первого <элемента> (в соответствующей интерпретации, если скопированная форма отличается от первоначальной), ЭТОТ ПОИСК НАЧИНАЕТСЯ С ОПРЕДЕЛЕНИЙ, ВЫБРАННЫХ ПОСЛЕДНИМИ. Если первый <элемент> не является словом DEF или одной из "машинных макрокоманд", описываемых ниже, то второй <элемент> рассматриваемого определения служит основой конечной копии; копирование этого <элемента> происходит в СООТВЕТСТВИИ С ОБЫЧНЫМИ ПРАВИЛАМИ (при необходимости и с рекурсивной интерпретацией), но с учетом дополнительного правила о БУКВАЛЬНОЙ ЗАМЕНЕ ПАРАМЕТРОВ выражениями, взятыми из соответствующих <элементов> промежуточной копии. Замена производится буквально, так как выражения уже прошли стадию интерпретации. Если первый <элемент> - слово DEF, то функциональная форма интерпретируется с добавлением ее второго и третьего элементов в список определений. При завершении интерпретации промежуточная копия вместе со всеми определениями, появившимися в результате интерпретации ее параметров, забывается. (Но сохраняются все определения, связанные с конечной копией).

Формализация этой семантики связана с рядом интересных вопросов. Становится ясно, что строки определений на разных стадиях обработки следует рассматривать как строки, записанные на разных языках! Мы будем употреблять компромиссную систему обозначений: в системе Иверсона-Беркхардта для синтаксических элементов мы сохраним скобки Бэкуса, а для семантических элементов мы будем употреблять квадратные скобки. Мы предполагаем наличие стекового списка строк и пользуемся сокращением [ * ] для обозначения сочленения, т.е. присоединения текущего символа к верхней строке стека. Тогда формальную семантику в довольно общих чертах (причем кажется невозможным произвести ее дальнейшую детализацию) можно записать следующим образом:

Код:

<текст> :: = $0{ <l>[*] | <n>[*] | <c>[*] | <внешняя цитата> | <функция> } { <символ конца> [стоп] }
<внешняя цитата> ::= {{ $0{ <l>[*] | <n>[*] | <c>[*] | $[*] | <внутренняя цитата> } }} [*]
<внутренняя цитата> ::= [*]$0{ <l>[*] | <n>[*] | <c>[*] | $[*] | <внутренняя цитата> } }} [*]
<функция> ::= $[стек] <элемент> $0{ ,[заменить] <элемент> };[применить]
<элемент> ::= $0{ <l>[*] | <n>[*] | <внешняя цитата> | <функция> }

Здесь <c> - это "запятая или точка с запятой", <n> - "цифра", <l> - любой из допустимых символов, кроме только что перечисленных, $ и кавычек. При выборе символов из классов <l>, <n> или <c> происходит их копирование [ * ]; процесс продолжается до тех пор, пока не выбирается последний символ строки, в противном случае исследуется возможность применения определений цитаты, функции или символа конца. Различие между <внешней цитатой> и <внутренней цитатой> состоит лишь в том, что у внешней цитаты отсутствует знак копирования после первого и последнего символов цитаты. Сразу же после обнаружения знака функции производится стековый сдвиг текущего списка и заводится новый список - промежуточная копия. При выполнении этой операции запятые, разделяющие элементы, нужно заменить на некоторый новый символ, так как запятые, не разделяющие элементов, могут обрабатываться без учета заключающих их кавычек. При выборе точки с запятой, не входящей в текущий элемент (элемент не может начинаться с точки с запятой), выполняется операция "применить".

Операция "применить" предусматривает выбор промежуточной копии из стекового списка; в результате становится доступной предыдущая строка, и к ней добавляется результат интерпретации промежуточной копии. Здесь можно отметить, что наша формализация семантики недостаточно детализирована, но более подробная разработка глобального формализма затруднена (хотя, вероятно, все-таки возможна) по трем причинам. (1) Большинство определений было введено динамически, и поэтому мы сталкиваемся с ситуацией, аналогичной ситуации с "описаниями языка АЛГОЛ". (2) Машинные макрокоманды, DEF и некоторые другие элементы требуют специальной обработки. Это, в частности, вытекает из того, что (3) синтаксис строк определений отличается от синтаксиса сообщения при вводе; это верно по крайней мере в отношении символа ~ .

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

Код:

1. <открытый текст> ::= $0{ <элемент текста> | <внутренний символ> [ошибка] } }} [стоп]

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

Код:

2. <элемент текста> ::= {{ <цитата> }} | $ <функция> | <внешний символ, но не }}>[*]
3. <функция> :: = [стек] <элемент> $0{ , [заменить] <элемент> } ; [заменить] [применить]
4. <цитата> ::= $0{ {{ [*] <цитата> }}[*] | <не }}>[*] }
5. <элемент> ::= $0{ {{ <цитата> }} | $ <функция> | <не , или ; >[*]

Формулы переупорядочены в интересах эффективности; формула (2) означает "если не открывающая кавычка?, не $?, не внутренний символ? и не закрывающая кавычка?, то копировать". Одним из следствий этого является исключение непарных внутренних и внешних кавычек. Запятая всюду будет заменяться на внутренний символ #. Добавим следующие формулы:

Код:

6. <описание> ::= $0{ ~{ <n>[транс] <параметр> | [ошибка] } | <элемент текста> } #[вытолкнуть]
7. <параметр> ::= $0{ <любой символ, за исключением #>[*]} #[вытолкнуть]

Обращение к этим правилам производится при выполнении процедуры [применить]. Формула (6) означает "искать подстроку, начинающуюся с ~ , или искать элемент текста; в первом случае далее должна следовать цифра, отсутствие цифры означало бы ошибку; если цифра обнаружена, то n-й элемент промежуточной копии передается на ввод (отодвигая на одну позицию переданные ранее элементы ввода)". Следующий далее (параметр) обрабатывается в соответствии с формулой (7), ТАК КАК в формуле (6) имеется обращение к [транс]; в первоначальной строке этого не было!

8.3. НЕСКОЛЬКО ДОПОЛНИТЕЛЬНЫХ ЗАМЕЧАНИЙ О ЯЗЫКЕ

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

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

(2) Функции S, P, W являются соответственно функциями над целыми числами: "следующее", "предыдущее", "слово".

(3) Введение "переменных функций", имена которых зависят от параметра, например $VERSES~1 .

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

$~1, $DEF, ~1, {{ ... }};, $DEF, X, {{...}};;

порождает различные действия в зависимости от того, является ли параметр ~1 именем X или нет.

(5) Различные особенности в связи с управлением форматом.

Кроме определения DEF, полный макрогенератор содержит ряд других "машинных макрокоманд"; все они были добавлены в последнее время для ликвидации обнаруженных узких мест языка. Функция МОДИФИЦИРОВАТЬ исправляет имеющееся определение, причем новое определение вводится либо временно, либо навсегда (ценой дополнительной затраты памяти). Функция $VAL,X; позволяет скопировать определяющую X строку без интерпретации; в простых случаях, когда интерпретация не обязательна, это эквивалентно $X; . Введена также функция для выполнения арифметических операций и преобразования цифровых строк. В качестве примера применения функций МОДИФИЦИРОВАТЬ возьмем функциональную форму $AORB; , определенную с помощью вспомогательной функции Q [начиная с этого места вместо {{ и }} используются < и > .- G.]:

$DEF, Q, А; $ DEF, AORB, <$$Q;;>, $ DEF, A, <A
$МОДИФИЦИРОВАТЬ, Q, В;>;, $DEF, В, <В $МОДИФИЦИРОВАТЬ, Q, А;>;;

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

<...(...>...<...)...>

может оказаться корректной и осмысленной при независимой семантической интерпретации глубины этих двух видов скобок. Один из серьезных минусов Макрогенератора в его полной форме заключается, по-видимому, в том, что в случае, когда язык узоров содержит символы кавычек, не представляется возможным выделить с помощью функциональной формы какую-либо часть содержимого выходной цитаты. Для обеспечения этой возможности необходимо либо допустить употребление дополнительных мета-кавычек, либо ввести символ, являющийся, как автор показывал в другой работе (Хигман, 1963), обязательной частью любого самоприменимого языка, а именно символ c (читать "спецсимвол"), который заключает непосредственно следующий за ним символ в явные "суперкавычки", если даже этот символ тоже является спецсимволом.

8.4. ПРИМЕРЫ

Ниже приводится формальная запись примеров, на которые мы уже ссылались [Для наглядности первый пример дается в русском переводе.- Прим. ред.]. При подготовке примеров использовался Флексорайтер (пишущая машинка, снабженная устройством пробивки и чтения бумажной ленты), полученная лента была введена в вычислительную машину, с ленты результатов на Флексорайтере была получена копия, приводимая на следующих двух страницах. (Заметим: (1) отсутствие на печати символов перевода строки и возврата каретки и (2) использование системного обозначения ***Z для указания конца ленты).

ИНФОРМАЦИЯ ДЛЯ ВВОДА В ВЫЧИСЛИТЕЛЬНУЮ МАШИНУ



РЕШЕНИЕ, ПОЛУЧЕННОЕ НА ВЫЧИСЛИТЕЛЬНОЙ МАШИНЕ

1. У старого Макдональда на ферме,
Водились на ферме цыплята,
То здесь цып-цып, то там цып-цып,
Здесь цып, там цып, и везде цып-цып,
У старого Макдональда на ферме.

У старого Макдональда на ферме,
Водились на ферме утята,
То здесь кряк-кряк, то там кряк-кряк,
Здесь кряк, там кряк, и везде кряк-кряк,
У старого Макдональда на ферме.

У старого Макдональда на ферме,
Водились на ферме индюшки,
То здесь гобл-гобл, то там гобл-гобл,
Здесь гобл, там гобл, и везде гобл-гобл,
У старого Макдональда на ферме.
И т.д., и т.д.

2.
The farmer wants a wife
The farmer wants a wife
Hey do diddledy ho
The farmer wants a wife

The wife wants a child
The wife wants a child
Hey do diddledy ho
The wife wants a child

The child wants a dog
The child wants a dog
Hey do diddledy ho
The child wants a dog

We all pat the dog
We all pat the dog
Hey do diddledy ho
We all pat the dog

3.
One man went to mow, went to mow a meadow,
One man and his dog, went to mow a meadow.

Two men went to mow, went to mow a meadow,
Two men,
One man and his dog, went to mow a meadow.

Three men went to mow, went to mow a meadow,
Three men, Two men,
One man and his dog, went to mow a meadow.

Four men went to mow, went to mow a meadow,
Four men, Three men, Two men,
One man and his dog, went to mow a meadow.

Five men went to mow, went to mow a meadow, Five men, Four men, Three men, Two men,
One man and his dog, went to mow a meadow.

Six men went to mow, went to mow a meadow,
Six men,
Five men, Four men, Three men, Two men,
One man and his dog, went to mow a meadow.

Seven men went to mow, went to mow a meadow,
Seven men, Six men,
Five men, Four men, Three men, Two men,
One man and his dog, went to mow a meadow.

Eight men went to mow, went to mow a meadow,
Eight men, Seven men, Six men,
Five men, Four men, Three men, Two men,
One man and his dog, went to mow a meadow.

Nine men went to mow, went to mow a meadow,
Nine men, Eight men, Seven men, Six men,
Five men, Four men, Three men, Two men,
One man and his dog, went to mow a meadow!

4. ВТОРОЙ СПОСОБ

One man went to mow, went to mow a meadow
One man and his dog, went to mow a meadow

Two men went to mow, went to mow a meadow
Two men
One man and his dog, went to mow a meadow

Three men went to mow, went to mow a meadow
Three men
Two men
One man and his dog, went to mow a meadow

Four men went to mow, went to mow a meadow
Four men
Three men
Two men
One man and his dog, went to mow a meadow

Five men went to mow, went to mow a meadow
Five men
Four men
Three men
Two men
One man and his dog, went to mow a meadow

Six men went to mow, went to mow a meadow
Six men
Five men
Four men
Three men
Two men
One man and his dog, went to mow a meadow

Seven men went to mow, went to mow a meadow
Seven men
Six men
Five men
Four men
Three men
Two men
One man and his dog, went to mow a meadow

Eight men went to mow, went to mow a meadow
Eight men
Seven men
Six men
Five men
Four men
Three men
Two men
One man and his dog, went to mow a meadow

Nine men went to mow, went to mow a meadow
Nine men
Eight men
etc.

***

Вот как можно быстро перейти от нежелания многажды набивать припевы детских песенок к вселенским проблемам программирования (ТЕМА #129, АБЗАЦ #2248). Не советую вникать во все эти тонкости синтаксиса и семантики, только, если вы не хотите написать свой макрогенератор в качестве упражнения.- G.

Еще один способ играть без компьютера.

ЗОНКЕ АРЕНС
КАК ДЕЛАТЬ ПОЛЕЗНЫЕ ЗАМЕТКИ
Эффективная система организации идей по методу Zettelkasten
2022
PDF, 1.96Мб



Эта и следующая картинка - из Википедии.

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

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

"Некоторое время Луман... делал записи на полях или распределял их по темам. А затем он понял, что это никуда не ведет... написал каждую заметку на отдельном маленьком листочке бумаги, поставил номер в углу и собрал их все в одном месте: в ящике для заметок... Ящик стал его ПАРТНЕРОМ ПО ДИАЛОГУ, главным генератором идей и двигателем производительности... И с ящиком было интересно работать - потому что он действительно работал".

Итак:

"ЯЩИК ДЛЯ ЗАМЕТОК
Строго говоря, у Лумана их было два: библиографический, который содержал ссылки и краткие заметки о содержании литературы, и основной, в котором он собирал и генерировал свои идеи, большей частью в ответ на прочитанное. Записи делались на учетных карточках и хранились в деревянных ящиках.
"Всякий раз, когда он что-то читал, то записывал библиографическую информацию на одной стороне карточки и делал краткие заметки о содержании на другой. Эти записи попадали в библиографический ящик.
"На втором этапе Луман просматривал краткие заметки и думал об их значении в отношении собственных размышлений и записей. Затем он обращался к основному ящику для заметок и записывал свои идеи, комментарии и мысли на новых листочках бумаги, используя по одному для каждой и ограничиваясь одной стороной листа, чтобы их можно было читать, не вынимая из коробки. Обычно он делал их достаточно краткими, чтобы уместить одну идею на одном листке, но иногда добавлял дополнительную заметку, чтобы развить мысль.
"Обычно Луман писал свои заметки, ориентируясь на уже существующие записи в ящике. И хотя примечания к литературе были краткими, он писал их с тщательностью, не сильно отличающейся от его стиля в финальной рукописи: полными предложениями и с прямыми ссылками на литературу, из которой черпал материалы. Чаще всего новая заметка следовала непосредственно за другой и становилась частью длинной цепочки записей. Затем он добавлял ссылки на заметки, находящиеся где-нибудь в другом месте в ящике, одни из них были расположены поблизости, другие - в совершенно других областях и контекстах. Одни были связаны напрямую и больше похожи на комментарии, другие содержали не столь очевидные связи. Редко записка оставалась изолированной".

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

"Если новая заметка имела отношение к уже существующей заметке или напрямую относилась к ней, например комментарий, исправление или добавление, Луман ставил ее непосредственно после предыдущей заметки. Если бы существующая карточка имела номер 22, новая карточка стала бы 23. Если 23 уже существовала, он называл новую заметку 22a. Чередуя числа и буквы, с косыми чертами и запятыми между ними, он мог делать столько цепочек-разветвлений мыслей, сколько ему хотелось. Например, заметка о причинно-следственной связи и теории систем имела номер 21/3d7a7 после заметки с номером 21/3d7a6".


Косые черты нужны для добавления "сыновей".

Инструкция (приведу ее целиком):
"1. Делайте повседневные заметки. Всегда имейте под рукой что-нибудь, чтобы сделать запись и не упустить ни одну идею, которая приходит вам на ум. Не беспокойтесь слишком сильно о том, как и на чем вы пишете. Это мимолетные заметки, просто напоминания о том, что проскользнуло у вас в голове. Вам не нужно сильно на них отвлекаться. Поместите их в одно место, которое определили под свой ящик для входящих заметок, и обработайте их позже. Обычно у меня с собой простой блокнот, но вполне сойдут салфетки и даже чеки, если под рукой больше ничего нет. Иногда я делаю диктофонную запись на телефоне. Если же ваши мысли уже сформировались и у вас есть время, можете пропустить этот шаг и записать идею в виде постоянной заметки для своего ящика.
"2. Делайте записи о литературе. Каждый раз, когда вы что-то читаете, сделайте заметку о содержании. Запишите то, что вы не хотите забыть или что, по вашему мнению, могли бы использовать в собственных изысканиях или письменных работах. Делайте это очень кратко, будьте предельно избирательны и пишите своими словами. Будьте особенно внимательны с цитатами - не пытайтесь просто списать их, иначе можете пропустить этап понимания их смысла. Храните эти записи вместе с библиографическими данными в одном месте - вашей справочной картотеке.
"3. Создавайте постоянные заметки. А теперь обратитесь к своему ящику. Просмотрите заметки, которые вы сделали на первом или втором шаге (в идеале просматривайте их раз в день, прежде чем забудете, что имели в виду), и подумайте, как они соотносятся с вашими исследованиями, размышлениями или интересами. Вскоре это можно будет сделать, заглянув в ящик: в любом случае он содержит только то, что вас интересует. Идея не в том, чтобы собирать, а в том, чтобы развивать идеи, аргументы и дискуссии. Новая информация противоречит, исправляет, поддерживает или дополняет то, что у вас уже есть (в вашем ящике или в вашей голове)? Можете ли вы объединить идеи, чтобы создать что-то новое? Какие вопросы они вызывают? Напишите ровно одну заметку для каждой идеи так, как если бы вы писали для кого-то другого: используйте полные предложения, раскрывайте свои источники, делайте ссылки и старайтесь быть максимально точными, ясными и краткими. Выбросьте мимолетные заметки из шага 1 и поместите литературные заметки из шага 2 в свою справочную картотеку. Теперь о них можно забыть. Все, что имеет значение, уже попало в ящик для заметок.
"4. Теперь добавьте новые постоянные заметки в свой ящик: а) поместите каждую из них позади одной или нескольких связанных заметок (с помощью программы вы можете поместить одну заметку "за" несколькими сразу; если используете ручку и бумагу, как Луман, вам придется решить, куда она лучше всего подходит, и вручную добавить ссылки на другие заметки). Посмотрите, к какой заметке напрямую относится новая, или, если она еще не связана ни с одной другой, просто поместите ее за последней; б) добавьте ссылки на связанные заметки; в) убедитесь, что вы сможете найти эту заметку позже, сделав ссылку на нее либо в своем указателе, либо в заметке, которую вы используете в качестве точки входа в обсуждение или тему и которая есть в указателе.
"5. Разрабатывайте свои темы и исследовательские проекты снизу вверх внутри системы. Посмотрите, что есть и чего не хватает, какие вопросы возникают. Читайте больше, чтобы поставить под сомнение и укрепить аргументы, а также изменить и расширить доводы в соответствии с новой информацией, которая к вам попала. Делайте больше заметок, развивайте идеи и смотрите, куда они вас приведут. Просто следуйте за своими интересами и всегда выбирайте путь, который обещает больше идей. Опирайтесь на то, что у вас уже есть. Даже если ваш ящик для заметок еще пуст, вы все равно не остаетесь один на один с чистым листом - у вас уже есть теории, которые нужно проверить, мнения, с которыми можно поспорить, и вопросы, на которые нужно ответить. Не проводите мозговой штурм в поисках темы. Вместо этого загляните в ящик для заметок, чтобы увидеть, как развивались цепочки мыслей и где идеи объединились в группы. Не цепляйтесь за одну идею, если набирает силу другая, более многообещающая. Чем больше интереса вы проявите к теме, тем больше вы будете читать и думать о ней, тем больше заметок вы соберете и тем больше вероятность, что у вас появятся новые вопросы. Возможно, это будет все еще то, что интересовало с самого начала, но более вероятно, что ваши интересы изменятся - так и рождаются новые идеи.
"6. Через некоторое время у вас будет достаточно много идей, чтобы решить, на какую тему писать. Теперь она будет основана на том, что у вас уже есть, а не на неясных предположениях о том, что может вам дать литература, которую вы собирались читать. Просмотрите связанные с этой темой заметки и соберите их всех по порядку (большинство уже будет иметь некоторый порядок), скопируйте их в планировщик [Или, если вы используете ручку и бумагу, просто перемешайте заметки на рабочем столе] и расставьте как вам надо. Смотрите, чего не хватает, а что лишнее. Не ждите, пока соберете все вместе. Скорее развивайте свои идеи и после дайте себе время еще почитать и создать новые заметки, чтобы улучшить аргументы и структуру.
"7. Превратите свои заметки в черновик. Но не просто скопируйте их в рукопись. Преобразуйте их в связный текст и включите в контекст вашего аргумента, одновременно выстраивая сам аргумент из заметок. Выявите пробелы в своих доводах, заполните их или измените аргумент.
"8. Отредактируйте и вычитайте рукопись. Похлопайте себя по плечу и перейдите к следующей".

Основная прелесть - как и в ГЛЮКВЕ - любой кусочек работы может быть сделан в любое удобное время. Можно переключиться на другой проект и вернуться, когда соскучишься по старому. Нет проблемы в том, что что для начала выполнения некоторого кусочка надо обязательно завершить все предыдущие.

Далее, мне показалось важным разделение заметок по категориям:
"1. Повседневные заметки, которые служат лишь напоминанием об информации; их можно писать любым способом, они попадут в корзину в течение дня или двух.
"2. Постоянные заметки, которые никогда не будут выброшены и содержат в себе необходимую информацию в постоянно доступной форме. Они всегда хранятся в одном и том же формате в одном и том же месте - либо в справочной системе, либо, как если бы текст на них уже был готов для печати, в ящике для заметок.
"3. Заметки для проекта, относящиеся только к одному конкретному проекту. Они хранятся в отдельной папке для конкретного проекта и могут быть забыты или заархивированы после его завершения.
"Только если заметки этих трех категорий будут храниться отдельно, можно будет собрать критическую массу идей внутри ящика. Одна из основных причин, когда не ладится ни с письмом, ни с публикациями, заключается в путанице этих категорий... порог для записи идеи должен быть как можно ниже, но не менее важно проработать эти идеи в течение дня или двух. Хорошим признаком того, что [повседневная] заметка слишком долго оставалась необработанной, является то, что вы перестали понимать, что имели в виду, или она начала казаться вам банальной. В первом случае вы забыли, о чем заметка должна была вам напоминать. Во втором - вы забыли контекст, который придавал ей значение.".
[Не забываем про "4-ю категорию" - библиографические карточки].

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

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

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

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

Что-то это мне напоминает:

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

ТЕНЬ ОТЦА ГАМЛЕТА
Возвращаюсь к STARGRUNT II. У меня есть скан книги правил на английском и файл с текстом (который я уже выкладывал выше). Вообще, я всегда распознаю сканы книг перед переводом. Это дает видимость успешного хода работы. Ничего особо умного не делаешь, но, вроде, проект движется.

По принятым правилам игры на этом этапе я не могу писать программы и/или использовать умные офисы. Поэтому полный текст для игры не годится. Прокручивать его в простом редакторе - чтобы найти /поправить нужное (т.е. выполнить ЧАСТНЫЕ операции) - ужасно неудобно.

Остается одно. Разбить его на много маленьких текстовых файлов. Занятие тоже совершенно не интеллектуальное.

Что-то вроде:
- вырезать заголовок первого параграфа старого (большого) файла;
- создать файл с именем из номера и заголовка;
- поместить в него заголовок;
- перенести из старого файла в новый параграф.
Повторить пару сотен раз.

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

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

Где-то в процессе игра начала становиться интересной. Параграфы превратились в "солдатиков", которых захотелось расставить по некому умозрительному многомерному полю боя: тут танки, тут рукопашная, там взрывы бомб... Что может для такой игры предложить Windows?
***

Я встречал пользователей, размещавших иконки документов на определенные места фоновой картинки экрана. По старому рецепту "Родительской" настольной игры ТЕМА #79, АБЗАЦ #940. Но для этого надо куда-то девать привычные рабочие иконки и иметь экран значительных размеров. В некоторых старых версиях Windows можно было "рисовать" и внутри окон директорий, но сейчас я такого не встречаю.

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



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

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



Например, для начала попытаться создать структуру папок для главной ПОСЛЕДОВАТЕЛЬНОСТИ игры, создав в ней ссылки на файлы нужных параграфов.

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

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

Основные "ходы игры" - консольные команды dir и find, позволяющие получить список файлов с подходящими именами или содержимым. Для сложных случаев - команда for, позволяющая перебрать список файлов или (с ключом /f) строк файла).

Например, начав с главной ПОСЛЕДОВАТЕЛЬНОСТИ, я сразу обнаружил выделение авторами двух терминов ACTION и ACTIVATION, которые предлагается очень хорошо уяснить.

find /I "action" 0??.*.txt >f1.txt

даст в промежуточном файле f1 достаточно замусоренный список из имен файлов, найденных строк и пробелов. (Тут как с досовскими BASIC-ами, все везде одинаково, но конкретно у вас это будет чуть-чуть иначе; в данном случае, 0??.*.txt - это МОЙ формат номеров, см. рисунок, у вас может быть другой; а f1.txt - МОЙ временный файл; искать, очевидно, вы будете не action, а другое слово).

Для "очистки" временного файла понадобится более сложная команда (да-да, с поправкой на ваши настройки - напильником; главное, для возможности ввода имени переменной в воскл.знаках надо запустить консоль с ключом /v - cmd /v)

for /f "tokens=1*" %i in (f1.txt) do if %i==---------- (
set SS=%j
) else (
if NOT "!SS!"=="*" echo !SS! >>f2.txt
set SS=*
)

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

Далее следует сравнить файлы, полученные для action и activation. Удобнее всего слить их в один, отсортировать (командой sort) и еще одной командой-программой for выбрать все двойные строчки. Если не писать команды, придется файлы (результаты find) перебирать руками. Возможно, это и не так и затратно, если учесть, что соответствующие параграфы придется читать/уяснять. Правда, наверное, для такой игры и компьютер не особо нужен, можно и распечаткой обойтись, ведя записи прямо на полях или в записной книжке.
***

Есть ли простейший набор команд, реализуемый почти без программирования? Есть, называется Реляционная Алгебра. Всего пять операций, предназначенных для преобразования таблиц Базы Данных. А папка с однотипно поименованными файлами (ссылками), как раз, и является такой "таблицей".

Первая операция "объединение" есть в ассортименте. Просто copy (с ключом /y, для затирания повторов). Копируем две директории в третью - и готово.

mkdir "ACTION ACTIVATION"
copy ACTION\* "ACTION ACTIVATION"
copy /y ACTIVATION\* "ACTION ACTIVATION"

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

del /q "ACTION ACTIVATION\*"
copy ACTION\* "ACTION ACTIVATION"
for %i in (ACTIVATION\*) do del /q "ACTION ACTIVATION\%~nxi"

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

del /q "ACTION ACTIVATION\*"
for %i in (ACTIVATION\*ACTION*) do copy "%i" "ACTION ACTIVATION"

Очевидно, что это удобно, если мы будем ставить в имена какие-то пометки, а потом сами их искать.

Четвертая операция "проекция" (убрать из имен лишние "поля") реализуется похоже - парой  for - move. При укорачивании имен (ссылок) некоторые файлы могут затереться.  В моей "базе данных" используется всего два явных "поля" - номер и заголовок, и третье - неявное - ссылка на текстовый файл. Откуда могут взяться лишние? Они могут появится в результате пятой операции.

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

Зачем это нужно?
Ну, как бы, инженеры Баз Данных сошлись на том, что большинство "запросов" к базе может быть сведено к следующей форме (языка SQL):

SELECT параметры проекции
FROM произведение нужных таблиц
WHERE условия селекции

(См. выше ГЛЮК).

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

Вообще, чем наш SQL отличается от канонического?

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

2. Содержимое файлов тоже имеет значение (то самое третье поле записи-ссылки!). Например, ища выше слова ACTION и ACTIVATION, я использовал find. Значит, полезно будет иметь разновидность операции селекции с поиском в тексте файлов.

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

Конечно, такие команды не должны заменять обычные операции, но быть дополнительными.

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

Для удобства имеет смысл добавить к нашим операциям еще две: преобразования списка файлов в текстовый файл (командой dir /b) и обратную - извлечение ссылок из текстового списка (поиск ссылок по имени должна осуществлять, как выше, операция проекции).

Например, из временного файла f2.txt (см. выше) выдрать список ссылок (в папке: UNIVERSAL - полный набор ссылок)

for /f "tokens=*" %i in (f2.txt) do copy "UNIVERSAL\%i.lnk" ACTIVATION

***

Другой вариант структуризации - создание HTML-оболочки (вручную с добавлением к текстам параграфов необходимый обвес в угловых скобках). Тут мы обнаруживаем, что в современном браузере обитает аналог досовских BASIC-ов - это консоль. Выглядит, по крайней мере, похоже - большой экран для показа результатов и - внизу - пара строк ввода команд и диагностики. Загрузив в браузер пустой HTML-шаблон, мы можем заполнять его дыры (грузить БЕДНЫЕ корабли), командами, выполняемыми в браузерной консоли. Даже с картинкам.

К сожалению, язык этой консоли - тот же убогий JavaScript, перегруженный функциями самоанализа и предназначенный для отладки браузерных ошибок. Засунуть в шаблон данные из файла мы еще как-то можем, использовав трюк, описанный в начале темы. А вот записать на диск - никак, разве через Win-карман или сохранив html-файл целиком. (В свежих версиях "как", но слишком много условностей). Последнее, видимо удобнее, т.к. текст, введенный руками в html-формы и командами консоли в html-объекты, сохраняется при сохранении файла.


Обратите внимание - дурацкое следование JavaScript объектной модели HTML-документа порождает команды-монстры (цепочка children[] изображает спуск по дереву объектов).

В принципе, операция ЗАПОМНИТЬ - это выбор в текущем HTML-файле некоего "фрагмента", а ВСПОМНИТЬ - запись его "значения" в новое место. Руками. Как пишут, в середине XX века в шанхайском порту не было ни одного подъемного крана. Только тысячи кули...
***

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

Проблема не только в том, что для написания правильных команд на таких кривых языках надо читать учебник (а лучше - иметь под рукой мастера). Она еще и в том, что она, будучи, по сути, простой, выходит за пределы обычных шаблонов программирования (см. ТЕМА #18, АБЗАЦ #74 и далее).

По идее, задача создания базы данных, с которой можно вести интересный диалог, давно уже многократно решена (см. книги Растригина и Чачко). Но все эти решения были отброшены, т.к. были лишены самого главного - смыслового наполнения. Машину научили говорить, но говорить, ввиду скоропостижной кончины  кибернетики, стало не о чем.