Фокал - часть 3 (пишется)

переменную или хотя бы не продублировали, то он — тю-тю! Разве мы хотели

этого?...) И вообще всё это сильно напоминает детскую загадку: "как положить

слона в холодильник?". Да очень просто: открыть холодильник, положить слона,

закрыть холодильник. А жирафа? В точности так же, только сначала слона надо

вытащить... В языке Форт такие фокусы со слонами и холодильником как-то не.

Там всё честно: вот до сих память занята, а дальше свободна. Занимаем еще

сколько-то ячеек, положив туда то, что составит заголовок новой словарной

статьи, включая её имя и ссылку на предыдущую. Засыплем содержимое, или даже

просто зарезервируем место, передвинув границу. Переставим туда указатель

начала словаря. Всё! (Всё это буквально парочка команд — всё давно

автоматизировано! Но надо хорошо понимать, что делаешь.) Но словари уже сразу

обширные, слов тама ентих таки дюже много. Сотни. А учитывая что всё это чужая

лексика, чуждая, можно даже сказать что вражеская... (Пока нет? Ну это нам

только так кажется!) Да, и Форт и ПостСкрипт позволяют вводить новые слова. Ну

так переименовать всё к такой-то бабушке!... Но нам с нашим языком флективного

типа всё равно не больно то удобно. Это скорее для тех, кто пишет и думает

неизменными иероглифами. Вот китайцам, полагаю, самое оно... Впрочем, хотя

"опора на естественный язык" это вот как раз для них, а для нас — глупость и

профанация (да и тупое запоминание — как нож острый, вся надежда на правильные

ассоциации), но у каждого свои проблемы, и если у нас они более синтаксические,

то у них имеющая место быть контекстозависимость... Пакость еще та! Нет, если

бы оная непомерная омонимия выявляла реально полезные ассоциации между

обозначаемыми вещами... Вот как наши гнёзда однокоренных слов. Но если они

таки больше случайные, то ведёт это к: от просто злоупотребления

классификационными наборами и проистекающей из этого мистики, до острого

дефицита носителей разума...

Ну всё, автора понесло... Ты про ёлку-то не забыл, боярин дубовый?! (Ц)

Ну это я так — для общего развития. Да не собираемся мы (по крайней мере

пока) выковыривать тексты из .rtf или .pdf файлов! У нас сейчас другая

проблема: перемещение по ссылкам — вот та самая "навигация".

* * *

Итак, что видим в вышеизложенном? Запись; поле записи; пакет, который

тоже совокупность полей; поток — обобщение файла и линии связи, а так же тела

пакета. И три вида содержимого эти самых полей: число, строка и вот поток. При

чем в двух вариантах: как ссылка и "вложенный". Но это нам пока без разницы.

Главное: вот как раз для трёх наших аккумуляторов!

Теперь, согласно новой (вот только что изобретенной) моде, оператор Oper

оперирует вовсе не какими-то там файлами, а потоками! И в аккумулятор А3 тоже

попадает указатель на такой поток. Но если раньше он использовался только и

исключительно для того, чтобы функция FTEll могла сообщить об этом файле

(потоке) кое-какие сведения, то вот прямо сейчас надо срочно придумать, как бы

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

сделали для А2: с одной стороны пусть используется везде, где бы могло

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

такого типа. Ну и поищем для этого типа переменные...

Ага-ага, ну и кому, спрашивается еще кроме всё той же FTEll это может

понадобиться? Разве что оператору Oper, в распоряжении которого как раз и

находится то, что с некоторыми натяжками можно считать "переменными":

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

((Кстати, а не наклёвываются ли у нас еще и следующие аккумуляторы?

А то мы вроде как собрались тоже выделять во временное пользование буковки под

типы файлов и под кодировки, подгружая всё это так пока и не реализованным

оператором Load... Ну, слава Аллаху, вроде бы нет. Нам бы еще вот с А3 как ни

будь разобраться... И вообще бог троицу любит, да и в операторе If у нас

только три направления... Так что это был бы явный перебор!))

Итак, определились что кроме FTEll и Oper аккумулятор А3 вроде бы никому

больше не нужен. (Ну разве что введём для чего ни будь еще одну функцию, для

которой, так же как и для FTEll, это будет неявный параметр.) Результат работы

FTEll("имя_файла") по поиску файлов в каталоге уже (изначально) попадает в А3.

Теперь еще надо чтобы туда попадали значения полей ссылочного типа. И надо

придумать, как использовать А3 в Oper. Пока что чисто синтаксически...

Ну ясный пень, как... Где там прохлаждается главный баламут всея Фокала?!

(А подать сюда Ляпкина-Тяпкина! (Ц)) А то он вроде бы уже во всех операторах

ввода/вывода отметился? А ан в операторе Oper еще нет — упущение!

Так что: Oper % Псевдоним; или даже: Oper %ХХХ Псевдоним

В первом случае имеем аналог присваивания: поток из А3 теперь будет еще и

под указанным в операторе псевдонимом. А "аналог" потому, что это ведь могла

быть всего лишь ссылка на файл, а вот теперь он открывается. Так что если

раньше, найдя конкретный файл с помощью FTEll("шаблон") мы должны были

предпринять меры, чтобы его имя попало в А2 в качестве "побочного эффекта" и

уж только потом... А сейчас можно вот так — напрямую. И как же это я раньше до

этого не додумался!

Но теперь (хотя я еще и не придумал — как?) в А3 сможет попасть значение

некоторого хитрого поля, например типа "мемо" в .dbf, или вложенный поток

некоторого пакета. И мы теперь сможем его открыть так, как будто это вполне

обычный файл. (А то как еще до них добраться?) Вот нам и навигация!...

Но сразу всплывает проблемка: таких потоков может быть много, очень много,

а псевдонимов — мало. При открытии нового файла, тот, который уже был открыт

под данным псевдонимом — закрывается... Ну и как его потом открыть по-новой?

Особенно, если мы прошлый раз шли к его открытию неведомо какими партизанскими

тропами... Или если, например, в некой подпрограмме понадобилось временно

чем-то попользоваться — после себя надо бы восстановить всё как было. А если

она при этом еще и рекурсивная... Имя файла надо знать! А мы его знаем? Ой, не

факт... (Кстати, штатных средств узнать имя открытого под таким-то псевдонимом

файла что-то не припоминается — как то никому не надо было... Ну не вывод же

оператора Write Oper; ловить и анализировать!) А даже если бы и знали...

(Положение указателя чтения/записи тоже восстановить не вредно...) Но

сейчас-то дело существенно усложняется. И вообще полезно как-то запомнить путь,

которым мы вот сюда пришли...

В общем вводим в псевдоним еще одну буковку, например S, предписывающую

предыдущий файл, открытый под этим псевдонимом, не закрывать, а "отодвинуть"

куда-то вглубь. На предмет, когда новый будет закрыт, вернуть всё как было.

А при переключении канала ввода или вывода эта самая S должна указывать

на необходимость сохранения информации о том, куда он был направлен для

последующего восстановления. Например если вдруг файл, на который его

направили, будет закрыт. Или... (Надо придумать, как переключить не куда-то а

обратно. Может быть что-то типа Op #R; если это к примеру канал ввода. Хотя

символ # это вполне добропорядочная буква... А нужен такой, что псевдонима

образовать не может... Может: Oper % и всё — без всякого псевдонима?)

Во-втором случае это самое ХХХ может быть например буковкой М чтобы

добраться до мета-информации данного потока. Или буковкой U чтобы что-то

сделать с USB, или буковка К (а может быть таки Ц) — чтобы с компортом...

(Ну например так: Open %К2=9600n2 П; — открыть под псевдонимом П ком-порт 2 и

установить скорость 9600 бод при двух стоповых битах и без контроля четности.)

* * *

Теперь надо что-то делать с полями. Много чего. Но для конкретики

предположим что у нас под псевдонимом П открыт уже существующий файл типа .dbf

который, как известно, содержит в себе собственную метаинформацию.

Ознакомиться с нею мы можем следующим образом:

Oper () П; Oper %m QrS; Oper QrS; Write %m; Oper "" Q;

Из чего должны сделать вывод, что у нас так же есть и встроенный формат

%М оператора Write, преобразующий вот такие-вот метафайлы в пригодный для

человеческого восприятия вид.

Однако, мы-то ознакомились, а что про этот файл знает программа? Возможны

варианты. Предположим, что она знает что там есть поле с именем "имя_поля", от

которого не ждёт никакого подвоха. Тогда всё как обычно: Op П; Ask :имя_поля, Х

И всё: если оно, как обычно, текстовое, то его содержимое попадёт во входной

буфер оператора Ask после чего обычным образом будет вычислено находящееся там

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

ИМЕНОВАННОМУ полю, аккумулятор А2 так же автоматически очищается, как и при

переключении канала ввода. А ежели поле числового типа, то тогда еще проще:

этот самый числовой тип напрямую (минуя А2) преобразуется во внутреннее

представление и попадает в переменную Х. Ага.

А вот если ожидает? Подвох же здесь в том, что это поле и не числовое и не

строчное. (Если не ожидала — будет ошибка.) А ожидает она следующим

оригинальным образом: Op П; Ask :имя_поля = A, B, C, D....; Понятно?

...Пришлось, панимашь, таки задействовать форму с присваиванием...

Что тут будет? А вот: содержимое поля попадает в один из трёх

аккумуляторов. А в переменную A — сведения, в какой именно (его вид): 0 — число,

+1 — строка, и -1 — вот то самое, что в А3. А в B, C, D... — следующие этого

поля параметры... Уж (пока) не знаю какие. Ну может быть более конкретный тип,

размер, смещение поля в записи... (Если просто Ask = ...; — то для текущего

поля.) А если для оператора Type, то всё, надо понимать, в другую сторону? Ага.

А конкретнее? В текущее поле копируется содержимое одного из этих трёх

аккумуляторов. И, возможно, (то есть если это возможно) устанавливаются его

параметры. В данном конкретном случае — если такого поля еще небыло, что должно

бы вызвать ошибку при позиционировании, а .dbf-файл пока пустой, состоит

только из заголовка, каковой и пополняется. Ага-ага: а ежели .dbf-файл как был

так и остался пустой, куда-же, спрашивается, делось якобы записанное туда

значение из аккумулятора?

Вот тут и всплывает необходимость в буферизации вывода! Вернее дело

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

"транзакциями". Чтобы, если что, она не зависла в промежуточном состоянии...

В данном конкретном случае мы должны читать его и писать не побайтно, а вот

такими (какие у него есть) записями. То есть к каждому такому файлу привязан

буфер под одну запись, и всё что мы пишем — мы пишем туда. А что читаем

оператором Ask — оттуда. По поводу автоматического чтения следующей записи мы

еще подумаем, а вот запись оператором Type находящейся в оном буфере записи

только и исключительно когда в его списке вывода встретится ! (восклицательный

знак) для строк указывающий, что мол надо учинить конец строки.

Вот где-то так. Но это только для .dbf

Файл, содеражщий потоки, на вроде .wav надо сперва открывать как каталог.

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

делать две разные вещи — либо объединять содержимое всех следующих друг за

дружкой однотипных пакетов в один непрерывный поток. Автоматически. Открыв этот

виртуальный поток под другим псевдонимом. Либо таки рассматривать каждый пакет

индивидуально — как "дейтаграмму". (Иковерканное "датаграмма" — аналог

телеграммы.) Так же как отдельную очередную запись из .dbf

Самое непонятное — что делать с .html? С .xml вроде как следует поступать

так же как с поледовательностью записей. Но обратим внимание — каждая такая

запись содержит два выделенных поля: имя тега и содержимое — поток. То есть как

полагается каталогу. Отличие только в том, что там все имена уникальные, а тут

нет. А еще — там в заголовке могут быть какие угодно дополнительные поля. В том

числе и заранее неизвестные. У .html — то же самое. Но там это объективно

сущетсвующие параметры просмотрщика, которым временно (до закрывающей скобки)

придаются новые значения. Получается, что у .html-евской записи ну просто куча

нигде заранее не описанных каких угодно полей (правда все одного типа:

фрагмент строки), а не как у .dbf — фиксированный набор, и целый стэк значений

для каждого. То есть если даже такого поля никогда небыло, то обращение к нему

это не ошибка, но значение у него — строка нулевой длины.

Как это сделать — впринципе понятно. Но черт возьми, как же это громоздко

получается!

* * *

Следующая наша проблема это описание полей. Именованных. Оно должно быть

организовано по аналогии с устанавливающим табулостопы спецкомментарием из

одних двоеточий. Что-то типа: :имя_поля1 :имя_поля2 :имя_поля3... !

Ага. Но с одной стороны надо еще указывать тип поля. (Например как в .dbf,

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

поля плюс тип в нём не помещаются. И тогда размер поля тоже придётся указывать

явным образом. А вот с другой: если табулостопы привязаны к терминалу, и

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

каждого файла — свой набор полей. Пусть даже и частично одинаковых. За сим

требуется привязка к файлу, что-то типа: @имя_файла :имя_поля1: имя_поля2... !

Вот только имя файла здесь не очень-то подходит. (Ну разве что в качестве

значения по-умолчанию.) Фактически это метафайл. (Вернее метапоток — поток

метаинформации для некоторого потока.) Он может быть встроенным в заголовок

файла, как для .dbf или и вовсе виртуальным. И плюс к этому нам пожалуй

пригодился бы виртуальный каталог — список вот таких метафайлов, автоматически

пополняемый по мере открытия файлов или ввода вот таких вот описаний,

изобретением которых мы вот сейчас и занимаемся...

Как мы это собираемся использовать? Ну например так: Open псевдоним = имя

Помнится, когда-то давно, это было полным синонимом для: Open "имя" псевдоним

Впрочем это была "учебная" реализация базового Фокала "первый блин", который и

в самом деле получился тогда немножко комом... Сейчас же будет назначение

потоку новой структуры. С текущего места...

Итак, если поток — это поток записей, то и мета-поток к нему это тоже поток

записей, каждая из которых описывает одно поле. А мета-мета-поток — один для

них для всех... Или не один а всего лишь одинаковый? Потому что хочется, чтобы