| Предыдущая глава |
↓ Содержание ↓
↑ Свернуть ↑
| Следующая глава |
помещается. (Только стэк у них у обоих неограниченной глубины, не то что у нас.)
И Форт можно считать безтиповый, а вот у ПостСкрипта — полиморфизЬм. Хотя
принцип, да — одинаковый, грамматика немножко разная. И слова... Разделяемые,
кстати, просто пробелами... У Форта слова — из совершенно любых символов, а у
ПостСкрипта некоторые символы таки "служебные": это все виды скобок, включая
угловые, символ % (процент, с которого, кстати, там начинается комментарий до
конца строки) и еще некоторые. Например текстовая строка там заключается в
круглые скобки (а вовсе не в кавычки), последовательность действий, которую
потом можно будет выполнить — в фигурные, а массив — в квадратные. При чем
строчка там — "литерал": сразу помещается на стэк. А вот квадратные скобки
действуют хитрО: открывающая помещает на стэк спецобъект "метка", а
закрывающая берёт всё что после этой метки скопилось, делает из этого массив и
помещает его на место метки. Соответственно, меж этими скобками делай что хошь.
А вот внутри круглых — все символы один в один. Ну разве что экранирующий...
Как всегда (обратная косая черта).) А то, что Форт безтиповый, а типы данных
таки объективно есть, то например для самых обычных арифметических операций
(+ — * /) нужно несколько разных комплектов слов чтобы обозначать их для целых
одинарной и двойной точности, а так же еще беззнаковых и с плавающей запятой...
В общем случае — громоздко получается. (А что мы хотим? Эта самая безтиповость
в том и заключается, что какую операцию применил, такой значит и был тип!)
Но в ограниченных частных случаях — просто, компактно и очень-очень быстро. Для
ПостСкрипта всё наоборот...
В общем, выражений в обоих языках никаких нет: буде захотели вычислить
что-то по формуле — преобразуем её в обратную польскую безскобочную запись...
(Ха! Между прочим — обход дерева.) Типа вместо 1+2+3 пишем 1 2 + 3 + а если
1+(2+3) то соответственно 1 2 3 + + только вместо + в ПостСкрипте придётся
писать add.
Впрочем, главное и там и там это "словарь", где все вот эти слова и
ищутся. Словарь — пополняемый! У нас в калькуляторах %r %R ничего подобного
нет: набор команд — фиксированный. Но в потоке символов, который — команды,
таки выделяются константы, сразу помещающиеся на стэк и собственно команды,
которые что-то делают. Так и у них — "литералы" (например числа или строки) и
просто слова, которые ищутся в словаре. (Но /слово — будет литералом.)
Ищутся — в словарях: их там несколько — целая стопка (кипа, стэк!) — начиная с
верхнего. Словарь, кстати, изображается: << ... >> где внутри — набор пар:
ключ-значение. Да, можно изобразить и вот так, или создать пустой: N dict но
сразу из N элементов. (И словарь и строка и массив отнюдь не резиновые — вот
как создали, так и.) После чего хоть перекинуть его на стэк словарей командой
begin и он станет "текущим" (а удалить его потом отуда командой end, но можно
и получить на стэк копию текущего командой currentdict) и заполнять:
/имя значение def (буде оное значение — литерал, получится переменная; буде
нечто выполняемое, типа {...} — подпрограмма получится). А можно заполнять
прямо здесь, обращаясь как с массивом или строкой — командами put и get.
(Однако, имеем в виду: вот мы положили на стэк словарь, а так же то что будет
ключом и значением; выполнили команду put которая туда их запишет. Но со стэка
то она их все три удалит! И если мы этот свой словарь заранее не припрятали в
переменную или хотя бы не продублировали, то он — тю-тю! Разве мы хотели
этого?...) И вообще всё это сильно напоминает детскую загадку: "как положить
слона в холодильник?". Да очень просто: открыть холодильник, положить слона,
закрыть холодильник. А жирафа? В точности так же, только сначала слона надо
вытащить... В языке Форт такие фокусы со слонами и холодильником как-то не.
Там всё честно: вот до сих память занята, а дальше свободна. Занимаем еще
сколько-то ячеек, положив туда то, что составит заголовок новой словарной
статьи, включая её имя и ссылку на предыдущую. Засыплем содержимое, или даже
просто зарезервируем место, передвинув границу. Переставим туда указатель
начала словаря. Всё! (Всё это буквально парочка команд — всё давно
автоматизировано! Но надо хорошо понимать, что делаешь.) Но словари уже сразу
обширные, слов тама ентих таки дюже много. Сотни. А учитывая что всё это чужая
лексика, чуждая, можно даже сказать что вражеская... (Пока нет? Ну это нам
только так кажется!) Да, и Форт и ПостСкрипт позволяют вводить новые слова. Ну
так переименовать всё к такой-то бабушке!... Но нам с нашим языком флективного
типа всё равно не больно то удобно. Это скорее для тех, кто пишет и думает
неизменными иероглифами. Вот китайцам, полагаю, самое оно... Впрочем, хотя
"опора на естественный язык" это вот как раз для них, а для нас — глупость и
профанация (да и тупое запоминание — как нож острый, вся надежда на правильные
ассоциации), но у каждого свои проблемы, и если у нас они более синтаксические,
то у них имеющая место быть контекстозависимость... Пакость еще та! Нет, если
бы оная непомерная омонимия выявляла реально полезные ассоциации между
обозначаемыми вещами... Вот как наши гнёзда однокоренных слов. Но если они
таки больше случайные, то ведёт это к: от просто злоупотребления
классификационными наборами и проистекающей из этого мистики, до острого
дефицита носителей разума...
Ну всё, автора понесло... Ты про ёлку-то не забыл, боярин дубовый?! (Ц)
Ну это я так — для общего развития. Да не собираемся мы (по крайней мере
пока) выковыривать тексты из .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 находящейся в оном буфере записи
только и исключительно когда в его списке вывода встретится ! (восклицательный
знак) для строк указывающий, что мол надо учинить конец строки.
| Предыдущая глава |
↓ Содержание ↓
↑ Свернуть ↑
| Следующая глава |
