Chapter 1: section 3

Author: ilammy

.gitignore

@@ -7,4 +7,3 @@
 *.pdf
 *.toc
 /epub/OEBPS/images/
-/book-src/compiled

book-src/.gitignore

@@ -0,0 +1,2 @@
+*.html
+compiled/

book-src/ch01_basics/03_evaluating-atoms.poly.pm

@@ -52,77 +52,74 @@
 ◊indexR{переменные!связь с~символами}
 ◊indexR{символы!связь с~переменными}
 Как видим, наш интерпретатор неявно преобразует символы в~переменные.
-Если быть более дотошным, тогда вместо ◊ic{(lookup exp env)} надо записать что-то вроде:
+Если быть более дотошным, то вместо ◊ic{(lookup exp env)} надо записать что-то вроде:
 
 ◊code:lisp{
 ... (lookup (symbol->variable exp) env) ...
 }
 
-◊; продолжать здесь:
-
 ◊indexR{приведение типов}
 ◊indexR{объекты!второго класса}
-В~таком случае мы явно говорим,
-что символ~◊ic{exp}, чьим значением является имя переменной, должен быть превращён в~переменную.
+В~таком случае мы явно говорим, что символ~◊ic{exp}, чьим значением является имя переменной, должен быть преобразован в~переменную.
 Также это подчёркивает тот факт, что функция ◊ic{symbol->variable}
 ◊footnote{Лично я не~люблю называть функции приведения типов ◊nobr{◊ic{◊ii{x}->◊ii{y}}},
 потому что так сложнее понимать цепочки преобразований.
-Запись ◊ic{(◊ii{y}"~>◊ii{z}(◊ii{x}"~>◊ii{y} ...))} не~так очевидна, как ◊ic{(◊ii{z}<"~◊ii{y}(◊ii{y}<"~◊ii{x} ...))}.
-Хотя, с~другой стороны, одиночная запись ◊ic{◊ii{z}<"~◊ii{y}} не~так легко читается, как ◊ic{◊ii{y}"~>◊ii{z}}.
+Запись ◊nobr{◊ic{(◊ii{y}->◊ii{z}(◊ii{x}->◊ii{y} ...))}} не~так очевидна, как ◊nobr{◊ic{(◊ii{z}<-◊ii{y}(◊ii{y}<-◊ii{x} ...))}}.
+Хотя, с~другой стороны, одиночная запись ◊nobr{◊ic{◊ii{z}<-◊ii{y}}} не~так легко читается, как ◊nobr{◊ic{◊ii{y}->◊ii{z}}}.
 Приходится~выбирать.}
-вовсе не~переводит ◊ic{exp} сам в~себя;
-она превращает синтаксическую сущность (символ) в~семантическую (переменную).
-В~действительности, переменные — это лишь воображаемые объекты, которым язык и программист дали какие-то имена,
-и которые ради удобства используются в~форме имён.
-Способ представления имён также выбран из соображений удобства, так как Лисп имеет базовый тип символов.
-В~данном случае
-◊ic{symbol->variable} ничего не~делает, хотя на самом деле могла бы применяться
-какая-нибудь другая форма записи имени переменной, например:
-строка, состоящая из знака доллара и имени переменной; в~этом случае, конечно~же, ◊ic{symbol->variable} будет сложнее.
-
-Если бы переменные действительно были лишь воображаемыми, то ◊ic{lookup}
-не~знала~бы как обрабатывать свой первый аргумент, так как она ожидает нечто
-«материальное». Так что нам надо преобразовать переменную в~её программное
-представление, какой-нибудь уникальный ключ, по которому ◊ic{lookup} сможет
-отыскать переменную в~окружении. Так что ещё точнее было~бы записать:
+вовсе не~переводит символ~◊ic{exp} сам в~себя;
+наоборот, она превращает синтаксическую сущность (символ) — в~семантическую (переменную).
+Имена переменных существуют лишь в~языке программирования для удобства программиста;
+если переменную везде переименовать, то поведение программы не~изменится.
+Способ представления имён выбран из соображений удобства, так как Лисп имеет базовый тип символов.
+В~нашем случае ◊ic{symbol->variable} ничего не~делает,
+хотя в~других языках может применяться какая-нибудь другая форма записи имени переменной
+(например, строка, состоящая из знака доллара и имени переменной);
+в~таком случае, конечно~же, ◊ic{symbol->variable} будет несколько сложнее.
+
+Если у~переменных на самом деле нет имён, то как~же ◊ic{lookup} будет их находить в~окружении?
+Вместо переменной как таковой следует использовать её программное представление,
+какой-нибудь уникальный ключ, по которому ◊ic{lookup} сможет отыскать переменную в~окружении.
+Так что ещё точнее было~бы записать:
 
 ◊code:lisp{
 ... (lookup (variable->key (symbol->variable exp)) env) ...
 }
 
-Однако, врождённая лень лисперов настаивает на использовании символов для
-ключей. Так что ◊ic{variable"~>key} — это лишь обратная функция
-к~◊ic{symbol◊discretionary{->}{}{->}variable}, и их последовательное применение
-никак не~изменяет~◊ic{exp}.
-
-◊indexR{автоцитирование}◊indexR{механизм автоцитирования}
-Если выражение атомарное (то~есть не~является списком) и не~является символом,
-то соблазнительно его считать представлением какой-нибудь константы
-с~соответствующим значением. Такое поведение называется механизмом
-◊term{автоцитирования}. Автоцитируемый объект не~требует явного цитирования и
-имеет собственное значение. За примерами можно обратиться к~◊cite{cha96}.
-
-Но является~ли такое поведение правильным? Во-первых, не~всегда атомарные
-объекты обозначают сами себя. Например, строка ◊ic{"a?b:c"} могла~бы означать
-вызов компилятора~Си, затем вызов получившейся программы и подстановку
-возвращаемого ей значения вместо этой строки.
-
-С~другими объектами (вроде функций) вообще не~понятно, как именно их
-◊emph{вычислять}. К~примеру, ясно, что значением переменной ◊ic{car} является
-функция, возвращающая левый элемент пары, но что является значением самой
-функции ◊ii{car}? Чаще всего попытки вычисления значения функции считаются
-ошибочными.
-
-◊indexC{()}◊indexR{пустой список, ◊protect◊ic{()}}
-Другой пример проблемного значения — пустой список~◊ic{()}. Судя по тому, что
-это список, он должен означать вызов функции. Вот только в~нём нет
-ни~аргументов, ни~самой функции. Такая запись в~Scheme запрещена и является
-синтаксической ошибкой.
-
-Поэтому необходимо очень аккуратно анализировать программу и автоцитировать
-только те данные, для которых это явно стоить делать, например: числа, строки
-и~знаки. ◊seePage[basics/evaluating-forms/ssect:quoting] Так что мы записываем
-следующее:
+Однако, врождённая лень лисперов подсказывает, что в~качестве ключей можно использовать символы.
+Получается, что ◊ic{variable->key} — это лишь обратная функция к~◊ic{symbol->variable},
+а~их последовательное применение никак не~изменяет~◊ic{exp}.
+
+◊indexR{автоцитирование}
+◊indexR{механизм автоцитирования}
+Если выражение атомарное (то~есть не~является списком) и~не~является символом,
+то соблазнительно его считать представлением константы с~соответствующим значением.
+Такое поведение называется механизмом ◊term{автоцитирования}.
+Автоцитируемый объект не~требует явного цитирования и имеет собственное значение.
+За~примерами можно обратиться к~◊cite{cha96}.
+
+Но~является~ли такое поведение правильным?
+Во-первых, атомарные объекты не~всегда обозначают сами себя.
+Например, строка ◊ic{"a?b:c"} могла~бы означать вызов компилятора~Си,
+затем исполнение получившейся программы и подстановку возвращаемого ей значения вместо этой~строки.
+
+С~другими объектами (вроде функций) вообще не~понятно, как именно их ◊emph{вычислять}.
+К~примеру, ясно, что значением переменной ◊ic{car} является функция, возвращающая левый элемент пары,
+но что является значением самой ◊emph{функции~◊ii{car}}?
+Чаще всего попытки вычисления значения функции считаются ошибочными.
+
+◊indexC{()}
+◊indexR{пустой список, ◊ic{()}}
+Другой пример проблемного значения — пустой список~◊ic{()}.
+Судя по тому, что это список, он должен означать вызов функции.
+Вот только в~нём нет ни~аргументов, ни~самой функции.
+Такая запись в~Scheme запрещена и считается синтаксической ошибкой.
+
+Поэтому необходимо очень аккуратно анализировать программу
+и автоцитировать только те данные, для которых это явно стоит делать,
+вроде чисел, строк, знаков.
+◊seePage{basics/evaluating-forms/ssect:quoting}
+Так что мы записываем следующее:
 
 ◊code:lisp{
 (define (evaluate exp env)
@@ -138,20 +135,24 @@
 ◊indexR{ошибки!варианты обработки}
 ◊indexC{wrong}
 ◊phantomlabel{basic/atoms/para:the-first-error}
-В~этом фрагменте кода виден первый случай, когда могут возникнуть ошибки.
-Большая часть лисп-систем имеет свои собственные механизмы обработки
-исключительных ситуаций, которые непросто сделать переносимыми. В~случае ошибки
-мы вызываем ◊ic{wrong}◊footnote{Заметьте, не~«функцию ◊ic{wrong}». Варианты её
-реализации подробнее рассматриваются в~разделе~◊ref{compilation/sect:exception}.}
-и передаём ей первым аргументом строку. В~строке находится текстовое описание
-ошибки, а следующие за ней аргументы несут дополнительную информацию о~том, что
-вызвало проблему. Системы с~зачаточным механизмом обработки ошибок обычно
-в~случае проблем выдают какие"~то непонятные надписи вроде ◊ic{"Bus error: core
-dumped"} и умирают. Другие останавливают текущие вычисления и возвращаются
-к~диалоговому режиму. А~третьи могут связывать с~вычисляемым выражением
-специальный обработчик исключений, который перехватит брошенный объект,
-описывающий ошибку, и будет уже по нему решать, что делать дальше.
-◊seePage[compilation/sect:exception] В~некоторых случаях даже реализуется
-подобие экспертной системы, которая анализирует ошибку, вызвавший её код и
-выдаёт пользователю варианты её исправления. В~общем, сложно сказать однозначно,
-что следует делать в~случае ошибки.
+В~исполняемой программе могут быть ошибки,
+которые интерпретатору надо как-то обрабатывать.
+Большинство лисп-систем имеет механизмы обработки исключительных ситуаций,
+но~у~каждой реализации они свои собственные и не~всегда переносимые между реализациями.
+В~случае ошибки мы будем вызывать ◊ic{wrong},
+◊footnote{Заметьте, не~«◊emph{функцию}~◊ic{wrong}».
+Варианты её реализации подробнее рассматриваются в~разделе~◊ref{compilation/sect:exception}.}
+передавая первым аргументом строку.
+В~строке находится текстовое описание ошибки,
+а~следующие аргументы несут дополнительную информацию о~том, что вызвало проблему.
+Системы с~зачаточным механизмом обработки ошибок
+в~случае проблем обычно выдают какие-то непонятные надписи вроде ◊ic{"Bus~error: core~dumped"} и~умирают.
+Другие останавливают текущую работу и возвращаются к~диалоговому режиму.
+А~третьи могут связывать с~вычисляемым выражением специальный обработчик исключений,
+который перехватит объект, описывающий ошибку, и~будет уже по нему решать, что делать дальше.
+◊seePage{compilation/sect:exception}
+В~некоторых случаях даже реализуется подобие экспертной системы,
+которая самостоятельно анализирует ошибку, вызвавший её код,
+и выдаёт пользователю возможные варианты исправления возникшей ситуации.
+Короче говоря, сложно сказать однозначно, что следует делать в~случае~ошибки,
+поэтому пока~что мы будем просто вызывать~◊ic{wrong}.

book-src/index.ptree

@@ -3,4 +3,6 @@
 01_preface.poly
 ◊ch01_basics/00_intro.poly{
  ch01_basics/01_evaluation.poly
+ ch01_basics/02_basic-evaluator.poly
+ ch01_basics/03_evaluating-atoms.poly
 }