| Предыдущая глава |
↓ Содержание ↓
↑ Свернуть ↑
| Следующая глава |
((Определение типа полученного аргумента, как частный случай факта наличия
переменной, можно поручить функции FSUBr("имя_переменной", индексы...) передав
ей в качесте имени переменной пустую строку. Пусть возвращает -1 если переменной
с таким именем и индексами нет, 0 если есть, а +1 только в случае локальной
переменной, которой соответствует аргумент в виде текстовой строки (а в саму
переменную попала её длина на момент передачи параметров). Позволяют же нынче
операторы Write и Eraze, вот тоже со строчным аргументом, выдать и истребить
значения не всех переменных, а только этим аргументом указанных. А что бы и
здесь? Но в дополнение ко всему этому, уж коли мы взялись манипулировать с
переменными, надо бы еще цикл по всем наборам индексов некоторого массива.
Например так: For имя_переменной; тело цикла... — без всякого знака = (равно)
— индексы попадут в локальные переменные &0 &1 &2 (ну мы же не знаем один там
был индекс или два, значит пусть будет и так и так). Впрочем, баловство всё
это...))
Так же не решена мелкая проблемка с функцией FTMP которая пишет свой
"побочный эффект" (при преобразовании времени в удобочитаемый вид)
непосредственно в канал вывода, а не в А2. Хотя вроде бы можно сделать это по
аналогии с FOper (она же FTEll) со строчным аргументом — именем файла для его
поиска в каталоге. Там "побочным эффектом" (который — имя найденного файла)
управляет сама эта функция (с помощью следующего аргумента). Вроде бы можно и
здесь следующим образом: не FTMP(N) а FTMP(N,).
И кстати для FMIn и FMAx на случай строчных аргументов сделать примерно то
же самое. Правда, непонятно как сравнивать строчки с числами. Да и между собой:
только по длине, или таки лексикографически?... Хотя вот это — определённо нет:
слишком много вариантов — пусть %r и %R этим занимаются. А результат возвращают
через аккумулятор А1, благо он там в свободном доступе...
* * *
Своего рода... ну скажем "интерлюдия": пора уже к ЧАСТИ ТРЕТЬЕЙ переходить,
А всё вот никак... (Может вот это и есть "вязкость мышления"?)
* * *
Всё эта вот проблемка — с побочным эффектом FTMP и ей подобных — что мол
здесь "кто в лес, кто по дрова"... Ну так давеча я её таки забодал — сделал
для них для всех единообразно, вот как выше предполагалось:
FO("имя_файла") — ищет файл и возвращает его размер (или -1 если не нашла)
FO("имя_файла",) — -//— + имя файла -> в канал вывода
FO("имя_файла",Y) — -//— + -//— (Y — тип файла — см.(FOper))
FO("имя_файла",,) — -//— + имя файла -> в А2
FO(,,N) — параметр N -> в канал вывода (возвращает его длину или -1)
FO(,,N,) — параметр N -> в А2 -//-
FO(,,"имя_переменной_окружения") — -> в канал вывода -//-
FO(,,"имя_переменной_окружения",) — -> в А2 -//-
привыкаем вместо FTEll писать FOper, FOpen, FOкружение...
FKурсор("к") — строка с экрана -> в канал вывода -//-
FKурсор("к",) — -//— -> в А2 -//-
FTMp(t) — дата/время(t) -> в канал вывода -//-
FTMp(t,) — -//— -> в А2 -//-
несколько забегая вперёд:
FSBr("имя_переменной",индексы) — 0 если переменная есть, -1 если нету
FSBr("имя_переменной",индексы,"") — -//— + "побочный эффект"
FSBr("имя_переменной",индексы,"",) — -//— + -//— в т.ч. имя -> в А2
FSBr("") — побочный эффект: имя -> в канал вывода + индексы -> & &1 &2
FSBr("",) имя -> в А2 -//-
это в случае "итератора": если индексы пропущены и/или имя — список/шаблон
аналогично:
FO(,,"имя_переменной_окружения") — значение переменной -> в канал вывода
FO(,,"имя_переменной_окружения",Х) — имя переменной -> в канал вывода
FO(,,"имя_переменной_окружения","") — "имя=значение" -> в канал вывода
FO(,,"имя_переменной_окружения","",) — "имя=значение" -> в А2
FO(,,"") — значение следующей переменной
FO(,,"",) — значение следующей переменной -> в А2
FO(,,"",Х) — имя следующей переменной
FO(,,"",Х,) — имя следующей переменной -> в А2
FO(,,"","") — "имя=значение" -> в канал вывода
FO(,,"","",) — "имя=значение" -> в А2
где Х — числовой параметр (никак не используется и даже не вычисляется)
Ну так вылезла следующая проблемка! А за нею — еще одна...
Вот, предположим, такая функция с побочным эффектом вызывается внутри
как раз и работающего с А2 форматного выражения оператора Write %... (будучи
там в составе фокаловского выражения, заключенного в фигурные скобки) — ну так
этот её побочный эффект, норовящий заменить собою содержимое А2, испортит нам
всю малину... Запретить! Подавить! Установить специальный признак,
предписывающй подавление побочного эффекта... Но уж коли строчный результат
функции таки сформирован — пусть пользу приносит! (Чем мы хуже кота
Матроскина?!) Нехай станет текстовым операндом. (Правда только в случае, если
такой и ожидается: просто {FTMp(t,)} — может и нет, а вот {''FTMp(t,)} — да.)
Ага. (В смысле: сделал.)
А вот есть у еще нас такая штука, о которой я совсем забыл: фокус-покус с
оператором Ask и строчным аккумулятором...
Еще давным давно, в незапамятные времена, когда и мысли то такой еще
небыло, что входной буфер оператора Ask это какой то там аккумулятор...
И Ask использовал его в одно рыло... Выявилась вот такая вот технологическая
потребность: давайте мол выдадим пользователю уже готовое значение, чтобы ему
его не набирать, а только согласиться! Нет, если хочет, конешно может
исправить... Но это всяко легче, чем набирать с нуля.
(Так делается при выходе из Фокала по нажатию ESC для сохранения программы)
Можно такое провернуть? Оказывается, запросто: всего-навсего надо, чтобы
вот это вот начальное значение было в буфере (в смысле в А2), но чтобы он при
этом ВЫГЛЯДЕЛ пустым. И тогда Ask не будет этот свой буфер чистить, а сразу
обратится за новой строчкой к редактору. (А редактор как раз и использует
содержимое буфера как начальное значение, которое ему велено редактировать.)
Провернуть это можно принудительно поставив на конец буфера указатель текущего
места в нём. (Тот самый, что указывает на очередной, якобы еще "не
использованный" символ. Он-же, кстати, "маркер".) Ничего сложного. Сейчас — аж
несколькими способами. Например: Mov ! = "нач.значение"; Write %$ 0; Ask x
Но тогда ничего такого еще небыло. Вот и поручили формировать это самое
начальное значение самому оператору Ask: после спецформата %% и до конца
оператора или до ! (восклицательного знака) список ввода обрабатывается в
точности так же как список вывода оператора Write. Но результат попадает не в
канал вывода, а в А2. Спецформат %%% отличается от %% тем что велит добавлять
к тому что в А2 уже есть. И с концом оператора не заканчивается...
Оказывается, это была заготовка для буферизации вывода. Типа: когда включен,
то весь вывод — в А2. Нецелесообразно: ну нафига там длиннющие тексты, которые
выдаёт оператор Help? Да и Write с дополнительными ключевыми словами одной
строчкой заведомо не ограничится. Оператор Type?... Но всё, что он умеет,
в этом режиме умеет и Ask. Так что пусть им всё и ограничится. А вот текстовый
побочный эффект вышеперечисленных функций (и плюс к ним FCHr("-текст",...
который она, начиная со второго символа, напишет в А2) — не заменяет того, что
там было, а добавляется.
Отменяется этот режим только с помощью ! или %! — чтобы, если режим не
включен, не выдать случайно лишний перевод строки. (Кстати %! и в операторе
Type тоже: таки рудимент!)
Ага. (В смысле поправил.)
Но это если FTMp(t,) где-то в других операторах. А в самом Ask %%... ?
Да то же самое!
И еще то же самое в операторе Move X = "текст", FTMp(t,)...
И вот теперь думаю: а не безобразие ли это? В плане предсказуемости и
детерминированности... Признак формирования начального значения — глобальный:
вдруг какая-то подпрограмма его включит и забудет выключить, а мы ни сном ни
духом — вот и будем удивляться, чего это вдруг оператор Ask так странно
работает?... Сделать локальным? (Чтобы самовыключался при выходе из
подпрограммы.)
Или, если посмотреть на это с другой стороны: а надо ли это? Что это даёт?
Перехватывается текстовый побочный эффект ряда функций. Которые могут
прекрасно быть вызваны и в самом операторе Ask — эффект будет тот же самый...
Да? Да, но только если этот самый побочный эффект таки есть. А если нету?
Что очень даже бывает, когда например файл или переменная среды не найдена...
Функция выдаст -1, что будет совсем "не в жилу"... (Хотя, конешно можно сделать
чтобы побочный эффект был всегда, но вот в этом случае — пустой.)
И, кстати, если это итератор, то всё это происходит в цикле и получив -1
надо из него выйти. Да и результаты его работы используются поштучно...
А вот это как раз не обязательно... Так что отложим "на подумать".
Ну ладно, это всё не то что бы совсем тривиально, но таки лежит на
поверхности. А вот что делать, если во всех этих местах будет вызов
подпрограммы с помощью функции FSUbr? В каковой подпрограмме запросто могут
быть не только функции вот с таким побочным эффектом (который тоже можно бы
подавить) но и работающие с А2 операторы? Запретить их работу было бы ну
совсем-совсем неправильно!...
А нехай FSUbr, обнаружив оный признак, сохраняет А2 где ни будь в стэке;
при возврате — восстанавливает; а для вызванной подпрограммы заводит новый,
делая его пустым. И пусть они там творят с ним что хотят... Но вот то, что
оказалось в А2 на момент возврата, пусть и будет текстовым побочным эффектом
вызова вот этой функции. (В смысле вызванной ею подпрограммы.)
Ну-с, с этим уже можно работать. Работаем... Сделано.
Сделано вместе с обсуждавшейся выше передачей в подпрограмму не только
числовых, но и строчных параметров. Каковые разумеется попадают не в локальные
переменные (ибо никакого полиморфизма!), а в регистры форматного механизма с
номерами, соответстствующими позиции параметра. (Но только в пределах первого
десятка.) Которые теперь тоже вдруг стали локальными. (Вернее вот эти вот -
сохраняются в стэке и при выходе из подпрограммы будут восстановлены. Даже
пустые. Механизмы — общие.)
Ага. В смысле теперь бы еще как-то узнать что именно передали...
Кстати, это частный случай от более общей проблемы проверки наличия объекта.
Каковых у нас, помнится, было два вида: программные строки и переменные.
Назвать-то объект, упомянуть в программе хоть по имени хоть по номеру,
обратиться к нему неким образом, нам ничто не мешает... А вот удостовериться,
что таковой уже существует и при этом не "получить по шапке", словив ситуацию?
Для программных строк пришлось ввести функцию FN, сообщающую в случае
наличия строки с указанным номером — номер следующей (в пределах группы), или
0 — если последняя. А если нету — соответственно -1.
Для переменных — задача хитрее: они бывают еще и с индексами. Каковой
индекс угадывать... Некузяво. А если мы его точно знаем, то и проверять без
надобности. Так что хотелось бы при случае пробежаться по ним по всем. Что
ставит перед нами проблему "итераторов": типа один раз задал, что именно ищем,
а потом обращаясь повторно, последовательно перебирашь элементы выделенной
таким вот методом коллекции, пока она не исчерпается...
Впринципе, один такой итератор у нас уже есть: функция FO со строчным
параметром... (Эта самая FO..., бывшая FTEll — парная к оператору О...
Каковая сладкая парочка специализируется на внешнем ОКРУЖЕНИИ. Удачная таки
буква им досталась!) Ну так FO("имя_файла") ищет в текущем каталоге файл,
указанный этим своим параметром. Однако, таковой может быть далеко не один,
потому что операционная система (ОС) к которой FO и обращается, разрешает
указать не конкретное имя файла, а "шаблон". Следующие файлы мы находим
повторными вызовами FO("") — с аргументом в виде пустой строки. Чем не
итератор? Но только один, глобальный... (Да, можно придумать задачу, где
таковых понадобится как минимум парочка... И придумать, как её решить, имея
хотя бы один. Или даже вообще ни одного: чисто с помощью команды DIR — анализом
выдаваемого ею текста. Так что у нас — минимум миниморум.)
Ну так кандидаты в итераторы: та же самая функция FO(,,"имя_переменной"),
позволяющая добраться до переменных "окружения" (которое "environ"); это самое
(обсуждаемое) средство проверить наличие переменной; и планируемое в третьей
части средство работы с именованными полями записей, до которого еще как до
Пекина раком...
Вернемся к нашим баранам: вот так и придётся поручить эту миссию функции
FSUBr("имя_переменной", индексы...) потому что единственное место, куда можно
деть значения очередного комплекта индексов — поместить их в локальные
переменные. А именно FSUBr на них и специализируется. Но таковой побочный
эффект (а так же имя переменной) — обязателен только при повторном вызове:
FSUBr(""), а при первом — только если: FSUBr("имя_переменной", индексы, "").
Соответственно возвращают они 0 для очередной переменной или -1 если коллекция
исчерпалась.
Для N-ного позиционного параметра (он же — локальная переменная) FSUBr("&N")
или FSUBr("&",N) вернёт +1 если в этой позиции была строка, 0 — если число,
и соответственно -1 если локальной переменной с таким номером нет. Но уж коли
так исторически сложилось, что у нас для обращения к локальным переменным два
синонима (кроме &N еще и $N) то пусть первый относится к переменным строго
локальным, а второй — еще и к тем, что есть у подпрограмм, вызвавших данную.
(Но только для конкретных переменных: устроить цикл по всем возможным
значениям индекса i для $[i] всех уровней вложенности несколько
затруднительно. Нет, можно, но уж больно громоздко получается. Да и зачем?...)
Если для FSUBr("строка") причиной сооружения итератора могут быть индексы;
строка может содержать сразу целый список имён переменных, которые, еще к тому
же могут быть шаблонами, то для FO("строка") — только шаблон. Адын штука. Это
раньше (в том числе в ДОС`е) на имена файлов накладывались почти такие же
ограничения, как на имена переменных. А теперь (например в винде) там могут
быть любые символы, включая пробелы и запятые...
А для FO(,,"строка") — свои сложности: если для конкретной переменной
однозначно возвращается её значение (а так же его размер, или -1 если нету),
то в случае шаблона нам может понадобиться еще и её имя... И что делать?
Ладно, пусть этот вопрос регулирует еще один параметр: числовой. При его
наличии... И уж тогда пусть обращение к конкретной переменной не ломает
| Предыдущая глава |
↓ Содержание ↓
↑ Свернуть ↑
| Следующая глава |
