| Предыдущая глава |
↓ Содержание ↓
↑ Свернуть ↑
| Следующая глава |
получен (вставлен в А2) в виде текста спецоперацией форматного выражения ** и
записан (удалён из А2) с помощью // которые сделаны для отладки, но уж ладно,
пусть будут — мало ли для чего вдруг понадобятся.)
Каждый элемент анализирующего шаблона, сопоставляясь со своим фрагментом
строки, фиксирует в протоколе — с чем именно сопоставился. (Так как
сопоставление идёт методом перебора с возвратами, то при возврате (то есть
неудачном сопоставлении) протокол тоже "отматывается" назад до места удачного,
и дальше пишется поверх...) Так например . (точка) сопоставившись с символом Х
пишет в протокол: ".Х" а встроенный шаблон %ш напишет "шХ"; конструкция <...>
так и пишет в протокол сначала открывающую скобку "<" а когда подойдёт к концу
(то есть удачно отработают все заключенные в ней элементы) — закрывающую ">".
(Напоминаю: весь шаблон целиком — это тоже вот такая конструкция.) Префиксы
повторения "выгораживают" там себе кусочек места, сначала написав "*", а в
конце — "|". Выбирающая конструкция [...] пишет в протокол "[" и после неё
число — порядковый номер сработавшего элемента, после чего (через запятую) то,
что он сам туда напишет. (Ну и закрывающую "]" — чисто для красоты.) Встроенный
шаблон, распознающий символ уникода, пишет его код в виде числа, но тоже с
префиксом "U". Есть так же средство записать нечто сложное и громоздкое, с чем
сопоставился например встроенный шаблон %S выделяющий строку в кавычках. А вот
по поводу постфиксов, типа :А где то что сгенерирует это А должно заменить в
протоколе то, что написал туда элемент шаблона этому постфиксу предшествующий,
не реализовано и даже не продумано — пока только общая идея.
Каждый элемент генерирующего шаблона получает очередной элемент протокола и
пытается, если простой, как-то использовать, или, если сложный — распределить
между входящими в него элементами. Так в частности всё та же . (точка)
вставляет абсолютно всё что получила один в один. А элемент, изображающий сам
себя — просто игнорирует.
В части второй не решена проблема с передачей в подпрограмму аргумента в
виде текстовой строки: если функциям получать такие аргументы можно, почему
подпрограммам — нет? Потому, что тогда под него потребуется локальная
переменная, способная хранить строку. А от полиморфизма мы шарахаемся...
Ладно, предположим это будет регистр форматного механизма с номером,
соответствующим позиции аргумента. А старое его значение — временно где-то
сохраняется и при возврате из подпрограммы будет восстановлено. Но при этом
с одной стороны встаёт вопрос определения типа полученного аргумента (включая
и его пропуск) для каждой позиции. А с другой — в сохранении и последующем
восстановлении нуждается так же и содержимое самого аккумулятора. Хотя не факт.
Но предпринимаются же меры по сохранению и последующему восстановлению А1 на
время выполнения реакции на внешнее событие... Или это "другое"?
((Определение типа полученного аргумента, как частный случай факта наличия
переменной, можно поручить функции FSUBr("имя_переменной", индексы...) передав
ей в качесте имени переменной пустую строку. Пусть возвращает -1 если переменной
с таким именем и индексами нет, 0 если есть, а +1 только в случае локальной
переменной, которой соответствует аргумент в виде текстовой строки (а в саму
переменную попала её длина на момент передачи параметров). Позволяют же нынче
операторы Write и Eraze, вот тоже со строчным аргументом, выдать и истребить
значения не всех переменных, а только этим аргументом указанных. А что бы и
здесь? Но в дополнение ко всему этому, уж коли мы взялись манипулировать с
переменными, надо бы еще цикл по всем наборам индексов некоторого массива.
Например так: For имя_переменной; тело цикла... — без всякого знака = (равно)
— индексы попадут в локальные переменные &0 &1 &2 (ну мы же не знаем один там
был индекс или два, значит пусть будет и так и так). Впрочем, баловство всё
это...))
Так же не решена мелкая проблемка с функцией FTMP которая пишет свой
"побочный эффект" (при преобразовании времени в удобочитаемый вид)
непосредственно в канал вывода, а не в А2. Хотя вроде бы можно сделать это по
аналогии с FTEll со строчным аргументом — именем файла для его поиска в
каталоге. Там "побочным эффектом" (который — имя найденного файла) управляет
сама эта функция (с помощью следующего аргумента). Вроде бы можно и здесь
следующим образом: не FTMP(N) а FTMP(N,).
И кстати для FMIn и FMAx на случай строчных аргументов сделать примерно то
же самое. Правда, непонятно как сравнивать строчки с числами. Да и между собой:
только по длине, или таки лексикографически?... Хотя вот это — определённо нет:
слишком много вариантов — пусть %r и %R этим занимаются. А результат возвращают
через аккумулятор А1, благо он там в свободном доступе...
* * *
А вот далее уже будет ЧАСТЬ ТРЕТЬЯ — чистой воды фантастика и выдумки.
* * *
...А исчо есть у нас такой аккумулятор А3 — чего это он, спрашивается,
бьёт баклуши, можно сказать почти без дела болтается? Пусть пользу приносит!
(Ну чем мы хуже кота Матроскина?!)
В туалете на военной кафедре разговаривают два студента:
— знаешь, чем майор Пронин отличается от обезьяны?
И тут заходит майор Пронин:
— ну и чем же я отличаюсь от обезьяны?
— Ни-Чем, товарищ майор!
— то-то у меня!
Ну так чем же мы хуже кота Матроскина — тем, что нас не показывают по
телевизору? Первое апреля, однако!...
Однако, пошутили и хватит. А и в самом деле: для чего такого полезного,
из того, что нам не хватает, можно пристроить аккумулятор, куда попадают
объекты ввода/вывода? И чего, кстати, нам не хватает? Графики? Да!
Ну графика, это вопрос отдельный, завязанный на образование "коллекций"
из графических примитивов, каждая из которых исходно — один график, а в
перспективе — изображение. Так, чтобы она могла выступать деталью других
изображений. То есть чтобы на неё можно было сослаться как на единое целое,
вызвать как подпрограмму. С параметрами, естественно... С параметрами? Ну
предположим... Но у нас же уже есть подпрограммы — самые обыкновенные. Можно
же написать такую, которая рисует нечто графическое... Но это — писать надо.
А коллекция — нечто другое, что само по себе в процессе (чего ни будь)
собирается. И параметры для неё это типа переместить, повернуть и
отмасштабировать... Перекрасить в другой цвет? Да. Коллекция же типа на цвет
завязана: это же исходно один из графиков, коих несколько штук мы строим в
общих осях, а значит — разными цветами. И собирается она вот как раз по мере
рассчета точек этого графика. А хранить её предполагается в виде одной из
групп программных строк. Но тут вылезает необходимость автонумерации. (А может
быть и псевдонимов из Фокала-2?) В отличии от подпрограммы, где строк, а вернее
операторов — умеренно, в графике какой ни будь функции этих самых отдельных
точек могут быть многие тысячи. И считать каждую из них оператором (типа:
Viz Точка X,Y; который её и нарисует), то на одних буквах V раззоришься! Да и
метки там нужны сильно не каждому. А только например когда хотим замкнуть
"полигон"...
Или таки лучше делать это в терминах "вершины — фаски" как в 3-Д моделях?
Подумаем... Вот вершине — аналогу точки, каждой нужна собственная метка, чтобы
фаски — аналоги полигонов на них могли ссылаться. Но их там тоже могут быть
многие тысячи. И хотя у нас сейчас номер строки в группе уже не две цифры, а до
четырёх, всё равно, боюсь, номеров не напасешься... Да и с построением графика
по точкам оно как-то не очень...
В общем тут еще думать и думать надо. (В процессе чего надо бы с языком
ПостСкрипт и с Х-терминалом познакомиться...)
Так что — нет, не графика...
Тогда может быть устройства? Вот например ком-порт... Ком-порт то у нас
якобы есть (под псевдонимом Ц) — ДОС`ом по умолчанию предоставляемый... Но
во-первых в машине их у меня два. Во-вторых: а как на счет скорости передачи,
да и прочих параметров? А в-третьих не только отдельные байтики, но и пакеты
оттедова хочется. Например вполне конкретные, имени одного моего знакомого...
Или есть изернетовский адаптер — тоже со своими пакетами.
Или вот USB...
Или канал азбуки морзе... Пока что она только встроенным динамиком пикает.
(И то засада со скоростями: надо переходить на другой таймер — который 1000 Гц,
а не системный — 18 с копейками. Его конешно тоже можно перепрограммировать, но
что будет с часами?!...) Но ведь можно и вывести на любой свободный вывод того
же ком-порта, или принтерного. И, кстати, ввести... Но там еще надо решить
проблему QLF так до сих пор и не решенную. (Что мол оператор работает на ключе
левой пяткою!...) Или подсмотреть у кого... Но вывод то можно сделать уже
сейчас...
Теплее, теплее... Но всё же еще не то.
А вот есть у нас еще такая проблемка — "навигация"...
Сейчас с точки зрения Фокала внешний мир это коллекция текстовых файлов.
Разложенных, правда, по каталогам... Но с каталогами Фокал работает, обращаясь
к ОС с помощью оператора ! (восклицательный знак). И, например, перебраться в
другой каталог под ДОС`ом с помощью команды CD у него вполне получается.
(Потому что процесс — один общий. Под UNIX`ом, полагаю, не получится.) А ищет
он файлы с помощью отдельного средства (FTEll("имя_файла")) никак с остальной
подсистемой ввода/вывода (почти) не связанного...
Правда файлы встречаются еще и "бинарные", с которыми Фокал испокон веку
работает с помощью спецфункции FCHR, таская ею байты поштучно. (А мы в части
второй еще кое-что к этому добавили.) Но чтобы сделать с бинарным файлом
что-то разумное, надо точно знать как именно он устроен — его формат.
А форматов этих нынче развелось — как собак нерезанных...
Но вот, полагаю, настало время (и/или появилась возможность) резко
облегчить работу с некоторыми из них. На примете: .dbf .wav .html вернее .xml
А еще и ком-порт, из коего приходят не отдельные байтики, а пакеты имени одного
моего знакомого... (Лично им в моём присутствии изобретенные. И с тех пор
используемые как минимум в трёх изделиях...)
Этот самый пакет — последовательность байтов, состоящая из "преамбулы",
заголовка, тела пакета, содержащего полезную информацию и контрольной суммы.
Преамбула (FF FF 00) должна показывать что информационный мусор, сыплющийся из
линии связи, закончился и начался вот этот вот пакет. (Коллега малость
перестраховался...) Заголовок — 4 байта: общая длина пакета, код его типа,
адреса отправителя и получателя. Контрольная сумма — один байт: просто сумма
всех остальных байтов пакета (не включая преамбулу). Содержимое — в
зависимости от типа. В смысле о чем договорились, как правило сами с собой.
Подобное изобретают все, кому не лень; этот конкретный — исключительно
ради конкретики.
Ага.
Этот самый файл типа .dbf известный как "реляционная база данных", хотя и
не совсем типичный их представитель. Но давно и широко используется, можно
сказать, стал уже стандартом де-факто... От типичной отличается тем, что
самодостаточный, "самоопределяемый" — содержит внутри себя описание своих
собственных полей — вложенный мини-файл... Впрочем, по порядку.
Эта самая реляционная база данных — всегда коллекция файлов. Разных, но
организованных на одном и том же принципе. Каждый файл — последовательность не
отдельных байтиков, а "записей" одинаковой длины. Каждая из которых состоит из
одних и тех же "полей". Где каждое поле содержит одно элементарное (для данной
базы данных) значение.
А наш механизм табулостопов это случайно не средство разделить текстовую
строку вот на такие поля? Да. Но есть и существенные отличия:
— во-первых поля — именованные
— во-вторых границы полей — "непроницаемы"
— и главное: поля — типизированные. (И этих типов — три вида...)
А у нас все поля пока что безымянные и все одного типа: "фрагмент строки".
Разумеется, в разных файлах и длина записи и набор составляющих её полей
могут быть очень даже разными. Поэтому в оной коллекции есть как минимум один
специальный файл, содержащий "метаинформацию" обо всех остальных: список их
полей с их типом и размерами. Описание каждого поля — одна запись, собственные
поля которой — фиксированные. А у файла типа .dbf перед последовательностью
записей, есть еще и заголовок, где среди прочего и содержится его
метаинформация.
Вопрос: является ли вышеописанный пакет частным случаем записи, бо он тоже
состоит из полей? (Если например откинуть преамбулу и контрольную сумму.)
Подумаем...
Этот самый файл типа .wav якобы содержащий вопли чьей то жены (ибо по
аглицки произносится совершенно так же), заставшей мужа... (опустим
подробности) оказывается, представитель целого семейства одинаково
организованных файлов, содержащих в себе потоки. Вон в файловой системе NTFS
эти самые потоки реализованы на уровне ФС, но в других-то ФС ничего подобного
нет, вот и приходится... Фрагмент потока (жаргонное название которого как-то
связано со свиньёй/чушкой из юго-восточной Азии) представляет собою запись
переменной длины, или, если хотите, очень простой пакет, заголовок которого
(8 байт) содержит только идентификатор (4 байта) указывающий его тип, и длину
тела. Но если она нечетная, то тело дополняется нулевым байтом.
Собственно весь файл — это один вот такой пакет. Но два типа потоков "RIFF"
и "LIST" содержат в себе вложенные потоки, организованные в точности так же.
(Но первые 4 байта — тоже идентификатор, указывающий что всё это такое.) Так
что в один файл можно запихать не только два канала с разными именами (чтобы
был стереоэффект) но и текстовое сообщение, что именно взбешенная супруга
хотела всем этим сказать. И еще массу полезной (или вредной) информации...
(Вообще-то стерео и даже квадроэффект достигается как-то по-другому: не
два отдельных канала, а в один — пары или даже чеверки отсчетов... Вроде бы.)
Вопрос: а еще у нас потоки есть? А как-же! Вот например содержимое самого
обыкновенного файла вне зависимости от его типа. Да и тело пакета пожалуй что
можно считать потоком. Вложенным или "встроенным". Хотя конешно в самую первую
очередь поток это то, что на нас валится из линии связи, включая отдельные
байтики и затесавшиеся меж ними пакеты, вот как вышеописанный.
А из файла, который лежит себе спокойно и никого не трогает, поток
организуется с помощью движущегося по нему указателя чтения/записи! Но его то
| Предыдущая глава |
↓ Содержание ↓
↑ Свернуть ↑
| Следующая глава |
