├── .gitignore ├── CONTRIBUINDO.md ├── README.md └── capitulos ├── 00-00-prologo.md ├── 00-01-prefacio-primeira-edicao.md ├── 00-02-prefacio-segunda-edicao.md ├── 01-00-construindo-abstracoes-procedimentos.md ├── 01-01-elementos-da-programacao.md ├── 01-02-procedimentos-e-processos.md ├── 01-03-procedimentos-de-alta-ordem.md ├── 02-00-construindo-abstracoes-dados.md ├── 02-01-intro-abstracoes-dados.md ├── 02-02-dados-hierarquicos-clausura.md ├── 02-03-dados-simbolicos.md ├── 02-04-multiplas-representacoes-dados-abstratos.md ├── 02-05-sistemas-operacoes-genericas.md ├── 03-00-modularidade-objetos-estado.md ├── 03-01-atribuicoes-estado-local.md ├── 03-02-modelo-ambiente-avaliacao.md ├── 03-03-modelando-dados-mutaveis.md ├── 03-04-concorrencia.md ├── 03-05-fluxos.md ├── 04-00-abstracao-metalinguistica.md ├── 04-01-avaliador-metacircular.md ├── 04-02-avaliacao-ociosa.md ├── 04-03-computacao-nao-deterministica.md ├── 04-04-programacao-logica.md ├── 05-00-registradores.md ├── 05-01-design-registradores.md ├── 05-02-simulador-registradores.md ├── 05-03-coletor-lixo.md ├── 05-04-avaliador-controle-explicito.md └── 05-05-compilacao.md /.gitignore: -------------------------------------------------------------------------------- 1 | *.ss~ 2 | *.ss#* 3 | .#*.ss 4 | 5 | *.scm~ 6 | *.scm#* 7 | .#*.scm 8 | -------------------------------------------------------------------------------- /CONTRIBUINDO.md: -------------------------------------------------------------------------------- 1 | # Contribuições 2 | 3 | --- 4 | 5 | ## Por onde começar? 6 | 7 | 1. Faça o _fork_ do projeto; 8 | 2. Entenda o fluxo de contribuições; 9 | 3. Leia e pratique as boas práticas; 10 | 11 | --- 12 | 13 | ## Fluxo 14 | 15 | É muito fácil contribuir para o projeto e iniciantes no universo _Open Source_ são mais do que bem-vindas(os)! 16 | 17 | Qualquer tipo de ajuda (seja ela grande ou pequena) é válida e construtiva. Se encontrar qualquer parte do livro que possa ser melhorada, essa é uma grande oportunidade para participar. 18 | 19 | E caso não saiba por onde começar: 20 | 21 | 1. Faça referência ao repositório oficial após o fork 22 | 23 | `git remote add upstream git@github.com:okrdu/sicp-ptbr.git` 24 | 25 | 2. Antes de iniciar o processo de contribuição, crie uma nova branch para fazer suas alterações. 26 | 27 | Alguns exemplos: 28 | 29 | - Para tradução: `git checkout -b traducaoCapX` 30 | - Para revisões: `git checkout -b revisaoCapX` 31 | - Para erros: `git checkout -b correcaoCapX` 32 | 33 | Use qualquer nome que seja coerente com a contribuição que está sendo feita. X representa o número do capítulo. 34 | 35 | 3. Após realizar as alterações, é hora de fazer um commit com uma mensagem coerente do que foi feito. Exemplo: 36 | 37 | `git add --all`
38 | `git commit -am ‘Adiciona tradução/revisão/melhoria capítulo X linha/linhas Y`
39 | `git push origin traducaoCapX`
40 | 41 | 4. Envie um Pull Request com as alterações feitas, fazendo referência para o master do repositório oficial. 42 | 43 | 5. Sua contribuição será analisada pela comunidade. Em alguns casos pediremos algumas alterações antes de dar merge. 44 | 45 | Após o merge: 46 | 47 | Delete a branch utilizada: 48 | 49 | `git checkout master`
50 | `git push origin traducaoCapX`
51 | `git branch -D traducaoCapX` 52 | 53 | Atualize seu repositório com o repositório oficial: 54 | 55 | `git fetch upstream`
56 | `git rebase upstream/master`
57 | `git push -f origin master` 58 | 59 | 6. Quando iniciar uma nova contribuição, inicie repita o processo pelo passo 2. 60 | 61 | --- 62 | 63 | ## Boas Práticas 64 | 65 | - Não traduza termos técnicos e blocos de código 66 | - Antes de enviar sua contribuição, certifique-se de que está enviando apenas um único _commit_ que represente o que foi feito. Caso tenha feito vários commits, [esmague-os](http://gitready.com/advanced/2009/02/10/squashing-commits-with-rebase.html) antes de fazer o _Pull Request_. 67 | - Caso tenha qualquer tipo de dúvida, abra uma _Issue_ que faremos o possível para te ajudar. 68 | - Contribua com as discussões. 69 | - Estrangeirismo: Utilizar o formato itálico. Exemplo: _bug_ 70 | - Sentido Figurado: Sempre destacar com aspas duplas. 71 | - Citação: Aspas duplas com o sinal de >. Exemplo: 72 | > “Foo bar” 73 | - Marcação para código: Utilizar um apóstrofe (`) para indicar um pedaço de código no meio de um texto (var foo = undefined). Ou três apóstrofe com o nome da linguagem de programação na frente (```scheme), para indicar um bloco de código: 74 | 75 | ```scheme 76 | (display "Hello, World!") 77 | ``` 78 | 79 | --- 80 | 81 | _Esse texto é um documento em constante edição, e pode ser alterado no futuro._ 82 | 83 | Um agradecimento especial ao [BrazilJS](https://github.com/braziljs/eloquente-javascript) por possibilitar a adaptação de sua documentação! 84 | 85 | _[<--- Voltar à Página Inicial](https://github.com/okrdu/sicp-ptbr)_ -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | # :carousel_horse: SICP - 2ª EDIÇÃO 2 | 3 |

7 |

8 | 9 | > Tradução do livro Structure and Interpretation of Computer Programs (SICP) - 2ª edição. 10 | 11 | --- 12 | 13 | ## :orange_book: Conteúdo do Livro 14 | 15 | [Prólogo](https://github.com/okrdu/sicp-ptbr/blob/master/capitulos/00-00-prologo.md)
16 | [Prefácio da 1ª Edição](https://github.com/okrdu/sicp-ptbr/blob/master/capitulos/00-01-prefacio-primeira-edicao.md)
17 | [Prefácio da 2ª Edição](https://github.com/okrdu/sicp-ptbr/blob/master/capitulos/00-02-prefacio-segunda-edicao.md)
18 | 19 | 1. [Construindo abstrações com procedimentos](https://github.com/okrdu/sicp-ptbr/blob/master/capitulos/01-00-construindo-abstracoes-procedimentos.md)
20 | 1.1. [Os elementos da programação](https://github.com/okrdu/sicp-ptbr/blob/master/capitulos/01-01-elementos-da-programacao.md)
21 | 1.2. [Procedimentos e os processos que eles geram](https://github.com/okrdu/sicp-ptbr/blob/master/capitulos/01-02-procedimentos-e-processos.md)
22 | 1.3. [Formulando abstrações com Procedimentos de Alta-Ordem](https://github.com/okrdu/sicp-ptbr/blob/master/capitulos/01-03-procedimentos-de-alta-ordem.md)
23 | 2. [Construindo abstrações com dados](https://github.com/okrdu/sicp-ptbr/blob/master/capitulos/02-00-construindo-abstracoes-dados.md)
24 | 2.1. [Introdução à abstração de dados](https://github.com/okrdu/sicp-ptbr/blob/master/capitulos/02-01-intro-abstracoes-dados.md)
25 | 2.2. [Dados hierárquicos e a propriedade de clausura](https://github.com/okrdu/sicp-ptbr/blob/master/capitulos/02-02-dados-hierarquicos-clausura.md)
26 | 2.3. [Dados simbólicos](https://github.com/okrdu/sicp-ptbr/blob/master/capitulos/02-03-dados-simbolicos.md)
27 | 2.4. [Múltiplas representações para dados abstratos](https://github.com/okrdu/sicp-ptbr/blob/master/capitulos/02-04-multiplas-representacoes-dados-abstratos.md)
28 | 2.5. [Sistemas com operações genéricas](https://github.com/okrdu/sicp-ptbr/blob/master/capitulos/02-05-sistemas-operacoes-genericas.md)
29 | 3. [Modularidade, Objetos e Estado](https://github.com/okrdu/sicp-ptbr/blob/master/capitulos/03-00-modularidade-objetos-estado.md)
30 | 3.1. [Atribuições e estado local](https://github.com/okrdu/sicp-ptbr/blob/master/capitulos/03-01-atribuicoes-estado-local.md)
31 | 3.2. [O modelo de ambiente de avaliação](https://github.com/okrdu/sicp-ptbr/blob/master/capitulos/03-02-modelo-ambiente-avaliacao.md)
32 | 3.3. [Modelando com dados mutáveis](https://github.com/okrdu/sicp-ptbr/blob/master/capitulos/03-03-modelando-dados-mutaveis.md)
33 | 3.4. [Concorrência: o tempo é essencial](https://github.com/okrdu/sicp-ptbr/blob/master/capitulos/03-04-concorrencia.md)
34 | 3.5. [Fluxos](https://github.com/okrdu/sicp-ptbr/blob/master/capitulos/03-05-fluxos.md)
35 | 4. [Abstração Metalinguística](https://github.com/okrdu/sicp-ptbr/blob/master/capitulos/04-00-abstracao-metalinguistica.md)
36 | 4.1. [O Avaliador Metacircular](https://github.com/okrdu/sicp-ptbr/blob/master/capitulos/04-01-avaliador-metacircular.md)
37 | 4.2. [Variações em Scheme - Avaliação Ociosa](https://github.com/okrdu/sicp-ptbr/blob/master/capitulos/04-02-avaliacao-ociosa.md)
38 | 4.3. [Variações em Scheme - Computação não determinística](https://github.com/okrdu/sicp-ptbr/blob/master/capitulos/04-03-computacao-nao-deterministica.md)
39 | 4.4. [Programação Lógica](https://github.com/okrdu/sicp-ptbr/blob/master/capitulos/04-04-programacao-logica.md)
40 | 5. [Computação com Registradores](https://github.com/okrdu/sicp-ptbr/blob/master/capitulos/05-00-registradores.md)
41 | 5.1. [O design de registradores](https://github.com/okrdu/sicp-ptbr/blob/master/capitulos/05-01-design-registradores.md)
42 | 5.2. [O simulador de registradores](https://github.com/okrdu/sicp-ptbr/blob/master/capitulos/05-02-simulador-registradores.md)
43 | 5.3. [Alocação de memória e o Coletor de Lixo](https://github.com/okrdu/sicp-ptbr/blob/master/capitulos/05-03-coletor-lixo.md)
44 | 5.4. [O avaliador de controle explícito](https://github.com/okrdu/sicp-ptbr/blob/master/capitulos/05-04-avaliador-controle-explicito.md)
45 | 5.5. [Compilação](https://github.com/okrdu/sicp-ptbr/blob/master/capitulos/05-05-compilacao.md)
46 | 47 | --- 48 | 49 | ## :hearts: Como contribuir?! 50 | 51 | Se você tiver interesse em ajudar, por gentileza, leia o [guia de contribuições](https://github.com/okrdu/sicp-ptbr/blob/master/CONTRIBUINDO.md). 52 | 53 | Se tiver qualquer dúvida, basta abrir uma issue. 54 | 55 | Você pode verificar o status geral do projeto na [seguinte issue](https://github.com/okrdu/sicp-ptbr/issues/31) e no presente [board](https://github.com/okrdu/sicp-ptbr/projects/1). 56 | 57 | --- 58 | 59 | ## :page_facing_up: Licenciamento 60 | 61 | - Autores(as): _Harold Abelson, Gerald Jay Sussman e Julie Sussman_; 62 | - [Versão Original desse Livro](https://mitpress.mit.edu/sites/default/files/sicp/index.html); 63 | 64 | O [presente livro](https://github.com/okrdu/sicp-ptbr) é licenciado sob a [CC BY-SA 4.0 (Atribuição-CompartilhaIgual 4.0 Internacional)](https://creativecommons.org/licenses/by-sa/4.0/deed.pt_BR) pela [MIT Press](https://mitpress.mit.edu/). 65 | 66 | ![Creative Commons Atribuição-CompartilhaIgual 4.0](https://licensebuttons.net/l/by-sa/4.0/88x31.png) 67 | -------------------------------------------------------------------------------- /capitulos/00-00-prologo.md: -------------------------------------------------------------------------------- 1 | # PRÓLOGO 2 | 3 | > Este livro é dedicado, com respeito e admiração, ao espírito que reside no computador. 4 | > 5 | > Acredito que é extremamente importante que nós, cientistas da computação, continuemos nos divertindo ao computar. Quando tudo começou, era muito divertido. É claro que alguns clientes foram enganados de vez em quando, e, depois de um tempo até começamos a levar as reclamações à sério. Começamos a nos sentir como se fôssemos realmente responsáveis pelo uso perfeito e bem-sucedido dessas máquinas. Eu não acho que somos. Acredito que nós somos responsáveis por sua expansão, colocando-as em novas direções e mantendo o processo divertido. 6 | > 7 | > Espero que o campo da Ciência da Computação nunca perca seu senso de diversão. Acima de tudo, espero que não nos tornemos missionários(as). Não se sinta como se você fosse um(a) vendedor(a) de bíblias. O mundo já está lotado de pessoas assim. 8 | > 9 | > O que você sabe sobre computação, outras pessoas aprenderão. Não se sinta como se a chave para uma computação bem-sucedida esteja apenas em suas mãos. O que eu espero que esteja contigo é inteligência: a habilidade para ver a máquina como algo além do que quando você a encontrou, como se você pudesse torná-la ainda melhor. 10 | > 11 | > -- Alan J. Perlis (Abril 1, 1922 - Fevereiro 7, 1990) 12 | 13 | --- 14 | 15 |

16 | 17 | 18 | 19 | 20 | 21 | 22 |

-------------------------------------------------------------------------------- /capitulos/00-01-prefacio-primeira-edicao.md: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/has256/sicp-ptbr/856d0fd1f262ee49522e544a13a912301c9e52b8/capitulos/00-01-prefacio-primeira-edicao.md -------------------------------------------------------------------------------- /capitulos/00-02-prefacio-segunda-edicao.md: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/has256/sicp-ptbr/856d0fd1f262ee49522e544a13a912301c9e52b8/capitulos/00-02-prefacio-segunda-edicao.md -------------------------------------------------------------------------------- /capitulos/01-00-construindo-abstracoes-procedimentos.md: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/has256/sicp-ptbr/856d0fd1f262ee49522e544a13a912301c9e52b8/capitulos/01-00-construindo-abstracoes-procedimentos.md -------------------------------------------------------------------------------- /capitulos/02-00-construindo-abstracoes-dados.md: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/has256/sicp-ptbr/856d0fd1f262ee49522e544a13a912301c9e52b8/capitulos/02-00-construindo-abstracoes-dados.md -------------------------------------------------------------------------------- /capitulos/02-01-intro-abstracoes-dados.md: -------------------------------------------------------------------------------- 1 | # 2.1 Introduction to Data Abstraction 2 | 3 | In [1.1.8](1_002e1.xhtml#g_t1_002e1_002e8), we noted that a procedure used as an element in creating a more complex procedure could be regarded not only as a collection of particular operations but also as a procedural abstraction. That is, the details of how the procedure was implemented could be suppressed, and the particular procedure itself could be replaced by any other procedure with the same overall behavior. In other words, we could make an abstraction that would separate the way the procedure would be used from the details of how the procedure would be implemented in terms of more primitive procedures. The analogous notion for compound data is called *data abstraction*. Data abstraction is a methodology that enables us to isolate how a compound data object is used from the details of how it is constructed from more primitive data objects. 4 | 5 | The basic idea of data abstraction is to structure the programs that are to use compound data objects so that they operate on “abstract data.” That is, our programs should use data in such a way as to make no assumptions about the data that are not strictly necessary for performing the task at hand. At the same time, a “concrete” data representation is defined independent of the programs that use the data. The interface between these two parts of our system will be a set of procedures, called *selectors* and *constructors*, that implement the abstract data in terms of the concrete representation. To illustrate this technique, we will consider how to design a set of procedures for manipulating rational numbers. 6 | 7 | 8 | ## 2.1.1 Example: Arithmetic Operations for Rational Numbers 9 | 10 | Suppose we want to do arithmetic with rational numbers. We want to be able to add, subtract, multiply, and divide them and to test whether two rational numbers are equal. 11 | 12 | Let us begin by assuming that we already have a way of constructing a rational number from a numerator and a denominator. We also assume that, given a rational number, we have a way of extracting (or selecting) its numerator and its denominator. Let us further assume that the constructor and selectors are available as procedures: 13 | 14 | - `(make-rat ⟨n⟩ ⟨d⟩)` returns the rational number whose numerator is the integer `⟨n⟩` and whose denominator is the integer `⟨d⟩`. 15 | - `(numer ⟨x⟩)` returns the numerator of the rational number `⟨x⟩`. 16 | - `(denom ⟨x⟩)` returns the denominator of the rational number `⟨x⟩`. 17 | 18 | We are using here a powerful strategy of synthesis: *wishful thinking*. We haven’t yet said how a rational number is represented, or how the procedures `numer`, `denom`, and `make-rat` should be implemented. Even so, if we did have these three procedures, we could then add, subtract, multiply, divide, and test equality by using the following relations: 19 | 20 | $$\begin{array}{lll} 21 | {\frac{n_{1}}{d_{1}} + \frac{n_{2}}{d_{2}}} & = & {\frac{n_{1}d_{2} + n_{2}d_{1}}{d_{1}d_{2}},} \\ 22 | {\frac{n_{1}}{d_{1}} - \frac{n_{2}}{d_{2}}} & = & {\frac{n_{1}d_{2} - n_{2}d_{1}}{d_{1}d_{2}},} \\ 23 | {\frac{n_{1}}{d_{1}} \times \frac{n_{2}}{d_{2}}} & = & {\frac{n_{1}n_{2}}{d_{1}d_{2}},} \\ 24 | \frac{n_{1}\,/\, d_{1}}{n_{2}\,/\, d_{2}} & = & {\frac{n_{1}d_{2}}{d_{1}n_{2}},} \\ 25 | \frac{n_{1}}{d_{1}} & = & {\frac{n_{2}}{d_{2}}\quad{\ if\ and\ only\ if\quad}n_{1}d_{2} = n_{2}d_{1}.} \\ 26 | \end{array}$$ 27 | 28 | We can express these rules as procedures: 29 | 30 | ``` {.scheme} 31 | (define (add-rat x y) 32 | (make-rat (+ (* (numer x) (denom y)) 33 | (* (numer y) (denom x))) 34 | (* (denom x) (denom y)))) 35 | 36 | (define (sub-rat x y) 37 | (make-rat (- (* (numer x) (denom y)) 38 | (* (numer y) (denom x))) 39 | (* (denom x) (denom y)))) 40 | 41 | (define (mul-rat x y) 42 | (make-rat (* (numer x) (numer y)) 43 | (* (denom x) (denom y)))) 44 | 45 | (define (div-rat x y) 46 | (make-rat (* (numer x) (denom y)) 47 | (* (denom x) (numer y)))) 48 | 49 | (define (equal-rat? x y) 50 | (= (* (numer x) (denom y)) 51 | (* (numer y) (denom x)))) 52 | ``` 53 | 54 | Now we have the operations on rational numbers defined in terms of the selector and constructor procedures `numer`, `denom`, and `make-rat`. But we haven’t yet defined these. What we need is some way to glue together a numerator and a denominator to form a rational number. 55 | 56 | 57 | ### Pairs 58 | 59 | To enable us to implement the concrete level of our data abstraction, our language provides a compound structure called a *pair*, which can be constructed with the primitive procedure `cons`. This procedure takes two arguments and returns a compound data object that contains the two arguments as parts. Given a pair, we can extract the parts using the primitive procedures `car` and `cdr`.^[The name `cons` stands for “construct.” The names `car` and `cdr` derive from the original implementation of Lisp on the IBM 704. That machine had an addressing scheme that allowed one to reference the “address” and “decrement” parts of a memory location. `Car` stands for “Contents of Address part of Register” and `cdr` (pronounced “could-er”) stands for “Contents of Decrement part of Register.”] Thus, we can use `cons`, `car`, and `cdr` as follows: 60 | 61 | ``` {.scheme} 62 | (define x (cons 1 2)) 63 | 64 | (car x) 65 | 1 66 | 67 | (cdr x) 68 | 2 69 | ``` 70 | 71 | Notice that a pair is a data object that can be given a name and manipulated, just like a primitive data object. Moreover, `cons` can be used to form pairs whose elements are pairs, and so on: 72 | 73 | ``` {.scheme} 74 | (define x (cons 1 2)) 75 | (define y (cons 3 4)) 76 | (define z (cons x y)) 77 | 78 | (car (car z)) 79 | 1 80 | 81 | (car (cdr z)) 82 | 3 83 | ``` 84 | 85 | In [2.2](2_002e2.xhtml#g_t2_002e2) we will see how this ability to combine pairs means that pairs can be used as general-purpose building blocks to create all sorts of complex data structures. The single compound-data primitive *pair*, implemented by the procedures `cons`, `car`, and `cdr`, is the only glue we need. Data objects constructed from pairs are called *list-structured* data. 86 | 87 | 88 | ### Representing rational numbers 89 | 90 | Pairs offer a natural way to complete the rational-number system. Simply represent a rational number as a pair of two integers: a numerator and a denominator. Then `make-rat`, `numer`, and `denom` are readily implemented as follows:^[Another way to define the selectors and constructor is] 91 | 92 | ``` {.scheme} 93 | (define (make-rat n d) (cons n d)) 94 | (define (numer x) (car x)) 95 | (define (denom x) (cdr x)) 96 | ``` 97 | 98 | Also, in order to display the results of our computations, we can print rational numbers by printing the numerator, a slash, and the denominator:^[`Display` is the Scheme primitive for printing data. The Scheme primitive `newline` starts a new line for printing. Neither of these procedures returns a useful value, so in the uses of `print-rat` below, we show only what `print-rat` prints, not what the interpreter prints as the value returned by `print-rat`.] 99 | 100 | ``` {.scheme} 101 | (define (print-rat x) 102 | (newline) 103 | (display (numer x)) 104 | (display "/") 105 | (display (denom x))) 106 | ``` 107 | 108 | Now we can try our rational-number procedures: 109 | 110 | ``` {.scheme} 111 | (define one-half (make-rat 1 2)) 112 | (print-rat one-half) 113 | 1/2 114 | 115 | (define one-third (make-rat 1 3)) 116 | (print-rat 117 | (add-rat one-half one-third)) 118 | 5/6 119 | 120 | (print-rat 121 | (mul-rat one-half one-third)) 122 | 1/6 123 | 124 | (print-rat 125 | (add-rat one-third one-third)) 126 | 6/9 127 | ``` 128 | 129 | As the final example shows, our rational-number implementation does not reduce rational numbers to lowest terms. We can remedy this by changing `make-rat`. If we have a `gcd` procedure like the one in [1.2.5](1_002e2.xhtml#g_t1_002e2_002e5) that produces the greatest common divisor of two integers, we can use `gcd` to reduce the numerator and the denominator to lowest terms before constructing the pair: 130 | 131 | ``` {.scheme} 132 | (define (make-rat n d) 133 | (let ((g (gcd n d))) 134 | (cons (/ n g) 135 | (/ d g)))) 136 | ``` 137 | 138 | Now we have 139 | 140 | ``` {.scheme} 141 | (print-rat 142 | (add-rat one-third one-third)) 143 | 2/3 144 | ``` 145 | 146 | as desired. This modification was accomplished by changing the constructor `make-rat` without changing any of the procedures (such as `add-rat` and `mul-rat`) that implement the actual operations. 147 | 148 | **Exercise 2.1:** Define a better version of `make-rat` that handles both positive and negative arguments. `Make-rat` should normalize the sign so that if the rational number is positive, both the numerator and denominator are positive, and if the rational number is negative, only the numerator is negative. 149 | 150 | 151 | ## 2.1.2 Abstraction Barriers 152 | 153 | Before continuing with more examples of compound data and data abstraction, let us consider some of the issues raised by the rational-number example. We defined the rational-number operations in terms of a constructor `make-rat` and selectors `numer` and `denom`. In general, the underlying idea of data abstraction is to identify for each type of data object a basic set of operations in terms of which all manipulations of data objects of that type will be expressed, and then to use only those operations in manipulating the data. 154 | 155 | We can envision the structure of the rational-number system as shown in [Figure 2.1](#Figure-2_002e1). The horizontal lines represent *abstraction barriers* that isolate different “levels” of the system. At each level, the barrier separates the programs (above) that use the data abstraction from the programs (below) that implement the data abstraction. Programs that use rational numbers manipulate them solely in terms of the procedures supplied “for public use” by the rational-number package: `add-rat`, `sub-rat`, `mul-rat`, `div-rat`, and `equal-rat?`. These, in turn, are implemented solely in terms of the constructor and selectors `make-rat`, `numer`, and `denom`, which themselves are implemented in terms of pairs. The details of how pairs are implemented are irrelevant to the rest of the rational-number package so long as pairs can be manipulated by the use of `cons`, `car`, and `cdr`. In effect, procedures at each level are the interfaces that define the abstraction barriers and connect the different levels. 156 | 157 | ![](fig/chap2/Fig2.1d.std.svg 586.44x456.96) 158 | **Figure 2.1:** Data-abstraction barriers in the rational-number package. 159 | 160 | This simple idea has many advantages. One advantage is that it makes programs much easier to maintain and to modify. Any complex data structure can be represented in a variety of ways with the primitive data structures provided by a programming language. Of course, the choice of representation influences the programs that operate on it; thus, if the representation were to be changed at some later time, all such programs might have to be modified accordingly. This task could be time-consuming and expensive in the case of large programs unless the dependence on the representation were to be confined by design to a very few program modules. 161 | 162 | For example, an alternate way to address the problem of reducing rational numbers to lowest terms is to perform the reduction whenever we access the parts of a rational number, rather than when we construct it. This leads to different constructor and selector procedures: 163 | 164 | ``` {.scheme} 165 | (define (make-rat n d) 166 | (cons n d)) 167 | 168 | (define (numer x) 169 | (let ((g (gcd (car x) (cdr x)))) 170 | (/ (car x) g))) 171 | 172 | (define (denom x) 173 | (let ((g (gcd (car x) (cdr x)))) 174 | (/ (cdr x) g))) 175 | ``` 176 | 177 | The difference between this implementation and the previous one lies in when we compute the `gcd`. If in our typical use of rational numbers we access the numerators and denominators of the same rational numbers many times, it would be preferable to compute the `gcd` when the rational numbers are constructed. If not, we may be better off waiting until access time to compute the `gcd`. In any case, when we change from one representation to the other, the procedures `add-rat`, `sub-rat`, and so on do not have to be modified at all. 178 | 179 | Constraining the dependence on the representation to a few interface procedures helps us design programs as well as modify them, because it allows us to maintain the flexibility to consider alternate implementations. To continue with our simple example, suppose we are designing a rational-number package and we can’t decide initially whether to perform the `gcd` at construction time or at selection time. The data-abstraction methodology gives us a way to defer that decision without losing the ability to make progress on the rest of the system. 180 | 181 | **Exercise 2.2:** Consider the problem of representing line segments in a plane. Each segment is represented as a pair of points: a starting point and an ending point. Define a constructor `make-segment` and selectors `start-segment` and `end-segment` that define the representation of segments in terms of points. Furthermore, a point can be represented as a pair of numbers: the $x$ coordinate and the $y$ coordinate. Accordingly, specify a constructor `make-point` and selectors `x-point` and `y-point` that define this representation. Finally, using your selectors and constructors, define a procedure `midpoint-segment` that takes a line segment as argument and returns its midpoint (the point whose coordinates are the average of the coordinates of the endpoints). To try your procedures, you’ll need a way to print points: 182 | 183 | 184 | ``` {.scheme} 185 | (define (print-point p) 186 | (newline) 187 | (display "(") 188 | (display (x-point p)) 189 | (display ",") 190 | (display (y-point p)) 191 | (display ")")) 192 | ``` 193 | 194 | 195 | **Exercise 2.3:** Implement a representation for rectangles in a plane. (Hint: You may want to make use of [Exercise 2.2](#Exercise-2_002e2).) In terms of your constructors and selectors, create procedures that compute the perimeter and the area of a given rectangle. Now implement a different representation for rectangles. Can you design your system with suitable abstraction barriers, so that the same perimeter and area procedures will work using either representation? 196 | 197 | 198 | ## 2.1.3 What Is Meant by Data? 199 | 200 | We began the rational-number implementation in [2.1.1](#g_t2_002e1_002e1) by implementing the rational-number operations `add-rat`, `sub-rat`, and so on in terms of three unspecified procedures: `make-rat`, `numer`, and `denom`. At that point, we could think of the operations as being defined in terms of data objects—numerators, denominators, and rational numbers—whose behavior was specified by the latter three procedures. 201 | 202 | But exactly what is meant by *data*? It is not enough to say “whatever is implemented by the given selectors and constructors.” Clearly, not every arbitrary set of three procedures can serve as an appropriate basis for the rational-number implementation. We need to guarantee that, if we construct a rational number `x` from a pair of integers `n` and `d`, then extracting the `numer` and the `denom` of `x` and dividing them should yield the same result as dividing `n` by `d`. In other words, `make-rat`, `numer`, and `denom` must satisfy the condition that, for any integer `n` and any non-zero integer `d`, if `x` is `(make-rat n d)`, then 203 | 204 | $$\frac{\text{(numer\ x)}}{\text{(denom\ x)}} = {\frac{\text{n}}{\text{d}}.}$$ 205 | 206 | In fact, this is the only condition `make-rat`, `numer`, and `denom` must fulfill in order to form a suitable basis for a rational-number representation. In general, we can think of data as defined by some collection of selectors and constructors, together with specified conditions that these procedures must fulfill in order to be a valid representation.^[Surprisingly, this idea is very difficult to formulate rigorously. There are two approaches to giving such a formulation. One, pioneered by C. A. R. [Hoare (1972)](References.xhtml#Hoare-_00281972_0029), is known as the method of *abstract models*. It formalizes the “procedures plus conditions” specification as outlined in the rational-number example above. Note that the condition on the rational-number representation was stated in terms of facts about integers (equality and division). In general, abstract models define new kinds of data objects in terms of previously defined types of data objects. Assertions about data objects can therefore be checked by reducing them to assertions about previously defined data objects. Another approach, introduced by Zilles at MIT, by Goguen, Thatcher, Wagner, and Wright at IBM (see [Thatcher et al. 1978](References.xhtml#Thatcher-et-al_002e-1978)), and by Guttag at Toronto (see [Guttag 1977](References.xhtml#Guttag-1977)), is called *algebraic specification*. It regards the “procedures” as elements of an abstract algebraic system whose behavior is specified by axioms that correspond to our “conditions,” and uses the techniques of abstract algebra to check assertions about data objects. Both methods are surveyed in the paper by [Liskov and Zilles (1975)](References.xhtml#Liskov-and-Zilles-_00281975_0029).] 207 | 208 | This point of view can serve to define not only “high-level” data objects, such as rational numbers, but lower-level objects as well. Consider the notion of a pair, which we used in order to define our rational numbers. We never actually said what a pair was, only that the language supplied procedures `cons`, `car`, and `cdr` for operating on pairs. But the only thing we need to know about these three operations is that if we glue two objects together using `cons` we can retrieve the objects using `car` and `cdr`. That is, the operations satisfy the condition that, for any objects `x` and `y`, if `z` is `(cons x y)` then `(car z)` is `x` and `(cdr z)` is `y`. Indeed, we mentioned that these three procedures are included as primitives in our language. However, any triple of procedures that satisfies the above condition can be used as the basis for implementing pairs. This point is illustrated strikingly by the fact that we could implement `cons`, `car`, and `cdr` without using any data structures at all but only using procedures. Here are the definitions: 209 | 210 | ``` {.scheme} 211 | (define (cons x y) 212 | (define (dispatch m) 213 | (cond ((= m 0) x) 214 | ((= m 1) y) 215 | (else 216 | (error "Argument not 0 or 1: 217 | CONS" m)))) 218 | dispatch) 219 | 220 | (define (car z) (z 0)) 221 | (define (cdr z) (z 1)) 222 | ``` 223 | 224 | This use of procedures corresponds to nothing like our intuitive notion of what data should be. Nevertheless, all we need to do to show that this is a valid way to represent pairs is to verify that these procedures satisfy the condition given above. 225 | 226 | The subtle point to notice is that the value returned by `(cons x y)` is a procedure—namely the internally defined procedure `dispatch`, which takes one argument and returns either `x` or `y` depending on whether the argument is 0 or 1. Correspondingly, `(car z)` is defined to apply `z` to 0. Hence, if `z` is the procedure formed by `(cons x y)`, then `z` applied to 0 will yield `x`. Thus, we have shown that `(car (cons x y))` yields `x`, as desired. Similarly, `(cdr (cons x y))` applies the procedure returned by `(cons x y)` to 1, which returns `y`. Therefore, this procedural implementation of pairs is a valid implementation, and if we access pairs using only `cons`, `car`, and `cdr` we cannot distinguish this implementation from one that uses “real” data structures. 227 | 228 | The point of exhibiting the procedural representation of pairs is not that our language works this way (Scheme, and Lisp systems in general, implement pairs directly, for efficiency reasons) but that it could work this way. The procedural representation, although obscure, is a perfectly adequate way to represent pairs, since it fulfills the only conditions that pairs need to fulfill. This example also demonstrates that the ability to manipulate procedures as objects automatically provides the ability to represent compound data. This may seem a curiosity now, but procedural representations of data will play a central role in our programming repertoire. This style of programming is often called *message passing*, and we will be using it as a basic tool in [Chapter 3](Chapter-3.xhtml#Chapter-3) when we address the issues of modeling and simulation. 229 | 230 | **Exercise 2.4:** Here is an alternative procedural representation of pairs. For this representation, verify that `(car (cons x y))` yields `x` for any objects `x` and `y`. 231 | 232 | 233 | ``` {.scheme} 234 | (define (cons x y) 235 | (lambda (m) (m x y))) 236 | 237 | (define (car z) 238 | (z (lambda (p q) p))) 239 | ``` 240 | 241 | 242 | What is the corresponding definition of `cdr`? (Hint: To verify that this works, make use of the substitution model of [1.1.5](1_002e1.xhtml#g_t1_002e1_002e5).) 243 | 244 | **Exercise 2.5:** Show that we can represent pairs of nonnegative integers using only numbers and arithmetic operations if we represent the pair $a$ and $b$ as the integer that is the product $2^{a}3^{b}$. Give the corresponding definitions of the procedures `cons`, `car`, and `cdr`. 245 | 246 | **Exercise 2.6:** In case representing pairs as procedures wasn’t mind-boggling enough, consider that, in a language that can manipulate procedures, we can get by without numbers (at least insofar as nonnegative integers are concerned) by implementing 0 and the operation of adding 1 as 247 | 248 | 249 | ``` {.scheme} 250 | (define zero (lambda (f) (lambda (x) x))) 251 | 252 | (define (add-1 n) 253 | (lambda (f) (lambda (x) (f ((n f) x))))) 254 | ``` 255 | 256 | 257 | This representation is known as *Church numerals*, after its inventor, Alonzo Church, the logician who invented the λ-calculus. 258 | 259 | Define `one` and `two` directly (not in terms of `zero` and `add-1`). (Hint: Use substitution to evaluate `(add-1 zero)`). Give a direct definition of the addition procedure `+` (not in terms of repeated application of `add-1`). 260 | 261 | 262 | ## 2.1.4 Extended Exercise: Interval Arithmetic 263 | 264 | Alyssa P. Hacker is designing a system to help people solve engineering problems. One feature she wants to provide in her system is the ability to manipulate inexact quantities (such as measured parameters of physical devices) with known precision, so that when computations are done with such approximate quantities the results will be numbers of known precision. 265 | 266 | Electrical engineers will be using Alyssa’s system to compute electrical quantities. It is sometimes necessary for them to compute the value of a parallel equivalent resistance $R_{p}$ of two resistors $R_{1}$ and $R_{2}$ using the formula 267 | 268 | $$R_{p}\, = \,{\frac{1}{1/R_{1} + 1/R_{2}}.}$$ 269 | 270 | Resistance values are usually known only up to some tolerance guaranteed by the manufacturer of the resistor. For example, if you buy a resistor labeled “6.8 ohms with 10% tolerance” you can only be sure that the resistor has a resistance between 6.8 $-$ 0.68 = 6.12 and 6.8 + 0.68 = 7.48 ohms. Thus, if you have a 6.8-ohm 10% resistor in parallel with a 4.7-ohm 5% resistor, the resistance of the combination can range from about 2.58 ohms (if the two resistors are at the lower bounds) to about 2.97 ohms (if the two resistors are at the upper bounds). 271 | 272 | Alyssa’s idea is to implement “interval arithmetic” as a set of arithmetic operations for combining “intervals” (objects that represent the range of possible values of an inexact quantity). The result of adding, subtracting, multiplying, or dividing two intervals is itself an interval, representing the range of the result. 273 | 274 | Alyssa postulates the existence of an abstract object called an “interval” that has two endpoints: a lower bound and an upper bound. She also presumes that, given the endpoints of an interval, she can construct the interval using the data constructor `make-interval`. Alyssa first writes a procedure for adding two intervals. She reasons that the minimum value the sum could be is the sum of the two lower bounds and the maximum value it could be is the sum of the two upper bounds: 275 | 276 | ``` {.scheme} 277 | (define (add-interval x y) 278 | (make-interval (+ (lower-bound x) 279 | (lower-bound y)) 280 | (+ (upper-bound x) 281 | (upper-bound y)))) 282 | ``` 283 | 284 | Alyssa also works out the product of two intervals by finding the minimum and the maximum of the products of the bounds and using them as the bounds of the resulting interval. (`Min` and `max` are primitives that find the minimum or maximum of any number of arguments.) 285 | 286 | ``` {.scheme} 287 | (define (mul-interval x y) 288 | (let ((p1 (* (lower-bound x) 289 | (lower-bound y))) 290 | (p2 (* (lower-bound x) 291 | (upper-bound y))) 292 | (p3 (* (upper-bound x) 293 | (lower-bound y))) 294 | (p4 (* (upper-bound x) 295 | (upper-bound y)))) 296 | (make-interval (min p1 p2 p3 p4) 297 | (max p1 p2 p3 p4)))) 298 | ``` 299 | 300 | To divide two intervals, Alyssa multiplies the first by the reciprocal of the second. Note that the bounds of the reciprocal interval are the reciprocal of the upper bound and the reciprocal of the lower bound, in that order. 301 | 302 | ``` {.scheme} 303 | (define (div-interval x y) 304 | (mul-interval x 305 | (make-interval 306 | (/ 1.0 (upper-bound y)) 307 | (/ 1.0 (lower-bound y))))) 308 | ``` 309 | 310 | **Exercise 2.7:** Alyssa’s program is incomplete because she has not specified the implementation of the interval abstraction. Here is a definition of the interval constructor: 311 | 312 | 313 | ``` {.scheme} 314 | (define (make-interval a b) (cons a b)) 315 | ``` 316 | 317 | 318 | Define selectors `upper-bound` and `lower-bound` to complete the implementation. 319 | 320 | **Exercise 2.8:** Using reasoning analogous to Alyssa’s, describe how the difference of two intervals may be computed. Define a corresponding subtraction procedure, called `sub-interval`. 321 | 322 | **Exercise 2.9:** The *width* of an interval is half of the difference between its upper and lower bounds. The width is a measure of the uncertainty of the number specified by the interval. For some arithmetic operations the width of the result of combining two intervals is a function only of the widths of the argument intervals, whereas for others the width of the combination is not a function of the widths of the argument intervals. Show that the width of the sum (or difference) of two intervals is a function only of the widths of the intervals being added (or subtracted). Give examples to show that this is not true for multiplication or division. 323 | 324 | **Exercise 2.10:** Ben Bitdiddle, an expert systems programmer, looks over Alyssa’s shoulder and comments that it is not clear what it means to divide by an interval that spans zero. Modify Alyssa’s code to check for this condition and to signal an error if it occurs. 325 | 326 | **Exercise 2.11:** In passing, Ben also cryptically comments: “By testing the signs of the endpoints of the intervals, it is possible to break `mul-interval` into nine cases, only one of which requires more than two multiplications.” Rewrite this procedure using Ben’s suggestion. 327 | 328 | After debugging her program, Alyssa shows it to a potential user, who complains that her program solves the wrong problem. He wants a program that can deal with numbers represented as a center value and an additive tolerance; for example, he wants to work with intervals such as 3.5 $\pm$ 0.15 rather than \[3.35, 3.65\]. Alyssa returns to her desk and fixes this problem by supplying an alternate constructor and alternate selectors: 329 | 330 | 331 | ``` {.scheme} 332 | (define (make-center-width c w) 333 | (make-interval (- c w) (+ c w))) 334 | 335 | (define (center i) 336 | (/ (+ (lower-bound i) 337 | (upper-bound i)) 338 | 2)) 339 | 340 | (define (width i) 341 | (/ (- (upper-bound i) 342 | (lower-bound i)) 343 | 2)) 344 | ``` 345 | 346 | 347 | Unfortunately, most of Alyssa’s users are engineers. Real engineering situations usually involve measurements with only a small uncertainty, measured as the ratio of the width of the interval to the midpoint of the interval. Engineers usually specify percentage tolerances on the parameters of devices, as in the resistor specifications given earlier. 348 | 349 | **Exercise 2.12:** Define a constructor `make-center-percent` that takes a center and a percentage tolerance and produces the desired interval. You must also define a selector `percent` that produces the percentage tolerance for a given interval. The `center` selector is the same as the one shown above. 350 | 351 | **Exercise 2.13:** Show that under the assumption of small percentage tolerances there is a simple formula for the approximate percentage tolerance of the product of two intervals in terms of the tolerances of the factors. You may simplify the problem by assuming that all numbers are positive. 352 | 353 | After considerable work, Alyssa P. Hacker delivers her finished system. Several years later, after she has forgotten all about it, she gets a frenzied call from an irate user, Lem E. Tweakit. It seems that Lem has noticed that the formula for parallel resistors can be written in two algebraically equivalent ways: 354 | 355 | $$\frac{R_{1}R_{2}}{R_{1} + R_{2}}$$ 356 | 357 | and 358 | 359 | $$\frac{1}{1/R_{1} + 1/R_{2}}.$$ 360 | 361 | He has written the following two programs, each of which computes the parallel-resistors formula differently: 362 | 363 | 364 | ``` {.scheme} 365 | (define (par1 r1 r2) 366 | (div-interval 367 | (mul-interval r1 r2) 368 | (add-interval r1 r2))) 369 | 370 | (define (par2 r1 r2) 371 | (let ((one (make-interval 1 1))) 372 | (div-interval 373 | one 374 | (add-interval 375 | (div-interval one r1) 376 | (div-interval one r2))))) 377 | ``` 378 | 379 | 380 | Lem complains that Alyssa’s program gives different answers for the two ways of computing. This is a serious complaint. 381 | 382 | **Exercise 2.14:** Demonstrate that Lem is right. Investigate the behavior of the system on a variety of arithmetic expressions. Make some intervals $A$ and $B$, and use them in computing the expressions $A/A$ and $A/B$. You will get the most insight by using intervals whose width is a small percentage of the center value. Examine the results of the computation in center-percent form (see [Exercise 2.12](#Exercise-2_002e12)). 383 | 384 | **Exercise 2.15:** Eva Lu Ator, another user, has also noticed the different intervals computed by different but algebraically equivalent expressions. She says that a formula to compute with intervals using Alyssa’s system will produce tighter error bounds if it can be written in such a form that no variable that represents an uncertain number is repeated. Thus, she says, `par2` is a “better” program for parallel resistances than `par1`. Is she right? Why? 385 | 386 | **Exercise 2.16:** Explain, in general, why equivalent algebraic expressions may lead to different answers. Can you devise an interval-arithmetic package that does not have this shortcoming, or is this task impossible? (Warning: This problem is very difficult.) 387 | -------------------------------------------------------------------------------- /capitulos/02-04-multiplas-representacoes-dados-abstratos.md: -------------------------------------------------------------------------------- 1 | # 2.4 Multiple Representations for Abstract Data 2 | 3 | We have introduced data abstraction, a methodology for structuring systems in such a way that much of a program can be specified independent of the choices involved in implementing the data objects that the program manipulates. For example, we saw in [2.1.1](2_002e1.xhtml#g_t2_002e1_002e1) how to separate the task of designing a program that uses rational numbers from the task of implementing rational numbers in terms of the computer language’s primitive mechanisms for constructing compound data. The key idea was to erect an abstraction barrier – in this case, the selectors and constructors for rational numbers (`make-rat`, `numer`, `denom`)—that isolates the way rational numbers are used from their underlying representation in terms of list structure. A similar abstraction barrier isolates the details of the procedures that perform rational arithmetic (`add-rat`, `sub-rat`, `mul-rat`, and `div-rat`) from the “higher-level” procedures that use rational numbers. The resulting program has the structure shown in [Figure 2.1](2_002e1.xhtml#Figure-2_002e1). 4 | 5 | These data-abstraction barriers are powerful tools for controlling complexity. By isolating the underlying representations of data objects, we can divide the task of designing a large program into smaller tasks that can be performed separately. But this kind of data abstraction is not yet powerful enough, because it may not always make sense to speak of “the underlying representation” for a data object. 6 | 7 | For one thing, there might be more than one useful representation for a data object, and we might like to design systems that can deal with multiple representations. To take a simple example, complex numbers may be represented in two almost equivalent ways: in rectangular form (real and imaginary parts) and in polar form (magnitude and angle). Sometimes rectangular form is more appropriate and sometimes polar form is more appropriate. Indeed, it is perfectly plausible to imagine a system in which complex numbers are represented in both ways, and in which the procedures for manipulating complex numbers work with either representation. 8 | 9 | More importantly, programming systems are often designed by many people working over extended periods of time, subject to requirements that change over time. In such an environment, it is simply not possible for everyone to agree in advance on choices of data representation. So in addition to the data-abstraction barriers that isolate representation from use, we need abstraction barriers that isolate different design choices from each other and permit different choices to coexist in a single program. Furthermore, since large programs are often created by combining pre-existing modules that were designed in isolation, we need conventions that permit programmers to incorporate modules into larger systems *additively*, that is, without having to redesign or reimplement these modules. 10 | 11 | In this section, we will learn how to cope with data that may be represented in different ways by different parts of a program. This requires constructing *generic procedures*—procedures that can operate on data that may be represented in more than one way. Our main technique for building generic procedures will be to work in terms of data objects that have *type tags*, that is, data objects that include explicit information about how they are to be processed. We will also discuss *data-directed* programming, a powerful and convenient implementation strategy for additively assembling systems with generic operations. 12 | 13 | We begin with the simple complex-number example. We will see how type tags and data-directed style enable us to design separate rectangular and polar representations for complex numbers while maintaining the notion of an abstract “complex-number” data object. We will accomplish this by defining arithmetic procedures for complex numbers (`add-complex`, `sub-complex`, `mul-complex`, and `div-complex`) in terms of generic selectors that access parts of a complex number independent of how the number is represented. The resulting complex-number system, as shown in [Figure 2.19](#Figure-2_002e19), contains two different kinds of abstraction barriers. The “horizontal” abstraction barriers play the same role as the ones in [Figure 2.1](2_002e1.xhtml#Figure-2_002e1). They isolate “higher-level” operations from “lower-level” representations. In addition, there is a “vertical” barrier that gives us the ability to separately design and install alternative representations. 14 | 15 | ![](fig/chap2/Fig2.19a.std.svg 484.92x400.92) 16 | **Figure 2.19:** Data-abstraction barriers in the complex-number system. 17 | 18 | In [2.5](2_002e5.xhtml#g_t2_002e5) we will show how to use type tags and data-directed style to develop a generic arithmetic package. This provides procedures (`add`, `mul`, and so on) that can be used to manipulate all sorts of “numbers” and can be easily extended when a new kind of number is needed. In [2.5.3](2_002e5.xhtml#g_t2_002e5_002e3), we’ll show how to use generic arithmetic in a system that performs symbolic algebra. 19 | 20 | 21 | ## 2.4.1 Representations for Complex Numbers 22 | 23 | We will develop a system that performs arithmetic operations on complex numbers as a simple but unrealistic example of a program that uses generic operations. We begin by discussing two plausible representations for complex numbers as ordered pairs: rectangular form (real part and imaginary part) and polar form (magnitude and angle).^[In actual computational systems, rectangular form is preferable to polar form most of the time because of roundoff errors in conversion between rectangular and polar form. This is why the complex-number example is unrealistic. Nevertheless, it provides a clear illustration of the design of a system using generic operations and a good introduction to the more substantial systems to be developed later in this chapter.] Section [2.4.2](#g_t2_002e4_002e2) will show how both representations can be made to coexist in a single system through the use of type tags and generic operations. 24 | 25 | Like rational numbers, complex numbers are naturally represented as ordered pairs. The set of complex numbers can be thought of as a two-dimensional space with two orthogonal axes, the “real” axis and the “imaginary” axis. (See [Figure 2.20](#Figure-2_002e20).) From this point of view, the complex number $z = x + iy$ (where $i^{\mspace{2mu} 2} = \text{−1}$) can be thought of as the point in the plane whose real coordinate is $x$ and whose imaginary coordinate is $y$. Addition of complex numbers reduces in this representation to addition of coordinates: 26 | 27 | $$\begin{array}{lll} 28 | {\text{Real-part}(z_{1} + z_{2})} & = & {\text{Real-part}(z_{1}) +} \\ 29 | & & {\text{Real-part}(z_{2}),} \\ 30 | {\text{Imaginary-part}(z_{1} + z_{2})} & = & {\text{Imaginary-part}(z_{1}) +} \\ 31 | & & {\text{Imaginary-part}(z_{2}).} \\ 32 | \end{array}$$ 33 | 34 | ![](fig/chap2/Fig2.20.std.svg 623.76x368.88) 35 | **Figure 2.20:** Complex numbers as points in the plane. 36 | 37 | When multiplying complex numbers, it is more natural to think in terms of representing a complex number in polar form, as a magnitude and an angle ($r$ and $A$ in [Figure 2.20](#Figure-2_002e20)). The product of two complex numbers is the vector obtained by stretching one complex number by the length of the other and then rotating it through the angle of the other: 38 | 39 | $$\begin{array}{lll} 40 | {\text{Magnitude}(z_{1} \cdot z_{2})} & = & {\text{Magnitude}(z_{1}) \cdot \text{Magnitude}(z_{2}),} \\ 41 | {\text{Angle}(z_{1} \cdot z_{2})} & = & {\text{Angle}(z_{1}) + \text{Angle}(z_{2}).} \\ 42 | \end{array}$$ 43 | 44 | Thus, there are two different representations for complex numbers, which are appropriate for different operations. Yet, from the viewpoint of someone writing a program that uses complex numbers, the principle of data abstraction suggests that all the operations for manipulating complex numbers should be available regardless of which representation is used by the computer. For example, it is often useful to be able to find the magnitude of a complex number that is specified by rectangular coordinates. Similarly, it is often useful to be able to determine the real part of a complex number that is specified by polar coordinates. 45 | 46 | To design such a system, we can follow the same data-abstraction strategy we followed in designing the rational-number package in [2.1.1](2_002e1.xhtml#g_t2_002e1_002e1). Assume that the operations on complex numbers are implemented in terms of four selectors: `real-part`, `imag-part`, `magnitude`, and `angle`. Also assume that we have two procedures for constructing complex numbers: `make-from-real-imag` returns a complex number with specified real and imaginary parts, and `make-from-mag-ang` returns a complex number with specified magnitude and angle. These procedures have the property that, for any complex number `z`, both 47 | 48 | ``` {.scheme} 49 | (make-from-real-imag (real-part z) 50 | (imag-part z)) 51 | ``` 52 | 53 | and 54 | 55 | ``` {.scheme} 56 | (make-from-mag-ang (magnitude z) 57 | (angle z)) 58 | ``` 59 | 60 | produce complex numbers that are equal to `z`. 61 | 62 | Using these constructors and selectors, we can implement arithmetic on complex numbers using the “abstract data” specified by the constructors and selectors, just as we did for rational numbers in [2.1.1](2_002e1.xhtml#g_t2_002e1_002e1). As shown in the formulas above, we can add and subtract complex numbers in terms of real and imaginary parts while multiplying and dividing complex numbers in terms of magnitudes and angles: 63 | 64 | ``` {.scheme} 65 | (define (add-complex z1 z2) 66 | (make-from-real-imag 67 | (+ (real-part z1) (real-part z2)) 68 | (+ (imag-part z1) (imag-part z2)))) 69 | 70 | (define (sub-complex z1 z2) 71 | (make-from-real-imag 72 | (- (real-part z1) (real-part z2)) 73 | (- (imag-part z1) (imag-part z2)))) 74 | 75 | (define (mul-complex z1 z2) 76 | (make-from-mag-ang 77 | (* (magnitude z1) (magnitude z2)) 78 | (+ (angle z1) (angle z2)))) 79 | 80 | (define (div-complex z1 z2) 81 | (make-from-mag-ang 82 | (/ (magnitude z1) (magnitude z2)) 83 | (- (angle z1) (angle z2)))) 84 | ``` 85 | 86 | To complete the complex-number package, we must choose a representation and we must implement the constructors and selectors in terms of primitive numbers and primitive list structure. There are two obvious ways to do this: We can represent a complex number in “rectangular form” as a pair (real part, imaginary part) or in “polar form” as a pair (magnitude, angle). Which shall we choose? 87 | 88 | In order to make the different choices concrete, imagine that there are two programmers, Ben Bitdiddle and Alyssa P. Hacker, who are independently designing representations for the complex-number system. Ben chooses to represent complex numbers in rectangular form. With this choice, selecting the real and imaginary parts of a complex number is straightforward, as is constructing a complex number with given real and imaginary parts. To find the magnitude and the angle, or to construct a complex number with a given magnitude and angle, he uses the trigonometric relations 89 | 90 | $$\begin{array}{lll} 91 | x & = & {r\cos A,} \\ 92 | y & = & {r\sin A,} \\ 93 | r & = & \sqrt{x^{2} + y^{2},} \\ 94 | A & = & {\arctan(y,x),} \\ 95 | \end{array}$$ 96 | 97 | which relate the real and imaginary parts $(x,y)$ to the magnitude and the angle $(r,A)$.^[The arctangent function referred to here, computed by Scheme’s `atan` procedure, is defined so as to take two arguments $y$ and $x$ and to return the angle whose tangent is $y/x$. The signs of the arguments determine the quadrant of the angle.] Ben’s representation is therefore given by the following selectors and constructors: 98 | 99 | ``` {.scheme} 100 | (define (real-part z) (car z)) 101 | (define (imag-part z) (cdr z)) 102 | 103 | (define (magnitude z) 104 | (sqrt (+ (square (real-part z)) 105 | (square (imag-part z))))) 106 | 107 | (define (angle z) 108 | (atan (imag-part z) (real-part z))) 109 | 110 | (define (make-from-real-imag x y) 111 | (cons x y)) 112 | 113 | (define (make-from-mag-ang r a) 114 | (cons (* r (cos a)) (* r (sin a)))) 115 | ``` 116 | 117 | Alyssa, in contrast, chooses to represent complex numbers in polar form. For her, selecting the magnitude and angle is straightforward, but she has to use the trigonometric relations to obtain the real and imaginary parts. Alyssa’s representation is: 118 | 119 | ``` {.scheme} 120 | (define (real-part z) 121 | (* (magnitude z) (cos (angle z)))) 122 | 123 | (define (imag-part z) 124 | (* (magnitude z) (sin (angle z)))) 125 | 126 | (define (magnitude z) (car z)) 127 | (define (angle z) (cdr z)) 128 | 129 | (define (make-from-real-imag x y) 130 | (cons (sqrt (+ (square x) (square y))) 131 | (atan y x))) 132 | 133 | (define (make-from-mag-ang r a) 134 | (cons r a)) 135 | ``` 136 | 137 | The discipline of data abstraction ensures that the same implementation of `add-complex`, `sub-complex`, `mul-complex`, and `div-complex` will work with either Ben’s representation or Alyssa’s representation. 138 | 139 | 140 | ## 2.4.2 Tagged data 141 | 142 | One way to view data abstraction is as an application of the “principle of least commitment.” In implementing the complex-number system in [2.4.1](#g_t2_002e4_002e1), we can use either Ben’s rectangular representation or Alyssa’s polar representation. The abstraction barrier formed by the selectors and constructors permits us to defer to the last possible moment the choice of a concrete representation for our data objects and thus retain maximum flexibility in our system design. 143 | 144 | The principle of least commitment can be carried to even further extremes. If we desire, we can maintain the ambiguity of representation even *after* we have designed the selectors and constructors, and elect to use both Ben’s representation *and* Alyssa’s representation. If both representations are included in a single system, however, we will need some way to distinguish data in polar form from data in rectangular form. Otherwise, if we were asked, for instance, to find the `magnitude` of the pair (3, 4), we wouldn’t know whether to answer 5 (interpreting the number in rectangular form) or 3 (interpreting the number in polar form). A straightforward way to accomplish this distinction is to include a *type tag*—the symbol `rectangular` or `polar`—as part of each complex number. Then when we need to manipulate a complex number we can use the tag to decide which selector to apply. 145 | 146 | In order to manipulate tagged data, we will assume that we have procedures `type-tag` and `contents` that extract from a data object the tag and the actual contents (the polar or rectangular coordinates, in the case of a complex number). We will also postulate a procedure `attach-tag` that takes a tag and contents and produces a tagged data object. A straightforward way to implement this is to use ordinary list structure: 147 | 148 | ``` {.scheme} 149 | (define (attach-tag type-tag contents) 150 | (cons type-tag contents)) 151 | 152 | (define (type-tag datum) 153 | (if (pair? datum) 154 | (car datum) 155 | (error "Bad tagged datum: 156 | TYPE-TAG" datum))) 157 | 158 | (define (contents datum) 159 | (if (pair? datum) 160 | (cdr datum) 161 | (error "Bad tagged datum: 162 | CONTENTS" datum))) 163 | ``` 164 | 165 | Using these procedures, we can define predicates `rectangular?` and `polar?`, which recognize rectangular and polar numbers, respectively: 166 | 167 | ``` {.scheme} 168 | (define (rectangular? z) 169 | (eq? (type-tag z) 'rectangular)) 170 | 171 | (define (polar? z) 172 | (eq? (type-tag z) 'polar)) 173 | ``` 174 | 175 | With type tags, Ben and Alyssa can now modify their code so that their two different representations can coexist in the same system. Whenever Ben constructs a complex number, he tags it as rectangular. Whenever Alyssa constructs a complex number, she tags it as polar. In addition, Ben and Alyssa must make sure that the names of their procedures do not conflict. One way to do this is for Ben to append the suffix `rectangular` to the name of each of his representation procedures and for Alyssa to append `polar` to the names of hers. Here is Ben’s revised rectangular representation from [2.4.1](#g_t2_002e4_002e1): 176 | 177 | ``` {.scheme} 178 | (define (real-part-rectangular z) (car z)) 179 | (define (imag-part-rectangular z) (cdr z)) 180 | 181 | (define (magnitude-rectangular z) 182 | (sqrt (+ (square (real-part-rectangular z)) 183 | (square (imag-part-rectangular z))))) 184 | 185 | (define (angle-rectangular z) 186 | (atan (imag-part-rectangular z) 187 | (real-part-rectangular z))) 188 | 189 | (define (make-from-real-imag-rectangular x y) 190 | (attach-tag 'rectangular (cons x y))) 191 | 192 | (define (make-from-mag-ang-rectangular r a) 193 | (attach-tag 194 | 'rectangular 195 | (cons (* r (cos a)) (* r (sin a))))) 196 | ``` 197 | 198 | and here is Alyssa’s revised polar representation: 199 | 200 | ``` {.scheme} 201 | (define (real-part-polar z) 202 | (* (magnitude-polar z) 203 | (cos (angle-polar z)))) 204 | 205 | (define (imag-part-polar z) 206 | (* (magnitude-polar z) 207 | (sin (angle-polar z)))) 208 | 209 | (define (magnitude-polar z) (car z)) 210 | (define (angle-polar z) (cdr z)) 211 | 212 | (define (make-from-real-imag-polar x y) 213 | (attach-tag 214 | 'polar 215 | (cons (sqrt (+ (square x) (square y))) 216 | (atan y x)))) 217 | 218 | (define (make-from-mag-ang-polar r a) 219 | (attach-tag 'polar (cons r a))) 220 | ``` 221 | 222 | Each generic selector is implemented as a procedure that checks the tag of its argument and calls the appropriate procedure for handling data of that type. For example, to obtain the real part of a complex number, `real-part` examines the tag to determine whether to use Ben’s `real-part-rectangular` or Alyssa’s `real-part-polar`. In either case, we use `contents` to extract the bare, untagged datum and send this to the rectangular or polar procedure as required: 223 | 224 | ``` {.scheme} 225 | (define (real-part z) 226 | (cond ((rectangular? z) 227 | (real-part-rectangular (contents z))) 228 | ((polar? z) 229 | (real-part-polar (contents z))) 230 | (else (error "Unknown type: 231 | REAL-PART" z)))) 232 | 233 | (define (imag-part z) 234 | (cond ((rectangular? z) 235 | (imag-part-rectangular (contents z))) 236 | ((polar? z) 237 | (imag-part-polar (contents z))) 238 | (else (error "Unknown type: 239 | IMAG-PART" z)))) 240 | 241 | (define (magnitude z) 242 | (cond ((rectangular? z) 243 | (magnitude-rectangular (contents z))) 244 | ((polar? z) 245 | (magnitude-polar (contents z))) 246 | (else (error "Unknown type: 247 | MAGNITUDE" z)))) 248 | 249 | (define (angle z) 250 | (cond ((rectangular? z) 251 | (angle-rectangular (contents z))) 252 | ((polar? z) 253 | (angle-polar (contents z))) 254 | (else (error "Unknown type: 255 | ANGLE" z)))) 256 | ``` 257 | 258 | To implement the complex-number arithmetic operations, we can use the same procedures `add-complex`, `sub-complex`, `mul-complex`, and `div-complex` from [2.4.1](#g_t2_002e4_002e1), because the selectors they call are generic, and so will work with either representation. For example, the procedure `add-complex` is still 259 | 260 | ``` {.scheme} 261 | (define (add-complex z1 z2) 262 | (make-from-real-imag 263 | (+ (real-part z1) (real-part z2)) 264 | (+ (imag-part z1) (imag-part z2)))) 265 | ``` 266 | 267 | Finally, we must choose whether to construct complex numbers using Ben’s representation or Alyssa’s representation. One reasonable choice is to construct rectangular numbers whenever we have real and imaginary parts and to construct polar numbers whenever we have magnitudes and angles: 268 | 269 | ``` {.scheme} 270 | (define (make-from-real-imag x y) 271 | (make-from-real-imag-rectangular x y)) 272 | 273 | (define (make-from-mag-ang r a) 274 | (make-from-mag-ang-polar r a)) 275 | ``` 276 | 277 | The resulting complex-number system has the structure shown in [Figure 2.21](#Figure-2_002e21). The system has been decomposed into three relatively independent parts: the complex-number-arithmetic operations, Alyssa’s polar implementation, and Ben’s rectangular implementation. The polar and rectangular implementations could have been written by Ben and Alyssa working separately, and both of these can be used as underlying representations by a third programmer implementing the complex-arithmetic procedures in terms of the abstract constructor/selector interface. 278 | 279 | ![](fig/chap2/Fig2.21a.std.svg 780.12x403.08) 280 | **Figure 2.21:** Structure of the generic complex-arithmetic system. 281 | 282 | Since each data object is tagged with its type, the selectors operate on the data in a generic manner. That is, each selector is defined to have a behavior that depends upon the particular type of data it is applied to. Notice the general mechanism for interfacing the separate representations: Within a given representation implementation (say, Alyssa’s polar package) a complex number is an untyped pair (magnitude, angle). When a generic selector operates on a number of `polar` type, it strips off the tag and passes the contents on to Alyssa’s code. Conversely, when Alyssa constructs a number for general use, she tags it with a type so that it can be appropriately recognized by the higher-level procedures. This discipline of stripping off and attaching tags as data objects are passed from level to level can be an important organizational strategy, as we shall see in [2.5](2_002e5.xhtml#g_t2_002e5). 283 | 284 | 285 | ## 2.4.3 Data-Directed Programming and Additivity 286 | 287 | The general strategy of checking the type of a datum and calling an appropriate procedure is called *dispatching on type*. This is a powerful strategy for obtaining modularity in system design. On the other hand, implementing the dispatch as in [2.4.2](#g_t2_002e4_002e2) has two significant weaknesses. One weakness is that the generic interface procedures (`real-part`, `imag-part`, `magnitude`, and `angle`) must know about all the different representations. For instance, suppose we wanted to incorporate a new representation for complex numbers into our complex-number system. We would need to identify this new representation with a type, and then add a clause to each of the generic interface procedures to check for the new type and apply the appropriate selector for that representation. 288 | 289 | Another weakness of the technique is that even though the individual representations can be designed separately, we must guarantee that no two procedures in the entire system have the same name. This is why Ben and Alyssa had to change the names of their original procedures from [2.4.1](#g_t2_002e4_002e1). 290 | 291 | The issue underlying both of these weaknesses is that the technique for implementing generic interfaces is not *additive*. The person implementing the generic selector procedures must modify those procedures each time a new representation is installed, and the people interfacing the individual representations must modify their code to avoid name conflicts. In each of these cases, the changes that must be made to the code are straightforward, but they must be made nonetheless, and this is a source of inconvenience and error. This is not much of a problem for the complex-number system as it stands, but suppose there were not two but hundreds of different representations for complex numbers. And suppose that there were many generic selectors to be maintained in the abstract-data interface. Suppose, in fact, that no one programmer knew all the interface procedures or all the representations. The problem is real and must be addressed in such programs as large-scale data-base-management systems. 292 | 293 | What we need is a means for modularizing the system design even further. This is provided by the programming technique known as *data-directed programming*. To understand how data-directed programming works, begin with the observation that whenever we deal with a set of generic operations that are common to a set of different types we are, in effect, dealing with a two-dimensional table that contains the possible operations on one axis and the possible types on the other axis. The entries in the table are the procedures that implement each operation for each type of argument presented. In the complex-number system developed in the previous section, the correspondence between operation name, data type, and actual procedure was spread out among the various conditional clauses in the generic interface procedures. But the same information could have been organized in a table, as shown in [Figure 2.22](#Figure-2_002e22). 294 | 295 | ![](fig/chap2/Fig2.22.std.svg 759.48x251.76) 296 | **Figure 2.22:** Table of operations for the complex-number system. 297 | 298 | Data-directed programming is the technique of designing programs to work with such a table directly. Previously, we implemented the mechanism that interfaces the complex-arithmetic code with the two representation packages as a set of procedures that each perform an explicit dispatch on type. Here we will implement the interface as a single procedure that looks up the combination of the operation name and argument type in the table to find the correct procedure to apply, and then applies it to the contents of the argument. If we do this, then to add a new representation package to the system we need not change any existing procedures; we need only add new entries to the table. 299 | 300 | To implement this plan, assume that we have two procedures, `put` and `get`, for manipulating the operation-and-type table: 301 | 302 | - `(put ⟨op⟩ ⟨type⟩ ⟨item⟩)` installs the `⟨`item`⟩` in the table, indexed by the `⟨`op`⟩` and the `⟨`type`⟩`. 303 | - `(get ⟨op⟩ ⟨type⟩)` looks up the `⟨`op`⟩`, `⟨`type`⟩` entry in the table and returns the item found there. If no item is found, `get` returns false. 304 | 305 | For now, we can assume that `put` and `get` are included in our language. In [Chapter 3](Chapter-3.xhtml#Chapter-3) ([3.3.3](3_002e3.xhtml#g_t3_002e3_002e3)) we will see how to implement these and other operations for manipulating tables. 306 | 307 | Here is how data-directed programming can be used in the complex-number system. Ben, who developed the rectangular representation, implements his code just as he did originally. He defines a collection of procedures, or a *package*, and interfaces these to the rest of the system by adding entries to the table that tell the system how to operate on rectangular numbers. This is accomplished by calling the following procedure: 308 | 309 | ``` {.scheme} 310 | (define (install-rectangular-package) 311 | ;; internal procedures 312 | (define (real-part z) (car z)) 313 | (define (imag-part z) (cdr z)) 314 | (define (make-from-real-imag x y) 315 | (cons x y)) 316 | (define (magnitude z) 317 | (sqrt (+ (square (real-part z)) 318 | (square (imag-part z))))) 319 | (define (angle z) 320 | (atan (imag-part z) (real-part z))) 321 | (define (make-from-mag-ang r a) 322 | (cons (* r (cos a)) (* r (sin a)))) 323 | ;; interface to the rest of the system 324 | (define (tag x) 325 | (attach-tag 'rectangular x)) 326 | (put 'real-part '(rectangular) real-part) 327 | (put 'imag-part '(rectangular) imag-part) 328 | (put 'magnitude '(rectangular) magnitude) 329 | (put 'angle '(rectangular) angle) 330 | (put 'make-from-real-imag 'rectangular 331 | (lambda (x y) 332 | (tag (make-from-real-imag x y)))) 333 | (put 'make-from-mag-ang 'rectangular 334 | (lambda (r a) 335 | (tag (make-from-mag-ang r a)))) 336 | 'done) 337 | ``` 338 | 339 | Notice that the internal procedures here are the same procedures from [2.4.1](#g_t2_002e4_002e1) that Ben wrote when he was working in isolation. No changes are necessary in order to interface them to the rest of the system. Moreover, since these procedure definitions are internal to the installation procedure, Ben needn’t worry about name conflicts with other procedures outside the rectangular package. To interface these to the rest of the system, Ben installs his `real-part` procedure under the operation name `real-part` and the type `(rectangular)`, and similarly for the other selectors.^[We use the list `(rectangular)` rather than the symbol `rectangular` to allow for the possibility of operations with multiple arguments, not all of the same type.] The interface also defines the constructors to be used by the external system.^[The type the constructors are installed under needn’t be a list because a constructor is always used to make an object of one particular type.] These are identical to Ben’s internally defined constructors, except that they attach the tag. 340 | 341 | Alyssa’s polar package is analogous: 342 | 343 | ``` {.scheme} 344 | (define (install-polar-package) 345 | ;; internal procedures 346 | (define (magnitude z) (car z)) 347 | (define (angle z) (cdr z)) 348 | (define (make-from-mag-ang r a) (cons r a)) 349 | (define (real-part z) 350 | (* (magnitude z) (cos (angle z)))) 351 | (define (imag-part z) 352 | (* (magnitude z) (sin (angle z)))) 353 | (define (make-from-real-imag x y) 354 | (cons (sqrt (+ (square x) (square y))) 355 | (atan y x))) 356 | ;; interface to the rest of the system 357 | (define (tag x) (attach-tag 'polar x)) 358 | (put 'real-part '(polar) real-part) 359 | (put 'imag-part '(polar) imag-part) 360 | (put 'magnitude '(polar) magnitude) 361 | (put 'angle '(polar) angle) 362 | (put 'make-from-real-imag 'polar 363 | (lambda (x y) 364 | (tag (make-from-real-imag x y)))) 365 | (put 'make-from-mag-ang 'polar 366 | (lambda (r a) 367 | (tag (make-from-mag-ang r a)))) 368 | 'done) 369 | ``` 370 | 371 | Even though Ben and Alyssa both still use their original procedures defined with the same names as each other’s (e.g., `real-part`), these definitions are now internal to different procedures (see [1.1.8](1_002e1.xhtml#g_t1_002e1_002e8)), so there is no name conflict. 372 | 373 | The complex-arithmetic selectors access the table by means of a general “operation” procedure called `apply-generic`, which applies a generic operation to some arguments. `Apply-generic` looks in the table under the name of the operation and the types of the arguments and applies the resulting procedure if one is present:^[`Apply-generic` uses the dotted-tail notation described in [Exercise 2.20](2_002e2.xhtml#Exercise-2_002e20), because different generic operations may take different numbers of arguments. In `apply-generic`, `op` has as its value the first argument to `apply-generic` and `args` has as its value a list of the remaining arguments.] 374 | 375 | ``` {.scheme} 376 | (define (apply-generic op . args) 377 | (let ((type-tags (map type-tag args))) 378 | (let ((proc (get op type-tags))) 379 | (if proc 380 | (apply proc (map contents args)) 381 | (error 382 | "No method for these types: 383 | APPLY-GENERIC" 384 | (list op type-tags)))))) 385 | ``` 386 | 387 | Using `apply-generic`, we can define our generic selectors as follows: 388 | 389 | ``` {.scheme} 390 | (define (real-part z) 391 | (apply-generic 'real-part z)) 392 | (define (imag-part z) 393 | (apply-generic 'imag-part z)) 394 | (define (magnitude z) 395 | (apply-generic 'magnitude z)) 396 | (define (angle z) 397 | (apply-generic 'angle z)) 398 | ``` 399 | 400 | Observe that these do not change at all if a new representation is added to the system. 401 | 402 | We can also extract from the table the constructors to be used by the programs external to the packages in making complex numbers from real and imaginary parts and from magnitudes and angles. As in [2.4.2](#g_t2_002e4_002e2), we construct rectangular numbers whenever we have real and imaginary parts, and polar numbers whenever we have magnitudes and angles: 403 | 404 | ``` {.scheme} 405 | (define (make-from-real-imag x y) 406 | ((get 'make-from-real-imag 407 | 'rectangular) 408 | x y)) 409 | 410 | (define (make-from-mag-ang r a) 411 | ((get 'make-from-mag-ang 412 | 'polar) 413 | r a)) 414 | ``` 415 | 416 | **Exercise 2.73:** [2.3.2](2_002e3.xhtml#g_t2_002e3_002e2) described a program that performs symbolic differentiation: 417 | 418 | 419 | ``` {.scheme} 420 | (define (deriv exp var) 421 | (cond ((number? exp) 0) 422 | ((variable? exp) 423 | (if (same-variable? exp var) 1 0)) 424 | ((sum? exp) 425 | (make-sum (deriv (addend exp) var) 426 | (deriv (augend exp) var))) 427 | ((product? exp) 428 | (make-sum 429 | (make-product 430 | (multiplier exp) 431 | (deriv (multiplicand exp) var)) 432 | (make-product 433 | (deriv (multiplier exp) var) 434 | (multiplicand exp)))) 435 | ⟨more rules can be added here⟩ 436 | (else (error "unknown expression type: 437 | DERIV" exp)))) 438 | ``` 439 | 440 | 441 | We can regard this program as performing a dispatch on the type of the expression to be differentiated. In this situation the “type tag” of the datum is the algebraic operator symbol (such as `+`) and the operation being performed is `deriv`. We can transform this program into data-directed style by rewriting the basic derivative procedure as 442 | 443 | 444 | ``` {.scheme} 445 | (define (deriv exp var) 446 | (cond ((number? exp) 0) 447 | ((variable? exp) 448 | (if (same-variable? exp var) 449 | 1 450 | 0)) 451 | (else ((get 'deriv (operator exp)) 452 | (operands exp) 453 | var)))) 454 | 455 | (define (operator exp) (car exp)) 456 | (define (operands exp) (cdr exp)) 457 | ``` 458 | 459 | 460 | 1. Explain what was done above. Why can’t we assimilate the predicates `number?` and `variable?` into the data-directed dispatch? 461 | 2. Write the procedures for derivatives of sums and products, and the auxiliary code required to install them in the table used by the program above. 462 | 3. Choose any additional differentiation rule that you like, such as the one for exponents ([Exercise 2.56](2_002e3.xhtml#Exercise-2_002e56)), and install it in this data-directed system. 463 | 4. In this simple algebraic manipulator the type of an expression is the algebraic operator that binds it together. Suppose, however, we indexed the procedures in the opposite way, so that the dispatch line in `deriv` looked like 464 | 465 | ``` {.scheme} 466 | ((get (operator exp) 'deriv) 467 | (operands exp) var) 468 | ``` 469 | 470 | 471 | What corresponding changes to the derivative system are required? 472 | 473 | **Exercise 2.74:** Insatiable Enterprises, Inc., is a highly decentralized conglomerate company consisting of a large number of independent divisions located all over the world. The company’s computer facilities have just been interconnected by means of a clever network-interfacing scheme that makes the entire network appear to any user to be a single computer. Insatiable’s president, in her first attempt to exploit the ability of the network to extract administrative information from division files, is dismayed to discover that, although all the division files have been implemented as data structures in Scheme, the particular data structure used varies from division to division. A meeting of division managers is hastily called to search for a strategy to integrate the files that will satisfy headquarters’ needs while preserving the existing autonomy of the divisions. 474 | 475 | Show how such a strategy can be implemented with data-directed programming. As an example, suppose that each division’s personnel records consist of a single file, which contains a set of records keyed on employees’ names. The structure of the set varies from division to division. Furthermore, each employee’s record is itself a set (structured differently from division to division) that contains information keyed under identifiers such as `address` and `salary`. In particular: 476 | 477 | 1. Implement for headquarters a `get-record` procedure that retrieves a specified employee’s record from a specified personnel file. The procedure should be applicable to any division’s file. Explain how the individual divisions’ files should be structured. In particular, what type information must be supplied? 478 | 2. Implement for headquarters a `get-salary` procedure that returns the salary information from a given employee’s record from any division’s personnel file. How should the record be structured in order to make this operation work? 479 | 3. Implement for headquarters a `find-employee-record` procedure. This should search all the divisions’ files for the record of a given employee and return the record. Assume that this procedure takes as arguments an employee’s name and a list of all the divisions’ files. 480 | 4. When Insatiable takes over a new company, what changes must be made in order to incorporate the new personnel information into the central system? 481 | 482 | 483 | ### Message passing 484 | 485 | The key idea of data-directed programming is to handle generic operations in programs by dealing explicitly with operation-and-type tables, such as the table in [Figure 2.22](#Figure-2_002e22). The style of programming we used in [2.4.2](#g_t2_002e4_002e2) organized the required dispatching on type by having each operation take care of its own dispatching. In effect, this decomposes the operation-and-type table into rows, with each generic operation procedure representing a row of the table. 486 | 487 | An alternative implementation strategy is to decompose the table into columns and, instead of using “intelligent operations” that dispatch on data types, to work with “intelligent data objects” that dispatch on operation names. We can do this by arranging things so that a data object, such as a rectangular number, is represented as a procedure that takes as input the required operation name and performs the operation indicated. In such a discipline, `make-from-real-imag` could be written as 488 | 489 | ``` {.scheme} 490 | (define (make-from-real-imag x y) 491 | (define (dispatch op) 492 | (cond ((eq? op 'real-part) x) 493 | ((eq? op 'imag-part) y) 494 | ((eq? op 'magnitude) 495 | (sqrt (+ (square x) (square y)))) 496 | ((eq? op 'angle) (atan y x)) 497 | (else 498 | (error "Unknown op: 499 | MAKE-FROM-REAL-IMAG" op)))) 500 | dispatch) 501 | ``` 502 | 503 | The corresponding `apply-generic` procedure, which applies a generic operation to an argument, now simply feeds the operation’s name to the data object and lets the object do the work:^[One limitation of this organization is it permits only generic procedures of one argument.] 504 | 505 | ``` {.scheme} 506 | (define (apply-generic op arg) (arg op)) 507 | ``` 508 | 509 | Note that the value returned by `make-from-real-imag` is a procedure—the internal `dispatch` procedure. This is the procedure that is invoked when `apply-generic` requests an operation to be performed. 510 | 511 | This style of programming is called *message passing*. The name comes from the image that a data object is an entity that receives the requested operation name as a “message.” We have already seen an example of message passing in [2.1.3](2_002e1.xhtml#g_t2_002e1_002e3), where we saw how `cons`, `car`, and `cdr` could be defined with no data objects but only procedures. Here we see that message passing is not a mathematical trick but a useful technique for organizing systems with generic operations. In the remainder of this chapter we will continue to use data-directed programming, rather than message passing, to discuss generic arithmetic operations. In [Chapter 3](Chapter-3.xhtml#Chapter-3) we will return to message passing, and we will see that it can be a powerful tool for structuring simulation programs. 512 | 513 | **Exercise 2.75:** Implement the constructor `make-from-mag-ang` in message-passing style. This procedure should be analogous to the `make-from-real-imag` procedure given above. 514 | 515 | **Exercise 2.76:** As a large system with generic operations evolves, new types of data objects or new operations may be needed. For each of the three strategies—generic operations with explicit dispatch, data-directed style, and message-passing-style—describe the changes that must be made to a system in order to add new types or new operations. Which organization would be most appropriate for a system in which new types must often be added? Which would be most appropriate for a system in which new operations must often be added? 516 | -------------------------------------------------------------------------------- /capitulos/03-00-modularidade-objetos-estado.md: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/has256/sicp-ptbr/856d0fd1f262ee49522e544a13a912301c9e52b8/capitulos/03-00-modularidade-objetos-estado.md -------------------------------------------------------------------------------- /capitulos/03-02-modelo-ambiente-avaliacao.md: -------------------------------------------------------------------------------- 1 | # 3.2 The Environment Model of Evaluation 2 | 3 | When we introduced compound procedures in [Chapter 1](Chapter-1.xhtml#Chapter-1), we used the substitution model of evaluation ([1.1.5](1_002e1.xhtml#g_t1_002e1_002e5)) to define what is meant by applying a procedure to arguments: 4 | 5 | - To apply a compound procedure to arguments, evaluate the body of the procedure with each formal parameter replaced by the corresponding argument. 6 | 7 | Once we admit assignment into our programming language, such a definition is no longer adequate. In particular, [3.1.3](3_002e1.xhtml#g_t3_002e1_002e3) argued that, in the presence of assignment, a variable can no longer be considered to be merely a name for a value. Rather, a variable must somehow designate a “place” in which values can be stored. In our new model of evaluation, these places will be maintained in structures called *environments*. 8 | 9 | An environment is a sequence of *frames*. Each frame is a table (possibly empty) of *bindings*, which associate variable names with their corresponding values. (A single frame may contain at most one binding for any variable.) Each frame also has a pointer to its *enclosing environment*, unless, for the purposes of discussion, the frame is considered to be *global*. The *value of a variable* with respect to an environment is the value given by the binding of the variable in the first frame in the environment that contains a binding for that variable. If no frame in the sequence specifies a binding for the variable, then the variable is said to be *unbound* in the environment. 10 | 11 | [Figure 3.1](#Figure-3_002e1) shows a simple environment structure consisting of three frames, labeled I, II, and III. In the diagram, A, B, C, and D are pointers to environments. C and D point to the same environment. The variables `z` and `x` are bound in frame II, while `y` and `x` are bound in frame I. The value of `x` in environment D is 3. The value of `x` with respect to environment B is also 3. This is determined as follows: We examine the first frame in the sequence (frame III) and do not find a binding for `x`, so we proceed to the enclosing environment D and find the binding in frame I. On the other hand, the value of `x` in environment A is 7, because the first frame in the sequence (frame II) contains a binding of `x` to 7. With respect to environment A, the binding of `x` to 7 in frame II is said to *shadow* the binding of `x` to 3 in frame I. 12 | 13 | ![](fig/chap3/Fig3.1b.std.svg 318.12x279.72) 14 | **Figure 3.1:** A simple environment structure. 15 | 16 | The environment is crucial to the evaluation process, because it determines the context in which an expression should be evaluated. Indeed, one could say that expressions in a programming language do not, in themselves, have any meaning. Rather, an expression acquires a meaning only with respect to some environment in which it is evaluated. Even the interpretation of an expression as straightforward as `(+ 1 1)` depends on an understanding that one is operating in a context in which `+` is the symbol for addition. Thus, in our model of evaluation we will always speak of evaluating an expression with respect to some environment. To describe interactions with the interpreter, we will suppose that there is a global environment, consisting of a single frame (with no enclosing environment) that includes values for the symbols associated with the primitive procedures. For example, the idea that `+` is the symbol for addition is captured by saying that the symbol `+` is bound in the global environment to the primitive addition procedure. 17 | 18 | 19 | ## 3.2.1 The Rules for Evaluation 20 | 21 | The overall specification of how the interpreter evaluates a combination remains the same as when we first introduced it in [1.1.3](1_002e1.xhtml#g_t1_002e1_002e3): 22 | 23 | - To evaluate a combination: 24 | 25 | 1. Evaluate the subexpressions of the combination.^[Assignment introduces a subtlety into step 1 of the evaluation rule. As shown in [Exercise 3.8](3_002e1.xhtml#Exercise-3_002e8), the presence of assignment allows us to write expressions that will produce different values depending on the order in which the subexpressions in a combination are evaluated. Thus, to be precise, we should specify an evaluation order in step 1 (e.g., left to right or right to left). However, this order should always be considered to be an implementation detail, and one should never write programs that depend on some particular order. For instance, a sophisticated compiler might optimize a program by varying the order in which subexpressions are evaluated.] 26 | 2. Apply the value of the operator subexpression to the values of the operand subexpressions. 27 | 28 | The environment model of evaluation replaces the substitution model in specifying what it means to apply a compound procedure to arguments. 29 | 30 | In the environment model of evaluation, a procedure is always a pair consisting of some code and a pointer to an environment. Procedures are created in one way only: by evaluating a λ-expression. This produces a procedure whose code is obtained from the text of the λ-expression and whose environment is the environment in which the λ-expression was evaluated to produce the procedure. For example, consider the procedure definition 31 | 32 | ``` {.scheme} 33 | (define (square x) 34 | (* x x)) 35 | ``` 36 | 37 | evaluated in the global environment. The procedure definition syntax is just syntactic sugar for an underlying implicit λ-expression. It would have been equivalent to have used 38 | 39 | ``` {.scheme} 40 | (define square 41 | (lambda (x) (* x x))) 42 | ``` 43 | 44 | which evaluates `(lambda (x) (* x x))` and binds `square` to the resulting value, all in the global environment. 45 | 46 | [Figure 3.2](#Figure-3_002e2) shows the result of evaluating this `define` expression. The procedure object is a pair whose code specifies that the procedure has one formal parameter, namely `x`, and a procedure body `(* x x)`. The environment part of the procedure is a pointer to the global environment, since that is the environment in which the λ-expression was evaluated to produce the procedure. A new binding, which associates the procedure object with the symbol `square`, has been added to the global frame. In general, `define` creates definitions by adding bindings to frames. 47 | 48 | ![](fig/chap3/Fig3.2b.std.svg 406.2x328.44) 49 | **Figure 3.2:** Environment structure produced by evaluating `(define (square x) (* x x))` in the global environment. 50 | 51 | Now that we have seen how procedures are created, we can describe how procedures are applied. The environment model specifies: To apply a procedure to arguments, create a new environment containing a frame that binds the parameters to the values of the arguments. The enclosing environment of this frame is the environment specified by the procedure. Now, within this new environment, evaluate the procedure body. 52 | 53 | To show how this rule is followed, [Figure 3.3](#Figure-3_002e3) illustrates the environment structure created by evaluating the expression `(square 5)` in the global environment, where `square` is the procedure generated in [Figure 3.2](#Figure-3_002e2). Applying the procedure results in the creation of a new environment, labeled E1 in the figure, that begins with a frame in which `x`, the formal parameter for the procedure, is bound to the argument 5. The pointer leading upward from this frame shows that the frame’s enclosing environment is the global environment. The global environment is chosen here, because this is the environment that is indicated as part of the `square` procedure object. Within E1, we evaluate the body of the procedure, `(* x x)`. Since the value of `x` in E1 is 5, the result is `(* 5 5)`, or 25. 54 | 55 | ![](fig/chap3/Fig3.3b.std.svg 629.88x328.44) 56 | **Figure 3.3:** Environment created by evaluating `(square 5)` in the global environment. 57 | 58 | The environment model of procedure application can be summarized by two rules: 59 | 60 | - A procedure object is applied to a set of arguments by constructing a frame, binding the formal parameters of the procedure to the arguments of the call, and then evaluating the body of the procedure in the context of the new environment constructed. The new frame has as its enclosing environment the environment part of the procedure object being applied. 61 | - A procedure is created by evaluating a λ-expression relative to a given environment. The resulting procedure object is a pair consisting of the text of the λ-expression and a pointer to the environment in which the procedure was created. 62 | 63 | We also specify that defining a symbol using `define` creates a binding in the current environment frame and assigns to the symbol the indicated value.^[If there is already a binding for the variable in the current frame, then the binding is changed. This is convenient because it allows redefinition of symbols; however, it also means that `define` can be used to change values, and this brings up the issues of assignment without explicitly using `set!`. Because of this, some people prefer redefinitions of existing symbols to signal errors or warnings.] Finally, we specify the behavior of `set!`, the operation that forced us to introduce the environment model in the first place. Evaluating the expression `(set! ⟨variable⟩ ⟨value⟩)` in some environment locates the binding of the variable in the environment and changes that binding to indicate the new value. That is, one finds the first frame in the environment that contains a binding for the variable and modifies that frame. If the variable is unbound in the environment, then `set!` signals an error. 64 | 65 | These evaluation rules, though considerably more complex than the substitution model, are still reasonably straightforward. Moreover, the evaluation model, though abstract, provides a correct description of how the interpreter evaluates expressions. In [Chapter 4](Chapter-4.xhtml#Chapter-4) we shall see how this model can serve as a blueprint for implementing a working interpreter. The following sections elaborate the details of the model by analyzing some illustrative programs. 66 | 67 | 68 | ## 3.2.2 Applying Simple Procedures 69 | 70 | When we introduced the substitution model in [1.1.5](1_002e1.xhtml#g_t1_002e1_002e5) we showed how the combination `(f 5)` evaluates to 136, given the following procedure definitions: 71 | 72 | ``` {.scheme} 73 | (define (square x) 74 | (* x x)) 75 | (define (sum-of-squares x y) 76 | (+ (square x) (square y))) 77 | (define (f a) 78 | (sum-of-squares (+ a 1) (* a 2))) 79 | ``` 80 | 81 | We can analyze the same example using the environment model. [Figure 3.4](#Figure-3_002e4) shows the three procedure objects created by evaluating the definitions of `f`, `square`, and `sum-of-squares` in the global environment. Each procedure object consists of some code, together with a pointer to the global environment. 82 | 83 | ![](fig/chap3/Fig3.4b.std.svg 649.68x429.96) 84 | **Figure 3.4:** Procedure objects in the global frame. 85 | 86 | In [Figure 3.5](#Figure-3_002e5) we see the environment structure created by evaluating the expression `(f 5)`. The call to `f` creates a new environment E1 beginning with a frame in which `a`, the formal parameter of `f`, is bound to the argument 5. In E1, we evaluate the body of `f`: 87 | 88 | ``` {.scheme} 89 | (sum-of-squares (+ a 1) (* a 2)) 90 | ``` 91 | 92 | ![](fig/chap3/Fig3.5b.std.svg 695.16x374.04) 93 | **Figure 3.5:** Environments created by evaluating `(f 5)` using the procedures in [Figure 3.4](#Figure-3_002e4). 94 | 95 | To evaluate this combination, we first evaluate the subexpressions. The first subexpression, `sum-of-squares`, has a value that is a procedure object. (Notice how this value is found: We first look in the first frame of E1, which contains no binding for `sum-of-squares`. Then we proceed to the enclosing environment, i.e. the global environment, and find the binding shown in [Figure 3.4](#Figure-3_002e4).) The other two subexpressions are evaluated by applying the primitive operations `+` and `*` to evaluate the two combinations `(+ a 1)` and `(* a 2)` to obtain 6 and 10, respectively. 96 | 97 | Now we apply the procedure object `sum-of-squares` to the arguments 6 and 10. This results in a new environment E2 in which the formal parameters `x` and `y` are bound to the arguments. Within E2 we evaluate the combination `(+ (square x) (square y))`. This leads us to evaluate `(square x)`, where `square` is found in the global frame and `x` is 6. Once again, we set up a new environment, E3, in which `x` is bound to 6, and within this we evaluate the body of `square`, which is `(* x x)`. Also as part of applying `sum-of-squares`, we must evaluate the subexpression `(square y)`, where `y` is 10. This second call to `square` creates another environment, E4, in which `x`, the formal parameter of `square`, is bound to 10. And within E4 we must evaluate `(* x x)`. 98 | 99 | The important point to observe is that each call to `square` creates a new environment containing a binding for `x`. We can see here how the different frames serve to keep separate the different local variables all named `x`. Notice that each frame created by `square` points to the global environment, since this is the environment indicated by the `square` procedure object. 100 | 101 | After the subexpressions are evaluated, the results are returned. The values generated by the two calls to `square` are added by `sum-of-squares`, and this result is returned by `f`. Since our focus here is on the environment structures, we will not dwell on how these returned values are passed from call to call; however, this is also an important aspect of the evaluation process, and we will return to it in detail in [Chapter 5](Chapter-5.xhtml#Chapter-5). 102 | 103 | **Exercise 3.9:** In [1.2.1](1_002e2.xhtml#g_t1_002e2_002e1) we used the substitution model to analyze two procedures for computing factorials, a recursive version 104 | 105 | 106 | ``` {.scheme} 107 | (define (factorial n) 108 | (if (= n 1) 109 | 1 110 | (* n (factorial (- n 1))))) 111 | ``` 112 | 113 | 114 | and an iterative version 115 | 116 | 117 | ``` {.scheme} 118 | (define (factorial n) 119 | (fact-iter 1 1 n)) 120 | 121 | (define (fact-iter product 122 | counter 123 | max-count) 124 | (if (> counter max-count) 125 | product 126 | (fact-iter (* counter product) 127 | (+ counter 1) 128 | max-count))) 129 | ``` 130 | 131 | 132 | Show the environment structures created by evaluating `(factorial 6)` using each version of the `factorial` procedure.^[The environment model will not clarify our claim in [1.2.1](1_002e2.xhtml#g_t1_002e2_002e1) that the interpreter can execute a procedure such as `fact-iter` in a constant amount of space using tail recursion. We will discuss tail recursion when we deal with the control structure of the interpreter in [5.4](5_002e4.xhtml#g_t5_002e4).] 133 | 134 | 135 | ## 3.2.3 Frames as the Repository of Local State 136 | 137 | We can turn to the environment model to see how procedures and assignment can be used to represent objects with local state. As an example, consider the “withdrawal processor” from [3.1.1](3_002e1.xhtml#g_t3_002e1_002e1) created by calling the procedure 138 | 139 | ``` {.scheme} 140 | (define (make-withdraw balance) 141 | (lambda (amount) 142 | (if (>= balance amount) 143 | (begin (set! balance 144 | (- balance amount)) 145 | balance) 146 | "Insufficient funds"))) 147 | ``` 148 | 149 | Let us describe the evaluation of 150 | 151 | ``` {.scheme} 152 | (define W1 (make-withdraw 100)) 153 | ``` 154 | 155 | followed by 156 | 157 | ``` {.scheme} 158 | (W1 50) 159 | 50 160 | ``` 161 | 162 | [Figure 3.6](#Figure-3_002e6) shows the result of defining the `make-withdraw` procedure in the global environment. This produces a procedure object that contains a pointer to the global environment. So far, this is no different from the examples we have already seen, except that the body of the procedure is itself a λ-expression. 163 | 164 | ![](fig/chap3/Fig3.6c.std.svg 620.64x442.44) 165 | **Figure 3.6:** Result of defining `make-withdraw` in the global environment. 166 | 167 | The interesting part of the computation happens when we apply the procedure `make-withdraw` to an argument: 168 | 169 | ``` {.scheme} 170 | (define W1 (make-withdraw 100)) 171 | ``` 172 | 173 | We begin, as usual, by setting up an environment E1 in which the formal parameter `balance` is bound to the argument 100. Within this environment, we evaluate the body of `make-withdraw`, namely the λ-expression. This constructs a new procedure object, whose code is as specified by the `lambda` and whose environment is E1, the environment in which the `lambda` was evaluated to produce the procedure. The resulting procedure object is the value returned by the call to `make-withdraw`. This is bound to `W1` in the global environment, since the `define` itself is being evaluated in the global environment. [Figure 3.7](#Figure-3_002e7) shows the resulting environment structure. 174 | 175 | ![](fig/chap3/Fig3.7b.std.svg 708.72x484.92) 176 | **Figure 3.7:** Result of evaluating `(define W1 (make-withdraw 100))`. 177 | 178 | Now we can analyze what happens when `W1` is applied to an argument: 179 | 180 | ``` {.scheme} 181 | (W1 50) 182 | 50 183 | ``` 184 | 185 | We begin by constructing a frame in which `amount`, the formal parameter of `W1`, is bound to the argument 50. The crucial point to observe is that this frame has as its enclosing environment not the global environment, but rather the environment E1, because this is the environment that is specified by the `W1` procedure object. Within this new environment, we evaluate the body of the procedure: 186 | 187 | ``` {.scheme} 188 | (if (>= balance amount) 189 | (begin (set! balance (- balance amount)) 190 | balance) 191 | "Insufficient funds") 192 | ``` 193 | 194 | The resulting environment structure is shown in [Figure 3.8](#Figure-3_002e8). The expression being evaluated references both `amount` and `balance`. `Amount` will be found in the first frame in the environment, while `balance` will be found by following the enclosing-environment pointer to E1. 195 | 196 | ![](fig/chap3/Fig3.8c.std.svg 707.64x524.28) 197 | **Figure 3.8:** Environments created by applying the procedure object `W1`. 198 | 199 | When the `set!` is executed, the binding of `balance` in E1 is changed. At the completion of the call to `W1`, `balance` is 50, and the frame that contains `balance` is still pointed to by the procedure object `W1`. The frame that binds `amount` (in which we executed the code that changed `balance`) is no longer relevant, since the procedure call that constructed it has terminated, and there are no pointers to that frame from other parts of the environment. The next time `W1` is called, this will build a new frame that binds `amount` and whose enclosing environment is E1. We see that E1 serves as the “place” that holds the local state variable for the procedure object `W1`. [Figure 3.9](#Figure-3_002e9) shows the situation after the call to `W1`. 200 | 201 | ![](fig/chap3/Fig3.9b.std.svg 713.88x392.64) 202 | **Figure 3.9:** Environments after the call to `W1`. 203 | 204 | Observe what happens when we create a second “withdraw” object by making another call to `make-withdraw`: 205 | 206 | ``` {.scheme} 207 | (define W2 (make-withdraw 100)) 208 | ``` 209 | 210 | This produces the environment structure of [Figure 3.10](#Figure-3_002e10), which shows that `W2` is a procedure object, that is, a pair with some code and an environment. The environment E2 for `W2` was created by the call to `make-withdraw`. It contains a frame with its own local binding for `balance`. On the other hand, `W1` and `W2` have the same code: the code specified by the λ-expression in the body of `make-withdraw`.^[Whether `W1` and `W2` share the same physical code stored in the computer, or whether they each keep a copy of the code, is a detail of the implementation. For the interpreter we implement in [Chapter 4](Chapter-4.xhtml#Chapter-4), the code is in fact shared.] We see here why `W1` and `W2` behave as independent objects. Calls to `W1` reference the state variable `balance` stored in E1, whereas calls to `W2` reference the `balance` stored in E2. Thus, changes to the local state of one object do not affect the other object. 211 | 212 | ![](fig/chap3/Fig3.10b.std.svg 715.92x464.16) 213 | **Figure 3.10:** Using `(define W2 (make-withdraw 100))` to create a second object. 214 | 215 | **Exercise 3.10:** In the `make-withdraw` procedure, the local variable `balance` is created as a parameter of `make-withdraw`. We could also create the local state variable explicitly, using `let`, as follows: 216 | 217 | 218 | ``` {.scheme} 219 | (define (make-withdraw initial-amount) 220 | (let ((balance initial-amount)) 221 | (lambda (amount) 222 | (if (>= balance amount) 223 | (begin (set! balance 224 | (- balance amount)) 225 | balance) 226 | "Insufficient funds")))) 227 | ``` 228 | 229 | 230 | Recall from [1.3.2](1_002e3.xhtml#g_t1_002e3_002e2) that `let` is simply syntactic sugar for a procedure call: 231 | 232 | 233 | ``` {.scheme} 234 | (let ((⟨var⟩ ⟨exp⟩)) ⟨body⟩) 235 | ``` 236 | 237 | 238 | is interpreted as an alternate syntax for 239 | 240 | 241 | ``` {.scheme} 242 | ((lambda (⟨var⟩) ⟨body⟩) ⟨exp⟩) 243 | ``` 244 | 245 | 246 | Use the environment model to analyze this alternate version of `make-withdraw`, drawing figures like the ones above to illustrate the interactions 247 | 248 | 249 | ``` {.scheme} 250 | (define W1 (make-withdraw 100)) 251 | (W1 50) 252 | (define W2 (make-withdraw 100)) 253 | ``` 254 | 255 | 256 | Show that the two versions of `make-withdraw` create objects with the same behavior. How do the environment structures differ for the two versions? 257 | 258 | 259 | ## 3.2.4 Internal Definitions 260 | 261 | Section [1.1.8](1_002e1.xhtml#g_t1_002e1_002e8) introduced the idea that procedures can have internal definitions, thus leading to a block structure as in the following procedure to compute square roots: 262 | 263 | ``` {.scheme} 264 | (define (sqrt x) 265 | (define (good-enough? guess) 266 | (< (abs (- (square guess) x)) 0.001)) 267 | (define (improve guess) 268 | (average guess (/ x guess))) 269 | (define (sqrt-iter guess) 270 | (if (good-enough? guess) 271 | guess 272 | (sqrt-iter (improve guess)))) 273 | (sqrt-iter 1.0)) 274 | ``` 275 | 276 | Now we can use the environment model to see why these internal definitions behave as desired. [Figure 3.11](#Figure-3_002e11) shows the point in the evaluation of the expression `(sqrt 2)` where the internal procedure `good-enough?` has been called for the first time with `guess` equal to 1. 277 | 278 | ![](fig/chap3/Fig3.11b.std.svg 720.12x682.8) 279 | **Figure 3.11:** `Sqrt` procedure with internal definitions. 280 | 281 | Observe the structure of the environment. `Sqrt` is a symbol in the global environment that is bound to a procedure object whose associated environment is the global environment. When `sqrt` was called, a new environment E1 was formed, subordinate to the global environment, in which the parameter `x` is bound to 2. The body of `sqrt` was then evaluated in E1. Since the first expression in the body of `sqrt` is 282 | 283 | ``` {.scheme} 284 | (define (good-enough? guess) 285 | (< (abs (- (square guess) x)) 0.001)) 286 | ``` 287 | 288 | evaluating this expression defined the procedure `good-enough?` in the environment E1. To be more precise, the symbol `good-enough?` was added to the first frame of E1, bound to a procedure object whose associated environment is E1. Similarly, `improve` and `sqrt-iter` were defined as procedures in E1. For conciseness, [Figure 3.11](#Figure-3_002e11) shows only the procedure object for `good-enough?`. 289 | 290 | After the local procedures were defined, the expression `(sqrt-iter 1.0)` was evaluated, still in environment E1. So the procedure object bound to `sqrt-iter` in E1 was called with 1 as an argument. This created an environment E2 in which `guess`, the parameter of `sqrt-iter`, is bound to 1. `Sqrt-iter` in turn called `good-enough?` with the value of `guess` (from E2) as the argument for `good-enough?`. This set up another environment, E3, in which `guess` (the parameter of `good-enough?`) is bound to 1. Although `sqrt-iter` and `good-enough?` both have a parameter named `guess`, these are two distinct local variables located in different frames. Also, E2 and E3 both have E1 as their enclosing environment, because the `sqrt-iter` and `good-enough?` procedures both have E1 as their environment part. One consequence of this is that the symbol `x` that appears in the body of `good-enough?` will reference the binding of `x` that appears in E1, namely the value of `x` with which the original `sqrt` procedure was called. 291 | 292 | The environment model thus explains the two key properties that make local procedure definitions a useful technique for modularizing programs: 293 | 294 | - The names of the local procedures do not interfere with names external to the enclosing procedure, because the local procedure names will be bound in the frame that the procedure creates when it is run, rather than being bound in the global environment. 295 | - The local procedures can access the arguments of the enclosing procedure, simply by using parameter names as free variables. This is because the body of the local procedure is evaluated in an environment that is subordinate to the evaluation environment for the enclosing procedure. 296 | 297 | **Exercise 3.11:** In [3.2.3](#g_t3_002e2_002e3) we saw how the environment model described the behavior of procedures with local state. Now we have seen how internal definitions work. A typical message-passing procedure contains both of these aspects. Consider the bank account procedure of [3.1.1](3_002e1.xhtml#g_t3_002e1_002e1): 298 | 299 | 300 | ``` {.scheme} 301 | (define (make-account balance) 302 | (define (withdraw amount) 303 | (if (>= balance amount) 304 | (begin (set! balance 305 | (- balance 306 | amount)) 307 | balance) 308 | "Insufficient funds")) 309 | (define (deposit amount) 310 | (set! balance (+ balance amount)) 311 | balance) 312 | (define (dispatch m) 313 | (cond ((eq? m 'withdraw) withdraw) 314 | ((eq? m 'deposit) deposit) 315 | (else (error "Unknown request: 316 | MAKE-ACCOUNT" 317 | m)))) 318 | dispatch) 319 | ``` 320 | 321 | 322 | Show the environment structure generated by the sequence of interactions 323 | 324 | 325 | ``` {.scheme} 326 | (define acc (make-account 50)) 327 | 328 | ((acc 'deposit) 40) 329 | 90 330 | 331 | ((acc 'withdraw) 60) 332 | 30 333 | ``` 334 | 335 | 336 | Where is the local state for `acc` kept? Suppose we define another account 337 | 338 | 339 | ``` {.scheme} 340 | (define acc2 (make-account 100)) 341 | ``` 342 | 343 | 344 | How are the local states for the two accounts kept distinct? Which parts of the environment structure are shared between `acc` and `acc2`? 345 | -------------------------------------------------------------------------------- /capitulos/04-00-abstracao-metalinguistica.md: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/has256/sicp-ptbr/856d0fd1f262ee49522e544a13a912301c9e52b8/capitulos/04-00-abstracao-metalinguistica.md -------------------------------------------------------------------------------- /capitulos/04-02-avaliacao-ociosa.md: -------------------------------------------------------------------------------- 1 | # 4.2 Variations on a Scheme — Lazy Evaluation 2 | 3 | Now that we have an evaluator expressed as a Lisp program, we can experiment with alternative choices in language design simply by modifying the evaluator. Indeed, new languages are often invented by first writing an evaluator that embeds the new language within an existing high-level language. For example, if we wish to discuss some aspect of a proposed modification to Lisp with another member of the Lisp community, we can supply an evaluator that embodies the change. The recipient can then experiment with the new evaluator and send back comments as further modifications. Not only does the high-level implementation base make it easier to test and debug the evaluator; in addition, the embedding enables the designer to snarf^[Snarf: “To grab, especially a large document or file for the purpose of using it either with or without the owner’s permission.” Snarf down: “To snarf, sometimes with the connotation of absorbing, processing, or understanding.” (These definitions were snarfed from [Steele et al. 1983](References.xhtml#Steele-et-al_002e-1983). See also [Raymond 1993](References.xhtml#Raymond-1993).)] features from the underlying language, just as our embedded Lisp evaluator uses primitives and control structure from the underlying Lisp. Only later (if ever) need the designer go to the trouble of building a complete implementation in a low-level language or in hardware. In this section and the next we explore some variations on Scheme that provide significant additional expressive power. 4 | 5 | 6 | ## 4.2.1 Normal Order and Applicative Order 7 | 8 | In [1.1](1_002e1.xhtml#g_t1_002e1), where we began our discussion of models of evaluation, we noted that Scheme is an *applicative-order* language, namely, that all the arguments to Scheme procedures are evaluated when the procedure is applied. In contrast, *normal-order* languages delay evaluation of procedure arguments until the actual argument values are needed. Delaying evaluation of procedure arguments until the last possible moment (e.g., until they are required by a primitive operation) is called *lazy evaluation*.^[The difference between the “lazy” terminology and the “normal-order” terminology is somewhat fuzzy. Generally, “lazy” refers to the mechanisms of particular evaluators, while “normal-order” refers to the semantics of languages, independent of any particular evaluation strategy. But this is not a hard-and-fast distinction, and the two terminologies are often used interchangeably.] Consider the procedure 9 | 10 | ``` {.scheme} 11 | (define (try a b) 12 | (if (= a 0) 1 b)) 13 | ``` 14 | 15 | Evaluating `(try 0 (/ 1 0))` generates an error in Scheme. With lazy evaluation, there would be no error. Evaluating the expression would return 1, because the argument `(/ 1 0)` would never be evaluated. 16 | 17 | An example that exploits lazy evaluation is the definition of a procedure `unless` 18 | 19 | ``` {.scheme} 20 | (define (unless condition 21 | usual-value 22 | exceptional-value) 23 | (if condition 24 | exceptional-value 25 | usual-value)) 26 | ``` 27 | 28 | that can be used in expressions such as 29 | 30 | ``` {.scheme} 31 | (unless (= b 0) 32 | (/ a b) 33 | (begin 34 | (display "exception: returning 0") 35 | 0)) 36 | ``` 37 | 38 | This won’t work in an applicative-order language because both the usual value and the exceptional value will be evaluated before `unless` is called (compare [Exercise 1.6](1_002e1.xhtml#Exercise-1_002e6)). An advantage of lazy evaluation is that some procedures, such as `unless`, can do useful computation even if evaluation of some of their arguments would produce errors or would not terminate. 39 | 40 | If the body of a procedure is entered before an argument has been evaluated we say that the procedure is *non-strict* in that argument. If the argument is evaluated before the body of the procedure is entered we say that the procedure is *strict* in that argument.^[The “strict” versus “non-strict” terminology means essentially the same thing as “applicative-order” versus “normal-order,” except that it refers to individual procedures and arguments rather than to the language as a whole. At a conference on programming languages you might hear someone say, “The normal-order language Hassle has certain strict primitives. Other procedures take their arguments by lazy evaluation.”] In a purely applicative-order language, all procedures are strict in each argument. In a purely normal-order language, all compound procedures are non-strict in each argument, and primitive procedures may be either strict or non-strict. There are also languages (see [Exercise 4.31](#Exercise-4_002e31)) that give programmers detailed control over the strictness of the procedures they define. 41 | 42 | A striking example of a procedure that can usefully be made non-strict is `cons` (or, in general, almost any constructor for data structures). One can do useful computation, combining elements to form data structures and operating on the resulting data structures, even if the values of the elements are not known. It makes perfect sense, for instance, to compute the length of a list without knowing the values of the individual elements in the list. We will exploit this idea in [4.2.3](#g_t4_002e2_002e3) to implement the streams of [Chapter 3](Chapter-3.xhtml#Chapter-3) as lists formed of non-strict `cons` pairs. 43 | 44 | **Exercise 4.25:** Suppose that (in ordinary applicative-order Scheme) we define `unless` as shown above and then define `factorial` in terms of `unless` as 45 | 46 | 47 | ``` {.scheme} 48 | (define (factorial n) 49 | (unless (= n 1) 50 | (* n (factorial (- n 1))) 51 | 1)) 52 | ``` 53 | 54 | 55 | What happens if we attempt to evaluate `(factorial 5)`? Will our definitions work in a normal-order language? 56 | 57 | **Exercise 4.26:** Ben Bitdiddle and Alyssa P. Hacker disagree over the importance of lazy evaluation for implementing things such as `unless`. Ben points out that it’s possible to implement `unless` in applicative order as a special form. Alyssa counters that, if one did that, `unless` would be merely syntax, not a procedure that could be used in conjunction with higher-order procedures. Fill in the details on both sides of the argument. Show how to implement `unless` as a derived expression (like `cond` or `let`), and give an example of a situation where it might be useful to have `unless` available as a procedure, rather than as a special form. 58 | 59 | 60 | ## 4.2.2 An Interpreter with Lazy Evaluation 61 | 62 | In this section we will implement a normal-order language that is the same as Scheme except that compound procedures are non-strict in each argument. Primitive procedures will still be strict. It is not difficult to modify the evaluator of [4.1.1](4_002e1.xhtml#g_t4_002e1_002e1) so that the language it interprets behaves this way. Almost all the required changes center around procedure application. 63 | 64 | The basic idea is that, when applying a procedure, the interpreter must determine which arguments are to be evaluated and which are to be delayed. The delayed arguments are not evaluated; instead, they are transformed into objects called *thunks*.^[The word *thunk* was invented by an informal working group that was discussing the implementation of call-by-name in Algol 60. They observed that most of the analysis of (“thinking about”) the expression could be done at compile time; thus, at run time, the expression would already have been “thunk” about ([Ingerman et al. 1960](References.xhtml#Ingerman-et-al_002e-1960)).] The thunk must contain the information required to produce the value of the argument when it is needed, as if it had been evaluated at the time of the application. Thus, the thunk must contain the argument expression and the environment in which the procedure application is being evaluated. 65 | 66 | The process of evaluating the expression in a thunk is called *forcing*.^[This is analogous to the use of `force` on the delayed objects that were introduced in [Chapter 3](Chapter-3.xhtml#Chapter-3) to represent streams. The critical difference between what we are doing here and what we did in [Chapter 3](Chapter-3.xhtml#Chapter-3) is that we are building delaying and forcing into the evaluator, and thus making this uniform and automatic throughout the language.] In general, a thunk will be forced only when its value is needed: when it is passed to a primitive procedure that will use the value of the thunk; when it is the value of a predicate of a conditional; and when it is the value of an operator that is about to be applied as a procedure. One design choice we have available is whether or not to *memoize* thunks, as we did with delayed objects in [3.5.1](3_002e5.xhtml#g_t3_002e5_002e1). With memoization, the first time a thunk is forced, it stores the value that is computed. Subsequent forcings simply return the stored value without repeating the computation. We’ll make our interpreter memoize, because this is more efficient for many applications. There are tricky considerations here, however.^[Lazy evaluation combined with memoization is sometimes referred to as *call-by-need* argument passing, in contrast to *call-by-name* argument passing. (Call-by-name, introduced in Algol 60, is similar to non-memoized lazy evaluation.) As language designers, we can build our evaluator to memoize, not to memoize, or leave this an option for programmers ([Exercise 4.31](#Exercise-4_002e31)). As you might expect from [Chapter 3](Chapter-3.xhtml#Chapter-3), these choices raise issues that become both subtle and confusing in the presence of assignments. (See [Exercise 4.27](#Exercise-4_002e27) and [Exercise 4.29](#Exercise-4_002e29).) An excellent article by [Clinger (1982)](References.xhtml#Clinger-_00281982_0029) attempts to clarify the multiple dimensions of confusion that arise here.] 67 | 68 | 69 | ### Modifying the evaluator 70 | 71 | The main difference between the lazy evaluator and the one in [4.1](4_002e1.xhtml#g_t4_002e1) is in the handling of procedure applications in `eval` and `apply`. 72 | 73 | The `application?` clause of `eval` becomes 74 | 75 | ``` {.scheme} 76 | ((application? exp) 77 | (apply (actual-value (operator exp) env) 78 | (operands exp) 79 | env)) 80 | ``` 81 | 82 | This is almost the same as the `application?` clause of `eval` in [4.1.1](4_002e1.xhtml#g_t4_002e1_002e1). For lazy evaluation, however, we call `apply` with the operand expressions, rather than the arguments produced by evaluating them. Since we will need the environment to construct thunks if the arguments are to be delayed, we must pass this as well. We still evaluate the operator, because `apply` needs the actual procedure to be applied in order to dispatch on its type (primitive versus compound) and apply it. 83 | 84 | Whenever we need the actual value of an expression, we use 85 | 86 | ``` {.scheme} 87 | (define (actual-value exp env) 88 | (force-it (eval exp env))) 89 | ``` 90 | 91 | instead of just `eval`, so that if the expression’s value is a thunk, it will be forced. 92 | 93 | Our new version of `apply` is also almost the same as the version in [4.1.1](4_002e1.xhtml#g_t4_002e1_002e1). The difference is that `eval` has passed in unevaluated operand expressions: For primitive procedures (which are strict), we evaluate all the arguments before applying the primitive; for compound procedures (which are non-strict) we delay all the arguments before applying the procedure. 94 | 95 | ``` {.scheme} 96 | (define (apply procedure arguments env) 97 | (cond ((primitive-procedure? procedure) 98 | (apply-primitive-procedure 99 | procedure 100 | (list-of-arg-values 101 | arguments 102 | env))) ; changed 103 | ((compound-procedure? procedure) 104 | (eval-sequence 105 | (procedure-body procedure) 106 | (extend-environment 107 | (procedure-parameters procedure) 108 | (list-of-delayed-args 109 | arguments 110 | env) ; changed 111 | (procedure-environment procedure)))) 112 | (else (error "Unknown procedure 113 | type: APPLY" 114 | procedure)))) 115 | ``` 116 | 117 | The procedures that process the arguments are just like `list-of-values` from [4.1.1](4_002e1.xhtml#g_t4_002e1_002e1), except that `list-of-delayed-args` delays the arguments instead of evaluating them, and `list-of-arg-values` uses `actual-value` instead of `eval`: 118 | 119 | ``` {.scheme} 120 | (define (list-of-arg-values exps env) 121 | (if (no-operands? exps) 122 | '() 123 | (cons (actual-value 124 | (first-operand exps) 125 | env) 126 | (list-of-arg-values 127 | (rest-operands exps) 128 | env)))) 129 | 130 | (define (list-of-delayed-args exps env) 131 | (if (no-operands? exps) 132 | '() 133 | (cons (delay-it 134 | (first-operand exps) 135 | env) 136 | (list-of-delayed-args 137 | (rest-operands exps) 138 | env)))) 139 | ``` 140 | 141 | The other place we must change the evaluator is in the handling of `if`, where we must use `actual-value` instead of `eval` to get the value of the predicate expression before testing whether it is true or false: 142 | 143 | ``` {.scheme} 144 | (define (eval-if exp env) 145 | (if (true? (actual-value (if-predicate exp) 146 | env)) 147 | (eval (if-consequent exp) env) 148 | (eval (if-alternative exp) env))) 149 | ``` 150 | 151 | Finally, we must change the `driver-loop` procedure ([4.1.4](4_002e1.xhtml#g_t4_002e1_002e4)) to use `actual-value` instead of `eval`, so that if a delayed value is propagated back to the read-eval-print loop, it will be forced before being printed. We also change the prompts to indicate that this is the lazy evaluator: 152 | 153 | ``` {.scheme} 154 | (define input-prompt ";;; L-Eval input:") 155 | (define output-prompt ";;; L-Eval value:") 156 | 157 | (define (driver-loop) 158 | (prompt-for-input input-prompt) 159 | (let ((input (read))) 160 | (let ((output (actual-value 161 | input 162 | the-global-environment))) 163 | (announce-output output-prompt) 164 | (user-print output))) 165 | (driver-loop)) 166 | ``` 167 | 168 | With these changes made, we can start the evaluator and test it. The successful evaluation of the `try` expression discussed in [4.2.1](#g_t4_002e2_002e1) indicates that the interpreter is performing lazy evaluation: 169 | 170 | ``` {.scheme} 171 | (define the-global-environment 172 | (setup-environment)) 173 | 174 | (driver-loop) 175 | 176 | ;;; L-Eval input: 177 | (define (try a b) (if (= a 0) 1 b)) 178 | 179 | ;;; L-Eval value: 180 | ok 181 | 182 | ;;; L-Eval input: 183 | (try 0 (/ 1 0)) 184 | 185 | ;;; L-Eval value: 186 | 1 187 | ``` 188 | 189 | 190 | ### Representing thunks 191 | 192 | Our evaluator must arrange to create thunks when procedures are applied to arguments and to force these thunks later. A thunk must package an expression together with the environment, so that the argument can be produced later. To force the thunk, we simply extract the expression and environment from the thunk and evaluate the expression in the environment. We use `actual-value` rather than `eval` so that in case the value of the expression is itself a thunk, we will force that, and so on, until we reach something that is not a thunk: 193 | 194 | ``` {.scheme} 195 | (define (force-it obj) 196 | (if (thunk? obj) 197 | (actual-value (thunk-exp obj) 198 | (thunk-env obj)) 199 | obj)) 200 | ``` 201 | 202 | One easy way to package an expression with an environment is to make a list containing the expression and the environment. Thus, we create a thunk as follows: 203 | 204 | ``` {.scheme} 205 | (define (delay-it exp env) 206 | (list 'thunk exp env)) 207 | (define (thunk? obj) (tagged-list? obj 'thunk)) 208 | (define (thunk-exp thunk) (cadr thunk)) 209 | (define (thunk-env thunk) (caddr thunk)) 210 | ``` 211 | 212 | Actually, what we want for our interpreter is not quite this, but rather thunks that have been memoized. When a thunk is forced, we will turn it into an evaluated thunk by replacing the stored expression with its value and changing the `thunk` tag so that it can be recognized as already evaluated.^[Notice that we also erase the `env` from the thunk once the expression’s value has been computed. This makes no difference in the values returned by the interpreter. It does help save space, however, because removing the reference from the thunk to the `env` once it is no longer needed allows this structure to be *garbage-collected* and its space recycled, as we will discuss in [5.3](5_002e3.xhtml#g_t5_002e3).] 213 | 214 | ``` {.scheme} 215 | (define (evaluated-thunk? obj) 216 | (tagged-list? obj 'evaluated-thunk)) 217 | 218 | (define (thunk-value evaluated-thunk) 219 | (cadr evaluated-thunk)) 220 | 221 | (define (force-it obj) 222 | (cond ((thunk? obj) 223 | (let ((result 224 | (actual-value 225 | (thunk-exp obj) 226 | (thunk-env obj)))) 227 | (set-car! obj 'evaluated-thunk) 228 | ;; replace exp with its value: 229 | (set-car! (cdr obj) result) 230 | ;; forget unneeded env: 231 | (set-cdr! (cdr obj) '()) 232 | result)) 233 | ((evaluated-thunk? obj) 234 | (thunk-value obj)) 235 | (else obj))) 236 | ``` 237 | 238 | Notice that the same `delay-it` procedure works both with and without memoization. 239 | 240 | **Exercise 4.27:** Suppose we type in the following definitions to the lazy evaluator: 241 | 242 | 243 | ``` {.scheme} 244 | (define count 0) 245 | (define (id x) (set! count (+ count 1)) x) 246 | ``` 247 | 248 | 249 | Give the missing values in the following sequence of interactions, and explain your answers.^[This exercise demonstrates that the interaction between lazy evaluation and side effects can be very confusing. This is just what you might expect from the discussion in [Chapter 3](Chapter-3.xhtml#Chapter-3).] 250 | 251 | 252 | ``` {.scheme} 253 | (define w (id (id 10))) 254 | 255 | ;;; L-Eval input: 256 | count 257 | 258 | ;;; L-Eval value: 259 | ⟨response⟩ 260 | 261 | ;;; L-Eval input: 262 | w 263 | 264 | ;;; L-Eval value: 265 | ⟨response⟩ 266 | 267 | ;;; L-Eval input: 268 | count 269 | 270 | ;;; L-Eval value: 271 | ⟨response⟩ 272 | ``` 273 | 274 | 275 | **Exercise 4.28:** `Eval` uses `actual-value` rather than `eval` to evaluate the operator before passing it to `apply`, in order to force the value of the operator. Give an example that demonstrates the need for this forcing. 276 | 277 | **Exercise 4.29:** Exhibit a program that you would expect to run much more slowly without memoization than with memoization. Also, consider the following interaction, where the `id` procedure is defined as in [Exercise 4.27](#Exercise-4_002e27) and `count` starts at 0: 278 | 279 | 280 | ``` {.scheme} 281 | (define (square x) (* x x)) 282 | 283 | ;;; L-Eval input: 284 | (square (id 10)) 285 | 286 | ;;; L-Eval value: 287 | ⟨response⟩ 288 | 289 | ;;; L-Eval input: 290 | count 291 | 292 | ;;; L-Eval value: 293 | ⟨response⟩ 294 | ``` 295 | 296 | 297 | Give the responses both when the evaluator memoizes and when it does not. 298 | 299 | **Exercise 4.30:** Cy D. Fect, a reformed C programmer, is worried that some side effects may never take place, because the lazy evaluator doesn’t force the expressions in a sequence. Since the value of an expression in a sequence other than the last one is not used (the expression is there only for its effect, such as assigning to a variable or printing), there can be no subsequent use of this value (e.g., as an argument to a primitive procedure) that will cause it to be forced. Cy thus thinks that when evaluating sequences, we must force all expressions in the sequence except the final one. He proposes to modify `eval-sequence` from [4.1.1](4_002e1.xhtml#g_t4_002e1_002e1) to use `actual-value` rather than `eval`: 300 | 301 | 302 | ``` {.scheme} 303 | (define (eval-sequence exps env) 304 | (cond ((last-exp? exps) 305 | (eval (first-exp exps) env)) 306 | (else 307 | (actual-value (first-exp exps) 308 | env) 309 | (eval-sequence (rest-exps exps) 310 | env)))) 311 | ``` 312 | 313 | 314 | 1. Ben Bitdiddle thinks Cy is wrong. He shows Cy the `for-each` procedure described in [Exercise 2.23](2_002e2.xhtml#Exercise-2_002e23), which gives an important example of a sequence with side effects: 315 | 316 | ``` {.scheme} 317 | (define (for-each proc items) 318 | (if (null? items) 319 | 'done 320 | (begin (proc (car items)) 321 | (for-each proc 322 | (cdr items))))) 323 | ``` 324 | 325 | 326 | He claims that the evaluator in the text (with the original `eval-sequence`) handles this correctly: 327 | 328 | ``` {.scheme} 329 | ;;; L-Eval input: 330 | (for-each 331 | (lambda (x) (newline) (display x)) 332 | (list 57 321 88)) 333 | 57 334 | 321 335 | 88 336 | 337 | ;;; L-Eval value: 338 | done 339 | ``` 340 | 341 | 342 | Explain why Ben is right about the behavior of `for-each`. 343 | 344 | 2. Cy agrees that Ben is right about the `for-each` example, but says that that’s not the kind of program he was thinking about when he proposed his change to `eval-sequence`. He defines the following two procedures in the lazy evaluator: 345 | 346 | ``` {.scheme} 347 | (define (p1 x) 348 | (set! x (cons x '(2))) x) 349 | 350 | (define (p2 x) 351 | (define (p e) e x) 352 | (p (set! x (cons x '(2))))) 353 | ``` 354 | 355 | 356 | What are the values of `(p1 1)` and `(p2 1)` with the original `eval-sequence`? What would the values be with Cy’s proposed change to `eval-sequence`? 357 | 358 | 3. Cy also points out that changing `eval-sequence` as he proposes does not affect the behavior of the example in part a. Explain why this is true. 359 | 4. How do you think sequences ought to be treated in the lazy evaluator? Do you like Cy’s approach, the approach in the text, or some other approach? 360 | 361 | **Exercise 4.31:** The approach taken in this section is somewhat unpleasant, because it makes an incompatible change to Scheme. It might be nicer to implement lazy evaluation as an *upward-compatible extension*, that is, so that ordinary Scheme programs will work as before. We can do this by extending the syntax of procedure declarations to let the user control whether or not arguments are to be delayed. While we’re at it, we may as well also give the user the choice between delaying with and without memoization. For example, the definition 362 | 363 | 364 | ``` {.scheme} 365 | (define (f a (b lazy) c (d lazy-memo)) 366 | …) 367 | ``` 368 | 369 | 370 | would define `f` to be a procedure of four arguments, where the first and third arguments are evaluated when the procedure is called, the second argument is delayed, and the fourth argument is both delayed and memoized. Thus, ordinary procedure definitions will produce the same behavior as ordinary Scheme, while adding the `lazy-memo` declaration to each parameter of every compound procedure will produce the behavior of the lazy evaluator defined in this section. Design and implement the changes required to produce such an extension to Scheme. You will have to implement new syntax procedures to handle the new syntax for `define`. You must also arrange for `eval` or `apply` to determine when arguments are to be delayed, and to force or delay arguments accordingly, and you must arrange for forcing to memoize or not, as appropriate. 371 | 372 | 373 | ## 4.2.3 Streams as Lazy Lists 374 | 375 | In [3.5.1](3_002e5.xhtml#g_t3_002e5_002e1), we showed how to implement streams as delayed lists. We introduced special forms `delay` and `cons-stream`, which allowed us to construct a “promise” to compute the `cdr` of a stream, without actually fulfilling that promise until later. We could use this general technique of introducing special forms whenever we need more control over the evaluation process, but this is awkward. For one thing, a special form is not a first-class object like a procedure, so we cannot use it together with higher-order procedures.^[This is precisely the issue with the `unless` procedure, as in [Exercise 4.26](#Exercise-4_002e26).] Additionally, we were forced to create streams as a new kind of data object similar but not identical to lists, and this required us to reimplement many ordinary list operations (`map`, `append`, and so on) for use with streams. 376 | 377 | With lazy evaluation, streams and lists can be identical, so there is no need for special forms or for separate list and stream operations. All we need to do is to arrange matters so that `cons` is non-strict. One way to accomplish this is to extend the lazy evaluator to allow for non-strict primitives, and to implement `cons` as one of these. An easier way is to recall ([2.1.3](2_002e1.xhtml#g_t2_002e1_002e3)) that there is no fundamental need to implement `cons` as a primitive at all. Instead, we can represent pairs as procedures:^[This is the procedural representation described in [Exercise 2.4](2_002e1.xhtml#Exercise-2_002e4). Essentially any procedural representation (e.g., a message-passing implementation) would do as well. Notice that we can install these definitions in the lazy evaluator simply by typing them at the driver loop. If we had originally included `cons`, `car`, and `cdr` as primitives in the global environment, they will be redefined. (Also see [Exercise 4.33](#Exercise-4_002e33) and [Exercise 4.34](#Exercise-4_002e34).)] 378 | 379 | ``` {.scheme} 380 | (define (cons x y) (lambda (m) (m x y))) 381 | (define (car z) (z (lambda (p q) p))) 382 | (define (cdr z) (z (lambda (p q) q))) 383 | ``` 384 | 385 | In terms of these basic operations, the standard definitions of the list operations will work with infinite lists (streams) as well as finite ones, and the stream operations can be implemented as list operations. Here are some examples: 386 | 387 | ``` {.scheme} 388 | (define (list-ref items n) 389 | (if (= n 0) 390 | (car items) 391 | (list-ref (cdr items) (- n 1)))) 392 | 393 | (define (map proc items) 394 | (if (null? items) 395 | '() 396 | (cons (proc (car items)) 397 | (map proc (cdr items))))) 398 | 399 | (define (scale-list items factor) 400 | (map (lambda (x) (* x factor)) 401 | items)) 402 | 403 | (define (add-lists list1 list2) 404 | (cond ((null? list1) list2) 405 | ((null? list2) list1) 406 | (else (cons (+ (car list1) 407 | (car list2)) 408 | (add-lists 409 | (cdr list1) 410 | (cdr list2)))))) 411 | 412 | (define ones (cons 1 ones)) 413 | 414 | (define integers 415 | (cons 1 (add-lists ones integers))) 416 | 417 | ;;; L-Eval input: 418 | (list-ref integers 17) 419 | 420 | ;;; L-Eval value: 421 | 18 422 | ``` 423 | 424 | Note that these lazy lists are even lazier than the streams of [Chapter 3](Chapter-3.xhtml#Chapter-3): The `car` of the list, as well as the `cdr`, is delayed.^[This permits us to create delayed versions of more general kinds of list structures, not just sequences. [Hughes 1990](References.xhtml#Hughes-1990) discusses some applications of “lazy trees.”] In fact, even accessing the `car` or `cdr` of a lazy pair need not force the value of a list element. The value will be forced only when it is really needed—e.g., for use as the argument of a primitive, or to be printed as an answer. 425 | 426 | Lazy pairs also help with the problem that arose with streams in [3.5.4](3_002e5.xhtml#g_t3_002e5_002e4), where we found that formulating stream models of systems with loops may require us to sprinkle our programs with explicit `delay` operations, beyond the ones supplied by `cons-stream`. With lazy evaluation, all arguments to procedures are delayed uniformly. For instance, we can implement procedures to integrate lists and solve differential equations as we originally intended in [3.5.4](3_002e5.xhtml#g_t3_002e5_002e4): 427 | 428 | ``` {.scheme} 429 | (define (integral integrand initial-value dt) 430 | (define int 431 | (cons initial-value 432 | (add-lists (scale-list integrand dt) 433 | int))) 434 | int) 435 | 436 | (define (solve f y0 dt) 437 | (define y (integral dy y0 dt)) 438 | (define dy (map f y)) 439 | y) 440 | 441 | ;;; L-Eval input: 442 | (list-ref (solve (lambda (x) x) 1 0.001) 1000) 443 | 444 | ;;; L-Eval value: 445 | 2.716924 446 | ``` 447 | 448 | **Exercise 4.32:** Give some examples that illustrate the difference between the streams of [Chapter 3](Chapter-3.xhtml#Chapter-3) and the “lazier” lazy lists described in this section. How can you take advantage of this extra laziness? 449 | 450 | **Exercise 4.33:** Ben Bitdiddle tests the lazy list implementation given above by evaluating the expression 451 | 452 | 453 | ``` {.scheme} 454 | (car '(a b c)) 455 | ``` 456 | 457 | 458 | To his surprise, this produces an error. After some thought, he realizes that the “lists” obtained by reading in quoted expressions are different from the lists manipulated by the new definitions of `cons`, `car`, and `cdr`. Modify the evaluator’s treatment of quoted expressions so that quoted lists typed at the driver loop will produce true lazy lists. 459 | 460 | **Exercise 4.34:** Modify the driver loop for the evaluator so that lazy pairs and lists will print in some reasonable way. (What are you going to do about infinite lists?) You may also need to modify the representation of lazy pairs so that the evaluator can identify them in order to print them. 461 | -------------------------------------------------------------------------------- /capitulos/05-00-registradores.md: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/has256/sicp-ptbr/856d0fd1f262ee49522e544a13a912301c9e52b8/capitulos/05-00-registradores.md -------------------------------------------------------------------------------- /capitulos/05-01-design-registradores.md: -------------------------------------------------------------------------------- 1 | # 5.1 Designing Register Machines 2 | 3 | To design a register machine, we must design its *data paths* (registers and operations) and the *controller* that sequences these operations. To illustrate the design of a simple register machine, let us examine Euclid’s Algorithm, which is used to compute the greatest common divisor (GCD) of two integers. As we saw in [1.2.5](1_002e2.xhtml#g_t1_002e2_002e5), Euclid’s Algorithm can be carried out by an iterative process, as specified by the following procedure: 4 | 5 | ``` {.scheme} 6 | (define (gcd a b) 7 | (if (= b 0) 8 | a 9 | (gcd b (remainder a b)))) 10 | ``` 11 | 12 | A machine to carry out this algorithm must keep track of two numbers, $a$ and $b$, so let us assume that these numbers are stored in two registers with those names. The basic operations required are testing whether the contents of register `b` is zero and computing the remainder of the contents of register `a` divided by the contents of register `b`. The remainder operation is a complex process, but assume for the moment that we have a primitive device that computes remainders. On each cycle of the GCD algorithm, the contents of register `a` must be replaced by the contents of register `b`, and the contents of `b` must be replaced by the remainder of the old contents of `a` divided by the old contents of `b`. It would be convenient if these replacements could be done simultaneously, but in our model of register machines we will assume that only one register can be assigned a new value at each step. To accomplish the replacements, our machine will use a third “temporary” register, which we call `t`. (First the remainder will be placed in `t`, then the contents of `b` will be placed in `a`, and finally the remainder stored in `t` will be placed in `b`.) 13 | 14 | We can illustrate the registers and operations required for this machine by using the data-path diagram shown in [Figure 5.1](#Figure-5_002e1). In this diagram, the registers (`a`, `b`, and `t`) are represented by rectangles. Each way to assign a value to a register is indicated by an arrow with an `X` behind the head, pointing from the source of data to the register. We can think of the `X` as a button that, when pushed, allows the value at the source to “flow” into the designated register. The label next to each button is the name we will use to refer to the button. The names are arbitrary, and can be chosen to have mnemonic value (for example, `a<-b` denotes pushing the button that assigns the contents of register `b` to register `a`). The source of data for a register can be another register (as in the `a<-b` assignment), an operation result (as in the `t<-r` assignment), or a constant (a built-in value that cannot be changed, represented in a data-path diagram by a triangle containing the constant). 15 | 16 | 17 | **Figure 5.1:** Data paths for a GCD machine. 18 | 19 | An operation that computes a value from constants and the contents of registers is represented in a data-path diagram by a trapezoid containing a name for the operation. For example, the box marked `rem` in [Figure 5.1](#Figure-5_002e1) represents an operation that computes the remainder of the contents of the registers `a` and `b` to which it is attached. Arrows (without buttons) point from the input registers and constants to the box, and arrows connect the operation’s output value to registers. A test is represented by a circle containing a name for the test. For example, our GCD machine has an operation that tests whether the contents of register `b` is zero. A test also has arrows from its input registers and constants, but it has no output arrows; its value is used by the controller rather than by the data paths. Overall, the data-path diagram shows the registers and operations that are required for the machine and how they must be connected. If we view the arrows as wires and the `X` buttons as switches, the data-path diagram is very like the wiring diagram for a machine that could be constructed from electrical components. 20 | 21 | In order for the data paths to actually compute GCDs, the buttons must be pushed in the correct sequence. We will describe this sequence in terms of a controller diagram, as illustrated in [Figure 5.2](#Figure-5_002e2). The elements of the controller diagram indicate how the data-path components should be operated. The rectangular boxes in the controller diagram identify data-path buttons to be pushed, and the arrows describe the sequencing from one step to the next. The diamond in the diagram represents a decision. One of the two sequencing arrows will be followed, depending on the value of the data-path test identified in the diamond. We can interpret the controller in terms of a physical analogy: Think of the diagram as a maze in which a marble is rolling. When the marble rolls into a box, it pushes the data-path button that is named by the box. When the marble rolls into a decision node (such as the test for `b` = 0), it leaves the node on the path determined by the result of the indicated test. Taken together, the data paths and the controller completely describe a machine for computing GCDs. We start the controller (the rolling marble) at the place marked `start`, after placing numbers in registers `a` and `b`. When the controller reaches `done`, we will find the value of the GCD in register `a`. 22 | 23 | 24 | **Figure 5.2:** Controller for a GCD machine. 25 | 26 | **Exercise 5.1:** Design a register machine to compute factorials using the iterative algorithm specified by the following procedure. Draw data-path and controller diagrams for this machine. 27 | 28 | 29 | ``` {.scheme} 30 | (define (factorial n) 31 | (define (iter product counter) 32 | (if (> counter n) 33 | product 34 | (iter (* counter product) 35 | (+ counter 1)))) 36 | (iter 1 1)) 37 | ``` 38 | 39 | 40 | 41 | ## 5.1.1 A Language for Describing Register Machines 42 | 43 | Data-path and controller diagrams are adequate for representing simple machines such as GCD, but they are unwieldy for describing large machines such as a Lisp interpreter. To make it possible to deal with complex machines, we will create a language that presents, in textual form, all the information given by the data-path and controller diagrams. We will start with a notation that directly mirrors the diagrams. 44 | 45 | We define the data paths of a machine by describing the registers and the operations. To describe a register, we give it a name and specify the buttons that control assignment to it. We give each of these buttons a name and specify the source of the data that enters the register under the button’s control. (The source is a register, a constant, or an operation.) To describe an operation, we give it a name and specify its inputs (registers or constants). 46 | 47 | We define the controller of a machine as a sequence of *instructions* together with *labels* that identify *entry points* in the sequence. An instruction is one of the following: 48 | 49 | - The name of a data-path button to push to assign a value to a register. (This corresponds to a box in the controller diagram.) 50 | - A `test` instruction, that performs a specified test. 51 | - A conditional branch (`branch` instruction) to a location indicated by a controller label, based on the result of the previous test. (The test and branch together correspond to a diamond in the controller diagram.) If the test is false, the controller should continue with the next instruction in the sequence. Otherwise, the controller should continue with the instruction after the label. 52 | - An unconditional branch (`goto` instruction) naming a controller label at which to continue execution. 53 | 54 | The machine starts at the beginning of the controller instruction sequence and stops when execution reaches the end of the sequence. Except when a branch changes the flow of control, instructions are executed in the order in which they are listed. 55 | 56 | [Figure 5.3](#Figure-5_002e3) shows the GCD machine described in this way. This example only hints at the generality of these descriptions, since the GCD machine is a very simple case: Each register has only one button, and each button and test is used only once in the controller. 57 | 58 | > **Figure 5.3:** $\downarrow$ A specification of the GCD machine. 59 | > > ``` {.scheme} 60 | > (data-paths 61 | > (registers 62 | > ((name a) 63 | > (buttons ((name a<-b) 64 | > (source (register b))))) 65 | > ((name b) 66 | > (buttons ((name b<-t) 67 | > (source (register t))))) 68 | > ((name t) 69 | > (buttons ((name t<-r) 70 | > (source (operation rem)))))) 71 | > (operations 72 | > ((name rem) 73 | > (inputs (register a) (register b))) 74 | > ((name =) 75 | > (inputs (register b) (constant 0))))) 76 | > > (controller 77 | > test-b ; label 78 | > (test =) ; test 79 | > (branch 80 | > (label gcd-done)) ; conditional branch 81 | > (t<-r) ; button push 82 | > (a<-b) ; button push 83 | > (b<-t) ; button push 84 | > (goto 85 | > (label test-b)) ; unconditional branch 86 | > gcd-done) ; label 87 | > ``` 88 | 89 | Unfortunately, it is difficult to read such a description. In order to understand the controller instructions we must constantly refer back to the definitions of the button names and the operation names, and to understand what the buttons do we may have to refer to the definitions of the operation names. We will thus transform our notation to combine the information from the data-path and controller descriptions so that we see it all together. 90 | 91 | To obtain this form of description, we will replace the arbitrary button and operation names by the definitions of their behavior. That is, instead of saying (in the controller) “Push button `t<-r`” and separately saying (in the data paths) “Button `t<-r` assigns the value of the `rem` operation to register `t`” and “The `rem` operation’s inputs are the contents of registers `a` and `b`,” we will say (in the controller) “Push the button that assigns to register `t` the value of the `rem` operation on the contents of registers `a` and `b`.” Similarly, instead of saying (in the controller) “Perform the `=` test” and separately saying (in the data paths) “The `=` test operates on the contents of register `b` and the constant 0,” we will say “Perform the `=` test on the contents of register `b` and the constant 0.” We will omit the data-path description, leaving only the controller sequence. Thus, the GCD machine is described as follows: 92 | 93 | ``` {.scheme} 94 | (controller 95 | test-b 96 | (test (op =) (reg b) (const 0)) 97 | (branch (label gcd-done)) 98 | (assign t (op rem) (reg a) (reg b)) 99 | (assign a (reg b)) 100 | (assign b (reg t)) 101 | (goto (label test-b)) 102 | gcd-done) 103 | ``` 104 | 105 | This form of description is easier to read than the kind illustrated in [Figure 5.3](#Figure-5_002e3), but it also has disadvantages: 106 | 107 | - It is more verbose for large machines, because complete descriptions of the data-path elements are repeated whenever the elements are mentioned in the controller instruction sequence. (This is not a problem in the GCD example, because each operation and button is used only once.) Moreover, repeating the data-path descriptions obscures the actual data-path structure of the machine; it is not obvious for a large machine how many registers, operations, and buttons there are and how they are interconnected. 108 | - Because the controller instructions in a machine definition look like Lisp expressions, it is easy to forget that they are not arbitrary Lisp expressions. They can notate only legal machine operations. For example, operations can operate directly only on constants and the contents of registers, not on the results of other operations. 109 | 110 | In spite of these disadvantages, we will use this register-machine language throughout this chapter, because we will be more concerned with understanding controllers than with understanding the elements and connections in data paths. We should keep in mind, however, that data-path design is crucial in designing real machines. 111 | 112 | **Exercise 5.2:** Use the register-machine language to describe the iterative factorial machine of [Exercise 5.1](#Exercise-5_002e1). 113 | 114 | 115 | ### Actions 116 | 117 | Let us modify the GCD machine so that we can type in the numbers whose GCD we want and get the answer printed at our terminal. We will not discuss how to make a machine that can read and print, but will assume (as we do when we use `read` and `display` in Scheme) that they are available as primitive operations.^[This assumption glosses over a great deal of complexity. Usually a large portion of the implementation of a Lisp system is dedicated to making reading and printing work.] 118 | 119 | `Read` is like the operations we have been using in that it produces a value that can be stored in a register. But `read` does not take inputs from any registers; its value depends on something that happens outside the parts of the machine we are designing. We will allow our machine’s operations to have such behavior, and thus will draw and notate the use of `read` just as we do any other operation that computes a value. 120 | 121 | `Print`, on the other hand, differs from the operations we have been using in a fundamental way: It does not produce an output value to be stored in a register. Though it has an effect, this effect is not on a part of the machine we are designing. We will refer to this kind of operation as an *action*. We will represent an action in a data-path diagram just as we represent an operation that computes a value—as a trapezoid that contains the name of the action. Arrows point to the action box from any inputs (registers or constants). We also associate a button with the action. Pushing the button makes the action happen. To make a controller push an action button we use a new kind of instruction called `perform`. Thus, the action of printing the contents of register `a` is represented in a controller sequence by the instruction 122 | 123 | ``` {.scheme} 124 | (perform (op print) (reg a)) 125 | ``` 126 | 127 | [Figure 5.4](#Figure-5_002e4) shows the data paths and controller for the new GCD machine. Instead of having the machine stop after printing the answer, we have made it start over, so that it repeatedly reads a pair of numbers, computes their GCD, and prints the result. This structure is like the driver loops we used in the interpreters of [Chapter 4](Chapter-4.xhtml#Chapter-4). 128 | 129 | 130 | **Figure 5.4:** A GCD machine that reads inputs and prints results. 131 | 132 | 133 | ## 5.1.2 Abstraction in Machine Design 134 | 135 | We will often define a machine to include “primitive” operations that are actually very complex. For example, in [5.4](5_002e4.xhtml#g_t5_002e4) and [5.5](5_002e5.xhtml#g_t5_002e5) we will treat Scheme’s environment manipulations as primitive. Such abstraction is valuable because it allows us to ignore the details of parts of a machine so that we can concentrate on other aspects of the design. The fact that we have swept a lot of complexity under the rug, however, does not mean that a machine design is unrealistic. We can always replace the complex “primitives” by simpler primitive operations. 136 | 137 | Consider the GCD machine. The machine has an instruction that computes the remainder of the contents of registers `a` and `b` and assigns the result to register `t`. If we want to construct the GCD machine without using a primitive remainder operation, we must specify how to compute remainders in terms of simpler operations, such as subtraction. Indeed, we can write a Scheme procedure that finds remainders in this way: 138 | 139 | ``` {.scheme} 140 | (define (remainder n d) 141 | (if (< n d) n (remainder (- n d) d))) 142 | ``` 143 | 144 | We can thus replace the remainder operation in the GCD machine’s data paths with a subtraction operation and a comparison test. [Figure 5.5](#Figure-5_002e5) shows the data paths and controller for the elaborated machine. The instruction 145 | 146 | ``` {.scheme} 147 | (assign t (op rem) (reg a) (reg b)) 148 | ``` 149 | 150 | in the GCD controller definition is replaced by a sequence of instructions that contains a loop, as shown in [Figure 5.6](#Figure-5_002e6). 151 | 152 | 153 | **Figure 5.5:** Data paths and controller for the elaborated GCD machine. 154 | 155 | > **Figure 5.6:** $\downarrow$ Controller instruction sequence for the GCD machine in [Figure 5.5](#Figure-5_002e5). 156 | > > ``` {.scheme} 157 | > (controller 158 | > test-b 159 | > (test (op =) (reg b) (const 0)) 160 | > (branch (label gcd-done)) 161 | > (assign t (reg a)) 162 | > rem-loop 163 | > (test (op <) (reg t) (reg b)) 164 | > (branch (label rem-done)) 165 | > (assign t (op -) (reg t) (reg b)) 166 | > (goto (label rem-loop)) 167 | > rem-done 168 | > (assign a (reg b)) 169 | > (assign b (reg t)) 170 | > (goto (label test-b)) 171 | > gcd-done) 172 | > ``` 173 | 174 | **Exercise 5.3:** Design a machine to compute square roots using Newton’s method, as described in [1.1.7](1_002e1.xhtml#Sec_002e1_002e1_002e7): 175 | 176 | 177 | ``` {.scheme} 178 | (define (sqrt x) 179 | (define (good-enough? guess) 180 | (< (abs (- (square guess) x)) 0.001)) 181 | (define (improve guess) 182 | (average guess (/ x guess))) 183 | (define (sqrt-iter guess) 184 | (if (good-enough? guess) 185 | guess 186 | (sqrt-iter (improve guess)))) 187 | (sqrt-iter 1.0)) 188 | ``` 189 | 190 | 191 | Begin by assuming that `good-enough?` and `improve` operations are available as primitives. Then show how to expand these in terms of arithmetic operations. Describe each version of the `sqrt` machine design by drawing a data-path diagram and writing a controller definition in the register-machine language. 192 | 193 | 194 | ## 5.1.3 Subroutines 195 | 196 | When designing a machine to perform a computation, we would often prefer to arrange for components to be shared by different parts of the computation rather than duplicate the components. Consider a machine that includes two GCD computations—one that finds the GCD of the contents of registers `a` and `b` and one that finds the GCD of the contents of registers `c` and `d`. We might start by assuming we have a primitive `gcd` operation, then expand the two instances of `gcd` in terms of more primitive operations. [Figure 5.7](#Figure-5_002e7) shows just the GCD portions of the resulting machine’s data paths, without showing how they connect to the rest of the machine. The figure also shows the corresponding portions of the machine’s controller sequence. 197 | 198 | 199 | **Figure 5.7:** Portions of the data paths and controller sequence for a machine with two GCD computations. 200 | 201 | This machine has two remainder operation boxes and two boxes for testing equality. If the duplicated components are complicated, as is the remainder box, this will not be an economical way to build the machine. We can avoid duplicating the data-path components by using the same components for both GCD computations, provided that doing so will not affect the rest of the larger machine’s computation. If the values in registers `a` and `b` are not needed by the time the controller gets to `gcd-2` (or if these values can be moved to other registers for safekeeping), we can change the machine so that it uses registers `a` and `b`, rather than registers `c` and `d`, in computing the second GCD as well as the first. If we do this, we obtain the controller sequence shown in [Figure 5.8](#Figure-5_002e8). 202 | 203 | > **Figure 5.8:** $\downarrow$ Portions of the controller sequence for a machine that uses the same data-path components for two different GCD computations. 204 | > > ``` {.scheme} 205 | > gcd-1 206 | > (test (op =) (reg b) (const 0)) 207 | > (branch (label after-gcd-1)) 208 | > (assign t (op rem) (reg a) (reg b)) 209 | > (assign a (reg b)) 210 | > (assign b (reg t)) 211 | > (goto (label gcd-1)) 212 | > after-gcd-1 213 | > … 214 | > gcd-2 215 | > (test (op =) (reg b) (const 0)) 216 | > (branch (label after-gcd-2)) 217 | > (assign t (op rem) (reg a) (reg b)) 218 | > (assign a (reg b)) 219 | > (assign b (reg t)) 220 | > (goto (label gcd-2)) 221 | > after-gcd-2 222 | > ``` 223 | 224 | We have removed the duplicate data-path components (so that the data paths are again as in [Figure 5.1](#Figure-5_002e1)), but the controller now has two GCD sequences that differ only in their entry-point labels. It would be better to replace these two sequences by branches to a single sequence—a `gcd` *subroutine*—at the end of which we branch back to the correct place in the main instruction sequence. We can accomplish this as follows: Before branching to `gcd`, we place a distinguishing value (such as 0 or 1) into a special register, `continue`. At the end of the `gcd` subroutine we return either to `after-gcd-1` or to `after-gcd-2`, depending on the value of the `continue` register. [Figure 5.9](#Figure-5_002e9) shows the relevant portion of the resulting controller sequence, which includes only a single copy of the `gcd` instructions. 225 | 226 | > **Figure 5.9:** $\downarrow$ Using a `continue` register to avoid the duplicate controller sequence in [Figure 5.8](#Figure-5_002e8). 227 | > > ``` {.scheme} 228 | > gcd 229 | > (test (op =) (reg b) (const 0)) 230 | > (branch (label gcd-done)) 231 | > (assign t (op rem) (reg a) (reg b)) 232 | > (assign a (reg b)) 233 | > (assign b (reg t)) 234 | > (goto (label gcd)) 235 | > gcd-done 236 | > (test (op =) (reg continue) (const 0)) 237 | > (branch (label after-gcd-1)) 238 | > (goto (label after-gcd-2)) 239 | > … 240 | > ;; Before branching to gcd from 241 | > ;; the first place where it is needed, 242 | > ;; we place 0 in the continue register 243 | > (assign continue (const 0)) 244 | > (goto (label gcd)) 245 | > after-gcd-1 246 | > … 247 | > ;; Before the second use of gcd, 248 | > ;; we place 1 in the continue register 249 | > (assign continue (const 1)) 250 | > (goto (label gcd)) 251 | > after-gcd-2 252 | > ``` 253 | 254 | This is a reasonable approach for handling small problems, but it would be awkward if there were many instances of GCD computations in the controller sequence. To decide where to continue executing after the `gcd` subroutine, we would need tests in the data paths and branch instructions in the controller for all the places that use `gcd`. A more powerful method for implementing subroutines is to have the `continue` register hold the label of the entry point in the controller sequence at which execution should continue when the subroutine is finished. Implementing this strategy requires a new kind of connection between the data paths and the controller of a register machine: There must be a way to assign to a register a label in the controller sequence in such a way that this value can be fetched from the register and used to continue execution at the designated entry point. 255 | 256 | To reflect this ability, we will extend the `assign` instruction of the register-machine language to allow a register to be assigned as value a label from the controller sequence (as a special kind of constant). We will also extend the `goto` instruction to allow execution to continue at the entry point described by the contents of a register rather than only at an entry point described by a constant label. Using these new constructs we can terminate the `gcd` subroutine with a branch to the location stored in the `continue` register. This leads to the controller sequence shown in [Figure 5.10](#Figure-5_002e10). 257 | 258 | > **Figure 5.10:** $\downarrow$ Assigning labels to the `continue` register simplifies and generalizes the strategy shown in [Figure 5.9](#Figure-5_002e9). 259 | > > ``` {.scheme} 260 | > gcd 261 | > (test (op =) (reg b) (const 0)) 262 | > (branch (label gcd-done)) 263 | > (assign t (op rem) (reg a) (reg b)) 264 | > (assign a (reg b)) 265 | > (assign b (reg t)) 266 | > (goto (label gcd)) 267 | > gcd-done 268 | > (goto (reg continue)) 269 | > … 270 | > ;; Before calling gcd, 271 | > ;; we assign to continue the label 272 | > ;; to which gcd should return. 273 | > (assign continue (label after-gcd-1)) 274 | > (goto (label gcd)) 275 | > after-gcd-1 276 | > … 277 | > ;; Here is the second call to gcd, 278 | > ;; with a different continuation. 279 | > (assign continue (label after-gcd-2)) 280 | > (goto (label gcd)) 281 | > after-gcd-2 282 | > ``` 283 | 284 | A machine with more than one subroutine could use multiple continuation registers (e.g., `gcd-continue`, `factorial-continue`) or we could have all subroutines share a single `continue` register. Sharing is more economical, but we must be careful if we have a subroutine (`sub1`) that calls another subroutine (`sub2`). Unless `sub1` saves the contents of `continue` in some other register before setting up `continue` for the call to `sub2`, `sub1` will not know where to go when it is finished. The mechanism developed in the next section to handle recursion also provides a better solution to this problem of nested subroutine calls. 285 | 286 | 287 | ## 5.1.4 Using a Stack to Implement Recursion 288 | 289 | With the ideas illustrated so far, we can implement any iterative process by specifying a register machine that has a register corresponding to each state variable of the process. The machine repeatedly executes a controller loop, changing the contents of the registers, until some termination condition is satisfied. At each point in the controller sequence, the state of the machine (representing the state of the iterative process) is completely determined by the contents of the registers (the values of the state variables). 290 | 291 | Implementing recursive processes, however, requires an additional mechanism. Consider the following recursive method for computing factorials, which we first examined in [1.2.1](1_002e2.xhtml#g_t1_002e2_002e1): 292 | 293 | ``` {.scheme} 294 | (define (factorial n) 295 | (if (= n 1) 296 | 1 297 | (* (factorial (- n 1)) n))) 298 | ``` 299 | 300 | As we see from the procedure, computing $n!$ requires computing $(n - 1)!$. Our GCD machine, modeled on the procedure 301 | 302 | ``` {.scheme} 303 | (define (gcd a b) 304 | (if (= b 0) 305 | a 306 | (gcd b (remainder a b)))) 307 | ``` 308 | 309 | similarly had to compute another GCD. But there is an important difference between the `gcd` procedure, which reduces the original computation to a new GCD computation, and `factorial`, which requires computing another factorial as a subproblem. In GCD, the answer to the new GCD computation is the answer to the original problem. To compute the next GCD, we simply place the new arguments in the input registers of the GCD machine and reuse the machine’s data paths by executing the same controller sequence. When the machine is finished solving the final GCD problem, it has completed the entire computation. 310 | 311 | In the case of factorial (or any recursive process) the answer to the new factorial subproblem is not the answer to the original problem. The value obtained for $(n - 1)!$ must be multiplied by $n$ to get the final answer. If we try to imitate the GCD design, and solve the factorial subproblem by decrementing the `n` register and rerunning the factorial machine, we will no longer have available the old value of `n` by which to multiply the result. We thus need a second factorial machine to work on the subproblem. This second factorial computation itself has a factorial subproblem, which requires a third factorial machine, and so on. Since each factorial machine contains another factorial machine within it, the total machine contains an infinite nest of similar machines and hence cannot be constructed from a fixed, finite number of parts. 312 | 313 | Nevertheless, we can implement the factorial process as a register machine if we can arrange to use the same components for each nested instance of the machine. Specifically, the machine that computes $n!$ should use the same components to work on the subproblem of computing $(n - 1)!$, on the subproblem for $(n - 2)!$, and so on. This is plausible because, although the factorial process dictates that an unbounded number of copies of the same machine are needed to perform a computation, only one of these copies needs to be active at any given time. When the machine encounters a recursive subproblem, it can suspend work on the main problem, reuse the same physical parts to work on the subproblem, then continue the suspended computation. 314 | 315 | In the subproblem, the contents of the registers will be different than they were in the main problem. (In this case the `n` register is decremented.) In order to be able to continue the suspended computation, the machine must save the contents of any registers that will be needed after the subproblem is solved so that these can be restored to continue the suspended computation. In the case of factorial, we will save the old value of `n`, to be restored when we are finished computing the factorial of the decremented `n` register.^[One might argue that we don’t need to save the old `n`; after we decrement it and solve the subproblem, we could simply increment it to recover the old value. Although this strategy works for factorial, it cannot work in general, since the old value of a register cannot always be computed from the new one.] 316 | 317 | Since there is no *a priori* limit on the depth of nested recursive calls, we may need to save an arbitrary number of register values. These values must be restored in the reverse of the order in which they were saved, since in a nest of recursions the last subproblem to be entered is the first to be finished. This dictates the use of a *stack*, or “last in, first out” data structure, to save register values. We can extend the register-machine language to include a stack by adding two kinds of instructions: Values are placed on the stack using a `save` instruction and restored from the stack using a `restore` instruction. After a sequence of values has been `save`d on the stack, a sequence of `restore`s will retrieve these values in reverse order.^[In [5.3](5_002e3.xhtml#g_t5_002e3) we will see how to implement a stack in terms of more primitive operations.] 318 | 319 | With the aid of the stack, we can reuse a single copy of the factorial machine’s data paths for each factorial subproblem. There is a similar design issue in reusing the controller sequence that operates the data paths. To reexecute the factorial computation, the controller cannot simply loop back to the beginning, as with an iterative process, because after solving the $(n - 1)!$ subproblem the machine must still multiply the result by $n$. The controller must suspend its computation of $n!$, solve the $(n - 1)!$ subproblem, then continue its computation of $n!$. This view of the factorial computation suggests the use of the subroutine mechanism described in [5.1.3](#g_t5_002e1_002e3), which has the controller use a `continue` register to transfer to the part of the sequence that solves a subproblem and then continue where it left off on the main problem. We can thus make a factorial subroutine that returns to the entry point stored in the `continue` register. Around each subroutine call, we save and restore `continue` just as we do the `n` register, since each “level” of the factorial computation will use the same `continue` register. That is, the factorial subroutine must put a new value in `continue` when it calls itself for a subproblem, but it will need the old value in order to return to the place that called it to solve a subproblem. 320 | 321 | [Figure 5.11](#Figure-5_002e11) shows the data paths and controller for a machine that implements the recursive `factorial` procedure. The machine has a stack and three registers, called `n`, `val`, and `continue`. To simplify the data-path diagram, we have not named the register-assignment buttons, only the stack-operation buttons (`sc` and `sn` to save registers, `rc` and `rn` to restore registers). To operate the machine, we put in register `n` the number whose factorial we wish to compute and start the machine. When the machine reaches `fact-done`, the computation is finished and the answer will be found in the `val` register. In the controller sequence, `n` and `continue` are saved before each recursive call and restored upon return from the call. Returning from a call is accomplished by branching to the location stored in `continue`. `Continue` is initialized when the machine starts so that the last return will go to `fact-done`. The `val` register, which holds the result of the factorial computation, is not saved before the recursive call, because the old contents of `val` is not useful after the subroutine returns. Only the new value, which is the value produced by the subcomputation, is needed. 322 | 323 | 324 | **Figure 5.11:** A recursive factorial machine. 325 | 326 | Although in principle the factorial computation requires an infinite machine, the machine in [Figure 5.11](#Figure-5_002e11) is actually finite except for the stack, which is potentially unbounded. Any particular physical implementation of a stack, however, will be of finite size, and this will limit the depth of recursive calls that can be handled by the machine. This implementation of factorial illustrates the general strategy for realizing recursive algorithms as ordinary register machines augmented by stacks. When a recursive subproblem is encountered, we save on the stack the registers whose current values will be required after the subproblem is solved, solve the recursive subproblem, then restore the saved registers and continue execution on the main problem. The `continue` register must always be saved. Whether there are other registers that need to be saved depends on the particular machine, since not all recursive computations need the original values of registers that are modified during solution of the subproblem (see [Exercise 5.4](#Exercise-5_002e4)). 327 | 328 | 329 | ### A double recursion 330 | 331 | Let us examine a more complex recursive process, the tree-recursive computation of the Fibonacci numbers, which we introduced in [1.2.2](1_002e2.xhtml#g_t1_002e2_002e2): 332 | 333 | ``` {.scheme} 334 | (define (fib n) 335 | (if (< n 2) 336 | n 337 | (+ (fib (- n 1)) (fib (- n 2))))) 338 | ``` 339 | 340 | Just as with factorial, we can implement the recursive Fibonacci computation as a register machine with registers `n`, `val`, and `continue`. The machine is more complex than the one for factorial, because there are two places in the controller sequence where we need to perform recursive calls—once to compute $\text{Fib}(n - 1)$ and once to compute $\text{Fib}(n - 2)$. To set up for each of these calls, we save the registers whose values will be needed later, set the `n` register to the number whose Fib we need to compute recursively ($n - 1$ or $n - 2$), and assign to `continue` the entry point in the main sequence to which to return (`afterfib-n-1` or `afterfib-n-2`, respectively). We then go to `fib-loop`. When we return from the recursive call, the answer is in `val`. [Figure 5.12](#Figure-5_002e12) shows the controller sequence for this machine. 341 | 342 | > **Figure 5.12:** $\downarrow$ Controller for a machine to compute Fibonacci numbers. 343 | > > ``` {.scheme} 344 | > (controller 345 | > (assign continue (label fib-done)) 346 | > fib-loop 347 | > (test (op <) (reg n) (const 2)) 348 | > (branch (label immediate-answer)) 349 | > ;; set up to compute Fib(n − 1) 350 | > (save continue) 351 | > (assign continue (label afterfib-n-1)) 352 | > (save n) ; save old value of n 353 | > (assign n 354 | > (op -) 355 | > (reg n) 356 | > (const 1)) ; clobber n to n-1 357 | > (goto 358 | > (label fib-loop)) ; perform recursive call 359 | > afterfib-n-1 ; upon return, val contains Fib(n − 1) 360 | > (restore n) 361 | > (restore continue) 362 | > ;; set up to compute Fib(n − 2) 363 | > (assign n (op -) (reg n) (const 2)) 364 | > (save continue) 365 | > (assign continue (label afterfib-n-2)) 366 | > (save val) ; save Fib(n − 1) 367 | > (goto (label fib-loop)) 368 | > afterfib-n-2 ; upon return, val contains Fib(n − 2) 369 | > (assign n 370 | > (reg val)) ; n now contains Fib(n − 2) 371 | > (restore val) ; val now contains Fib(n − 1) 372 | > (restore continue) 373 | > (assign val ; Fib(n − 1) + Fib(n − 2) 374 | > (op +) 375 | > (reg val) 376 | > (reg n)) 377 | > (goto ; return to caller, 378 | > (reg continue)) ; answer is in val 379 | > immediate-answer 380 | > (assign val 381 | > (reg n)) ; base case: Fib(n) = n 382 | > (goto (reg continue)) 383 | > fib-done) 384 | > ``` 385 | 386 | **Exercise 5.4:** Specify register machines that implement each of the following procedures. For each machine, write a controller instruction sequence and draw a diagram showing the data paths. 387 | 388 | 1. Recursive exponentiation: 389 | ``` {.scheme} 390 | (define (expt b n) 391 | (if (= n 0) 392 | 1 393 | (* b (expt b (- n 1))))) 394 | ``` 395 | 396 | 397 | 2. Iterative exponentiation: 398 | ``` {.scheme} 399 | (define (expt b n) 400 | (define (expt-iter counter product) 401 | (if (= counter 0) 402 | product 403 | (expt-iter (- counter 1) 404 | (* b product)))) 405 | (expt-iter n 1)) 406 | ``` 407 | 408 | 409 | **Exercise 5.5:** Hand-simulate the factorial and Fibonacci machines, using some nontrivial input (requiring execution of at least one recursive call). Show the contents of the stack at each significant point in the execution. 410 | 411 | **Exercise 5.6:** Ben Bitdiddle observes that the Fibonacci machine’s controller sequence has an extra `save` and an extra `restore`, which can be removed to make a faster machine. Where are these instructions? 412 | 413 | 414 | ## 5.1.5 Instruction Summary 415 | 416 | A controller instruction in our register-machine language has one of the following forms, where each $\langle\mspace{1mu} input_{i}\rangle$ is either `(reg ⟨register-name⟩)` or `(const ⟨constant-value⟩)`. These instructions were introduced in [5.1.1](#g_t5_002e1_002e1): 417 | 418 | ``` {.scheme} 419 | (assign ⟨register-name⟩ (reg ⟨register-name⟩)) 420 | (assign ⟨register-name⟩ 421 | (const ⟨constant-value⟩)) 422 | (assign ⟨register-name⟩ 423 | (op ⟨operation-name⟩) 424 | ⟨input₁⟩ … ⟨inputₙ⟩) 425 | (perform (op ⟨operation-name⟩) 426 | ⟨input₁⟩ 427 | … 428 | ⟨inputₙ⟩) 429 | (test (op ⟨operation-name⟩) 430 | ⟨input₁⟩ 431 | … 432 | ⟨inputₙ⟩) 433 | (branch (label ⟨label-name⟩)) 434 | (goto (label ⟨label-name⟩)) 435 | ``` 436 | 437 | The use of registers to hold labels was introduced in [5.1.3](#g_t5_002e1_002e3): 438 | 439 | ``` {.scheme} 440 | (assign ⟨register-name⟩ (label ⟨label-name⟩)) 441 | (goto (reg ⟨register-name⟩)) 442 | ``` 443 | 444 | Instructions to use the stack were introduced in [5.1.4](#g_t5_002e1_002e4): 445 | 446 | ``` {.scheme} 447 | (save ⟨register-name⟩) 448 | (restore ⟨register-name⟩) 449 | ``` 450 | 451 | The only kind of `⟨`constant-value`⟩` we have seen so far is a number, but later we will use strings, symbols, and lists. For example,\ 452 | `(const "abc")` is the string `"abc"`,\ 453 | `(const abc)` is the symbol `abc`,\ 454 | `(const (a b c))` is the list `(a b c)`,\ 455 | and `(const ())` is the empty list. 456 | -------------------------------------------------------------------------------- /capitulos/05-03-coletor-lixo.md: -------------------------------------------------------------------------------- 1 | # 5.3 Storage Allocation and Garbage Collection 2 | 3 | In section [5.4](5_002e4.xhtml#g_t5_002e4), we will show how to implement a Scheme evaluator as a register machine. In order to simplify the discussion, we will assume that our register machines can be equipped with a *list-structured memory*, in which the basic operations for manipulating list-structured data are primitive. Postulating the existence of such a memory is a useful abstraction when one is focusing on the mechanisms of control in a Scheme interpreter, but this does not reflect a realistic view of the actual primitive data operations of contemporary computers. To obtain a more complete picture of how a Lisp system operates, we must investigate how list structure can be represented in a way that is compatible with conventional computer memories. 4 | 5 | There are two considerations in implementing list structure. The first is purely an issue of representation: how to represent the “box-and-pointer” structure of Lisp pairs, using only the storage and addressing capabilities of typical computer memories. The second issue concerns the management of memory as a computation proceeds. The operation of a Lisp system depends crucially on the ability to continually create new data objects. These include objects that are explicitly created by the Lisp procedures being interpreted as well as structures created by the interpreter itself, such as environments and argument lists. Although the constant creation of new data objects would pose no problem on a computer with an infinite amount of rapidly addressable memory, computer memories are available only in finite sizes (more’s the pity). Lisp systems thus provide an *automatic storage allocation* facility to support the illusion of an infinite memory. When a data object is no longer needed, the memory allocated to it is automatically recycled and used to construct new data objects. There are various techniques for providing such automatic storage allocation. The method we shall discuss in this section is called *garbage collection*. 6 | 7 | 8 | ## 5.3.1 Memory as Vectors 9 | 10 | A conventional computer memory can be thought of as an array of cubbyholes, each of which can contain a piece of information. Each cubbyhole has a unique name, called its *address* or *location*. Typical memory systems provide two primitive operations: one that fetches the data stored in a specified location and one that assigns new data to a specified location. Memory addresses can be incremented to support sequential access to some set of the cubbyholes. More generally, many important data operations require that memory addresses be treated as data, which can be stored in memory locations and manipulated in machine registers. The representation of list structure is one application of such *address arithmetic*. 11 | 12 | To model computer memory, we use a new kind of data structure called a *vector*. Abstractly, a vector is a compound data object whose individual elements can be accessed by means of an integer index in an amount of time that is independent of the index.^[We could represent memory as lists of items. However, the access time would then not be independent of the index, since accessing the $n^{\text{th}}$ element of a list requires $n - 1$ `cdr` operations.] In order to describe memory operations, we use two primitive Scheme procedures for manipulating vectors: 13 | 14 | - `(vector-ref ⟨vector⟩ ⟨n⟩)` returns the $n^{\text{th}}$ element of the vector. 15 | - `(vector-set! ⟨vector⟩ ⟨n⟩ ⟨value⟩)` sets the $n^{\text{th}}$ element of the vector to the designated value. 16 | 17 | For example, if `v` is a vector, then `(vector-ref v 5)` gets the fifth entry in the vector `v` and `(vector-set! v 5 7)` changes the value of the fifth entry of the vector `v` to 7.^[For completeness, we should specify a `make-vector` operation that constructs vectors. However, in the present application we will use vectors only to model fixed divisions of the computer memory.] For computer memory, this access can be implemented through the use of address arithmetic to combine a *base address* that specifies the beginning location of a vector in memory with an *index* that specifies the offset of a particular element of the vector. 18 | 19 | 20 | ### Representing Lisp data 21 | 22 | We can use vectors to implement the basic pair structures required for a list-structured memory. Let us imagine that computer memory is divided into two vectors: `the-cars` and `the-cdrs`. We will represent list structure as follows: A pointer to a pair is an index into the two vectors. The `car` of the pair is the entry in `the-cars` with the designated index, and the `cdr` of the pair is the entry in `the-cdrs` with the designated index. We also need a representation for objects other than pairs (such as numbers and symbols) and a way to distinguish one kind of data from another. There are many methods of accomplishing this, but they all reduce to using *typed pointers*, that is, to extending the notion of “pointer” to include information on data type.^[This is precisely the same “tagged data” idea we introduced in [Chapter 2](Chapter-2.xhtml#Chapter-2) for dealing with generic operations. Here, however, the data types are included at the primitive machine level rather than constructed through the use of lists.] The data type enables the system to distinguish a pointer to a pair (which consists of the “pair” data type and an index into the memory vectors) from pointers to other kinds of data (which consist of some other data type and whatever is being used to represent data of that type). Two data objects are considered to be the same (`eq?`) if their pointers are identical.^[Type information may be encoded in a variety of ways, depending on the details of the machine on which the Lisp system is to be implemented. The execution efficiency of Lisp programs will be strongly dependent on how cleverly this choice is made, but it is difficult to formulate general design rules for good choices. The most straightforward way to implement typed pointers is to allocate a fixed set of bits in each pointer to be a *type field* that encodes the data type. Important questions to be addressed in designing such a representation include the following: How many type bits are required? How large must the vector indices be? How efficiently can the primitive machine instructions be used to manipulate the type fields of pointers? Machines that include special hardware for the efficient handling of type fields are said to have *tagged architectures*.] [Figure 5.14](#Figure-5_002e14) illustrates the use of this method to represent the list `((1 2) 3 4)`, whose box-and-pointer diagram is also shown. We use letter prefixes to denote the data-type information. Thus, a pointer to the pair with index 5 is denoted `p5`, the empty list is denoted by the pointer `e0`, and a pointer to the number 4 is denoted `n4`. In the box-and-pointer diagram, we have indicated at the lower left of each pair the vector index that specifies where the `car` and `cdr` of the pair are stored. The blank locations in `the-cars` and `the-cdrs` may contain parts of other list structures (not of interest here). 23 | 24 | ![](fig/chap5/Fig5.14b.std.svg 641.28x503.52) 25 | **Figure 5.14:** Box-and-pointer and memory-vector representations of the list `((1 2) 3 4)`. 26 | 27 | A pointer to a number, such as `n4`, might consist of a type indicating numeric data together with the actual representation of the number 4.^[This decision on the representation of numbers determines whether `eq?`, which tests equality of pointers, can be used to test for equality of numbers. If the pointer contains the number itself, then equal numbers will have the same pointer. But if the pointer contains the index of a location where the number is stored, equal numbers will be guaranteed to have equal pointers only if we are careful never to store the same number in more than one location.] To deal with numbers that are too large to be represented in the fixed amount of space allocated for a single pointer, we could use a distinct *bignum* data type, for which the pointer designates a list in which the parts of the number are stored.^[This is just like writing a number as a sequence of digits, except that each “digit” is a number between 0 and the largest number that can be stored in a single pointer.] 28 | 29 | A symbol might be represented as a typed pointer that designates a sequence of the characters that form the symbol’s printed representation. This sequence is constructed by the Lisp reader when the character string is initially encountered in input. Since we want two instances of a symbol to be recognized as the “same” symbol by `eq?` and we want `eq?` to be a simple test for equality of pointers, we must ensure that if the reader sees the same character string twice, it will use the same pointer (to the same sequence of characters) to represent both occurrences. To accomplish this, the reader maintains a table, traditionally called the *obarray*, of all the symbols it has ever encountered. When the reader encounters a character string and is about to construct a symbol, it checks the obarray to see if it has ever before seen the same character string. If it has not, it uses the characters to construct a new symbol (a typed pointer to a new character sequence) and enters this pointer in the obarray. If the reader has seen the string before, it returns the symbol pointer stored in the obarray. This process of replacing character strings by unique pointers is called *interning* symbols. 30 | 31 | 32 | ### Implementing the primitive list operations 33 | 34 | Given the above representation scheme, we can replace each “primitive” list operation of a register machine with one or more primitive vector operations. We will use two registers, `the-cars` and `the-cdrs`, to identify the memory vectors, and will assume that `vector-ref` and `vector-set!` are available as primitive operations. We also assume that numeric operations on pointers (such as incrementing a pointer, using a pair pointer to index a vector, or adding two numbers) use only the index portion of the typed pointer. 35 | 36 | For example, we can make a register machine support the instructions 37 | 38 | ``` {.scheme} 39 | (assign ⟨reg₁⟩ (op car) (reg ⟨reg₂⟩)) 40 | (assign ⟨reg₁⟩ (op cdr) (reg ⟨reg₂⟩)) 41 | ``` 42 | 43 | if we implement these, respectively, as 44 | 45 | ``` {.scheme} 46 | (assign ⟨reg₁⟩ 47 | (op vector-ref) 48 | (reg the-cars) 49 | (reg ⟨reg₂⟩)) 50 | (assign ⟨reg₁⟩ 51 | (op vector-ref) 52 | (reg the-cdrs) 53 | (reg ⟨reg₂⟩)) 54 | ``` 55 | 56 | The instructions 57 | 58 | ``` {.scheme} 59 | (perform (op set-car!) (reg ⟨reg₁⟩) (reg ⟨reg₂⟩)) 60 | (perform (op set-cdr!) (reg ⟨reg₁⟩) (reg ⟨reg₂⟩)) 61 | ``` 62 | 63 | are implemented as 64 | 65 | ``` {.scheme} 66 | (perform (op vector-set!) 67 | (reg the-cars) 68 | (reg ⟨reg₁⟩) 69 | (reg ⟨reg₂⟩)) 70 | (perform (op vector-set!) 71 | (reg the-cdrs) 72 | (reg ⟨reg₁⟩) 73 | (reg ⟨reg₂⟩)) 74 | ``` 75 | 76 | `Cons` is performed by allocating an unused index and storing the arguments to `cons` in `the-cars` and `the-cdrs` at that indexed vector position. We presume that there is a special register, `free`, that always holds a pair pointer containing the next available index, and that we can increment the index part of that pointer to find the next free location.^[There are other ways of finding free storage. For example, we could link together all the unused pairs into a *free list*. Our free locations are consecutive (and hence can be accessed by incrementing a pointer) because we are using a compacting garbage collector, as we will see in [5.3.2](#g_t5_002e3_002e2).] For example, the instruction 77 | 78 | ``` {.scheme} 79 | (assign ⟨reg₁⟩ 80 | (op cons) 81 | (reg ⟨reg₂⟩) 82 | (reg ⟨reg₃⟩)) 83 | ``` 84 | 85 | is implemented as the following sequence of vector operations:^[This is essentially the implementation of `cons` in terms of `set-car!` and `set-cdr!`, as described in [3.3.1](3_002e3.xhtml#g_t3_002e3_002e1). The operation `get-new-pair` used in that implementation is realized here by the `free` pointer.] 86 | 87 | ``` {.scheme} 88 | (perform (op vector-set!) 89 | (reg the-cars) 90 | (reg free) 91 | (reg ⟨reg₂⟩)) 92 | (perform (op vector-set!) 93 | (reg the-cdrs) 94 | (reg free) 95 | (reg ⟨reg₃⟩)) 96 | (assign ⟨reg₁⟩ (reg free)) 97 | (assign free (op +) (reg free) (const 1)) 98 | ``` 99 | 100 | The `eq?` operation 101 | 102 | ``` {.scheme} 103 | (op eq?) (reg ⟨reg₁⟩) (reg ⟨reg₂⟩) 104 | ``` 105 | 106 | simply tests the equality of all fields in the registers, and predicates such as `pair?`, `null?`, `symbol?`, and `number?` need only check the type field. 107 | 108 | 109 | ### Implementing stacks 110 | 111 | Although our register machines use stacks, we need do nothing special here, since stacks can be modeled in terms of lists. The stack can be a list of the saved values, pointed to by a special register `the-stack`. Thus, `(save ⟨reg⟩)` can be implemented as 112 | 113 | ``` {.scheme} 114 | (assign the-stack 115 | (op cons) 116 | (reg ⟨reg⟩) 117 | (reg the-stack)) 118 | ``` 119 | 120 | Similarly, `(restore ⟨reg⟩)` can be implemented as 121 | 122 | ``` {.scheme} 123 | (assign ⟨reg⟩ (op car) (reg the-stack)) 124 | (assign the-stack (op cdr) (reg the-stack)) 125 | ``` 126 | 127 | and `(perform (op initialize-stack))` can be implemented as 128 | 129 | ``` {.scheme} 130 | (assign the-stack (const ())) 131 | ``` 132 | 133 | These operations can be further expanded in terms of the vector operations given above. In conventional computer architectures, however, it is usually advantageous to allocate the stack as a separate vector. Then pushing and popping the stack can be accomplished by incrementing or decrementing an index into that vector. 134 | 135 | **Exercise 5.20:** Draw the box-and-pointer representation and the memory-vector representation (as in [Figure 5.14](#Figure-5_002e14)) of the list structure produced by 136 | 137 | 138 | ``` {.scheme} 139 | (define x (cons 1 2)) 140 | (define y (list x x)) 141 | ``` 142 | 143 | 144 | with the `free` pointer initially `p1`. What is the final value of `free`? What pointers represent the values of `x` and `y`? 145 | 146 | **Exercise 5.21:** Implement register machines for the following procedures. Assume that the list-structure memory operations are available as machine primitives. 147 | 148 | 1. Recursive `count-leaves`: 149 | ``` {.scheme} 150 | (define (count-leaves tree) 151 | (cond ((null? tree) 0) 152 | ((not (pair? tree)) 1) 153 | (else 154 | (+ (count-leaves (car tree)) 155 | (count-leaves (cdr tree)))))) 156 | ``` 157 | 158 | 159 | 2. Recursive `count-leaves` with explicit counter: 160 | ``` {.scheme} 161 | (define (count-leaves tree) 162 | (define (count-iter tree n) 163 | (cond ((null? tree) n) 164 | ((not (pair? tree)) (+ n 1)) 165 | (else 166 | (count-iter 167 | (cdr tree) 168 | (count-iter (car tree) 169 | n))))) 170 | (count-iter tree 0)) 171 | ``` 172 | 173 | 174 | **Exercise 5.22:** [Exercise 3.12](3_002e3.xhtml#Exercise-3_002e12) of [3.3.1](3_002e3.xhtml#g_t3_002e3_002e1) presented an `append` procedure that appends two lists to form a new list and an `append!` procedure that splices two lists together. Design a register machine to implement each of these procedures. Assume that the list-structure memory operations are available as primitive operations. 175 | 176 | 177 | ## 5.3.2 Maintaining the Illusion of Infinite Memory 178 | 179 | The representation method outlined in [5.3.1](#g_t5_002e3_002e1) solves the problem of implementing list structure, provided that we have an infinite amount of memory. With a real computer we will eventually run out of free space in which to construct new pairs.^[This may not be true eventually, because memories may get large enough so that it would be impossible to run out of free memory in the lifetime of the computer. For example, there are about $3 \cdot 10^{13}$ microseconds in a year, so if we were to `cons` once per microsecond we would need about $10^{15}$ cells of memory to build a machine that could operate for 30 years without running out of memory. That much memory seems absurdly large by today’s standards, but it is not physically impossible. On the other hand, processors are getting faster and a future computer may have large numbers of processors operating in parallel on a single memory, so it may be possible to use up memory much faster than we have postulated.] However, most of the pairs generated in a typical computation are used only to hold intermediate results. After these results are accessed, the pairs are no longer needed—they are *garbage*. For instance, the computation 180 | 181 | ``` {.scheme} 182 | (accumulate 183 | + 184 | 0 185 | (filter odd? (enumerate-interval 0 n))) 186 | ``` 187 | 188 | constructs two lists: the enumeration and the result of filtering the enumeration. When the accumulation is complete, these lists are no longer needed, and the allocated memory can be reclaimed. If we can arrange to collect all the garbage periodically, and if this turns out to recycle memory at about the same rate at which we construct new pairs, we will have preserved the illusion that there is an infinite amount of memory. 189 | 190 | In order to recycle pairs, we must have a way to determine which allocated pairs are not needed (in the sense that their contents can no longer influence the future of the computation). The method we shall examine for accomplishing this is known as *garbage collection*. Garbage collection is based on the observation that, at any moment in a Lisp interpretation, the only objects that can affect the future of the computation are those that can be reached by some succession of `car` and `cdr` operations starting from the pointers that are currently in the machine registers.^[We assume here that the stack is represented as a list as described in [5.3.1](#g_t5_002e3_002e1), so that items on the stack are accessible via the pointer in the stack register.] Any memory cell that is not so accessible may be recycled. 191 | 192 | There are many ways to perform garbage collection. The method we shall examine here is called *stop-and-copy*. The basic idea is to divide memory into two halves: “working memory” and “free memory.” When `cons` constructs pairs, it allocates these in working memory. When working memory is full, we perform garbage collection by locating all the useful pairs in working memory and copying these into consecutive locations in free memory. (The useful pairs are located by tracing all the `car` and `cdr` pointers, starting with the machine registers.) Since we do not copy the garbage, there will presumably be additional free memory that we can use to allocate new pairs. In addition, nothing in the working memory is needed, since all the useful pairs in it have been copied. Thus, if we interchange the roles of working memory and free memory, we can continue processing; new pairs will be allocated in the new working memory (which was the old free memory). When this is full, we can copy the useful pairs into the new free memory (which was the old working memory).^[This idea was invented and first implemented by Minsky, as part of the implementation of Lisp for the PDP-1 at the MIT Research Laboratory of Electronics. It was further developed by [Fenichel and Yochelson (1969)](References.xhtml#Fenichel-and-Yochelson-_00281969_0029) for use in the Lisp implementation for the Multics time-sharing system. Later, [Baker (1978)](References.xhtml#Baker-_00281978_0029) developed a “real-time” version of the method, which does not require the computation to stop during garbage collection. Baker’s idea was extended by Hewitt, Lieberman, and Moon (see [Lieberman and Hewitt 1983](References.xhtml#Lieberman-and-Hewitt-1983)) to take advantage of the fact that some structure is more volatile and other structure is more permanent.] 193 | 194 | 195 | ### Implementation of a stop-and-copy garbage collector 196 | 197 | We now use our register-machine language to describe the stop-and-copy algorithm in more detail. We will assume that there is a register called `root` that contains a pointer to a structure that eventually points at all accessible data. This can be arranged by storing the contents of all the machine registers in a pre-allocated list pointed at by `root` just before starting garbage collection.^[This list of registers does not include the registers used by the storage-allocation system—`root`, `the-cars`, `the-cdrs`, and the other registers that will be introduced in this section.] We also assume that, in addition to the current working memory, there is free memory available into which we can copy the useful data. The current working memory consists of vectors whose base addresses are in registers called `the-cars` and `the-cdrs`, and the free memory is in registers called `new-cars` and `new-cdrs`. 198 | 199 | Garbage collection is triggered when we exhaust the free cells in the current working memory, that is, when a `cons` operation attempts to increment the `free` pointer beyond the end of the memory vector. When the garbage-collection process is complete, the `root` pointer will point into the new memory, all objects accessible from the `root` will have been moved to the new memory, and the `free` pointer will indicate the next place in the new memory where a new pair can be allocated. In addition, the roles of working memory and new memory will have been interchanged—new pairs will be constructed in the new memory, beginning at the place indicated by `free`, and the (previous) working memory will be available as the new memory for the next garbage collection. [Figure 5.15](#Figure-5_002e15) shows the arrangement of memory just before and just after garbage collection. 200 | 201 | ![](fig/chap5/Fig5.15c.std.svg 691.08x533.64) 202 | **Figure 5.15:** Reconfiguration of memory by the garbage-collection process. 203 | 204 | The state of the garbage-collection process is controlled by maintaining two pointers: `free` and `scan`. These are initialized to point to the beginning of the new memory. The algorithm begins by relocating the pair pointed at by `root` to the beginning of the new memory. The pair is copied, the `root` pointer is adjusted to point to the new location, and the `free` pointer is incremented. In addition, the old location of the pair is marked to show that its contents have been moved. This marking is done as follows: In the `car` position, we place a special tag that signals that this is an already-moved object. (Such an object is traditionally called a *broken heart*.)^[The term *broken heart* was coined by David Cressey, who wrote a garbage collector for MDL, a dialect of Lisp developed at MIT during the early 1970s.] In the `cdr` position we place a *forwarding address* that points at the location to which the object has been moved. 205 | 206 | After relocating the root, the garbage collector enters its basic cycle. At each step in the algorithm, the `scan` pointer (initially pointing at the relocated root) points at a pair that has been moved to the new memory but whose `car` and `cdr` pointers still refer to objects in the old memory. These objects are each relocated, and the `scan` pointer is incremented. To relocate an object (for example, the object indicated by the `car` pointer of the pair we are scanning) we check to see if the object has already been moved (as indicated by the presence of a broken-heart tag in the `car` position of the object). If the object has not already been moved, we copy it to the place indicated by `free`, update `free`, set up a broken heart at the object’s old location, and update the pointer to the object (in this example, the `car` pointer of the pair we are scanning) to point to the new location. If the object has already been moved, its forwarding address (found in the `cdr` position of the broken heart) is substituted for the pointer in the pair being scanned. Eventually, all accessible objects will have been moved and scanned, at which point the `scan` pointer will overtake the `free` pointer and the process will terminate. 207 | 208 | We can specify the stop-and-copy algorithm as a sequence of instructions for a register machine. The basic step of relocating an object is accomplished by a subroutine called `relocate-old-result-in-new`. This subroutine gets its argument, a pointer to the object to be relocated, from a register named `old`. It relocates the designated object (incrementing `free` in the process), puts a pointer to the relocated object into a register called `new`, and returns by branching to the entry point stored in the register `relocate-continue`. To begin garbage collection, we invoke this subroutine to relocate the `root` pointer, after initializing `free` and `scan`. When the relocation of `root` has been accomplished, we install the new pointer as the new `root` and enter the main loop of the garbage collector. 209 | 210 | ``` {.scheme} 211 | begin-garbage-collection 212 | (assign free (const 0)) 213 | (assign scan (const 0)) 214 | (assign old (reg root)) 215 | (assign relocate-continue 216 | (label reassign-root)) 217 | (goto (label relocate-old-result-in-new)) 218 | reassign-root 219 | (assign root (reg new)) 220 | (goto (label gc-loop)) 221 | ``` 222 | 223 | In the main loop of the garbage collector we must determine whether there are any more objects to be scanned. We do this by testing whether the `scan` pointer is coincident with the `free` pointer. If the pointers are equal, then all accessible objects have been relocated, and we branch to `gc-flip`, which cleans things up so that we can continue the interrupted computation. If there are still pairs to be scanned, we call the relocate subroutine to relocate the `car` of the next pair (by placing the `car` pointer in `old`). The `relocate-continue` register is set up so that the subroutine will return to update the `car` pointer. 224 | 225 | ``` {.scheme} 226 | gc-loop 227 | (test (op =) (reg scan) (reg free)) 228 | (branch (label gc-flip)) 229 | (assign old 230 | (op vector-ref) 231 | (reg new-cars) 232 | (reg scan)) 233 | (assign relocate-continue 234 | (label update-car)) 235 | (goto (label relocate-old-result-in-new)) 236 | ``` 237 | 238 | At `update-car`, we modify the `car` pointer of the pair being scanned, then proceed to relocate the `cdr` of the pair. We return to `update-cdr` when that relocation has been accomplished. After relocating and updating the `cdr`, we are finished scanning that pair, so we continue with the main loop. 239 | 240 | ``` {.scheme} 241 | update-car 242 | (perform (op vector-set!) 243 | (reg new-cars) 244 | (reg scan) 245 | (reg new)) 246 | (assign old 247 | (op vector-ref) 248 | (reg new-cdrs) 249 | (reg scan)) 250 | (assign relocate-continue 251 | (label update-cdr)) 252 | (goto (label relocate-old-result-in-new)) 253 | update-cdr 254 | (perform (op vector-set!) 255 | (reg new-cdrs) 256 | (reg scan) 257 | (reg new)) 258 | (assign scan (op +) (reg scan) (const 1)) 259 | (goto (label gc-loop)) 260 | ``` 261 | 262 | The subroutine `relocate-old-result-in-new` relocates objects as follows: If the object to be relocated (pointed at by `old`) is not a pair, then we return the same pointer to the object unchanged (in `new`). (For example, we may be scanning a pair whose `car` is the number 4. If we represent the `car` by `n4`, as described in [5.3.1](#g_t5_002e3_002e1), then we want the “relocated” `car` pointer to still be `n4`.) Otherwise, we must perform the relocation. If the `car` position of the pair to be relocated contains a broken-heart tag, then the pair has in fact already been moved, so we retrieve the forwarding address (from the `cdr` position of the broken heart) and return this in `new`. If the pointer in `old` points at a yet-unmoved pair, then we move the pair to the first free cell in new memory (pointed at by `free`) and set up the broken heart by storing a broken-heart tag and forwarding address at the old location. `Relocate-old-result-in-new` uses a register `oldcr` to hold the `car` or the `cdr` of the object pointed at by `old`.^[The garbage collector uses the low-level predicate `pointer-to-pair?` instead of the list-structure `pair?` operation because in a real system there might be various things that are treated as pairs for garbage-collection purposes. For example, in a Scheme system that conforms to the IEEE standard a procedure object may be implemented as a special kind of “pair” that doesn’t satisfy the `pair?` predicate. For simulation purposes, `pointer-to-pair?` can be implemented as `pair?`.] 263 | 264 | ``` {.scheme} 265 | relocate-old-result-in-new 266 | (test (op pointer-to-pair?) (reg old)) 267 | (branch (label pair)) 268 | (assign new (reg old)) 269 | (goto (reg relocate-continue)) 270 | pair 271 | (assign oldcr 272 | (op vector-ref) 273 | (reg the-cars) 274 | (reg old)) 275 | (test (op broken-heart?) (reg oldcr)) 276 | (branch (label already-moved)) 277 | (assign new (reg free)) ; new location for pair 278 | ;; Update free pointer. 279 | (assign free (op +) (reg free) (const 1)) 280 | ;; Copy the car and cdr to new memory. 281 | (perform (op vector-set!) 282 | (reg new-cars) 283 | (reg new) 284 | (reg oldcr)) 285 | (assign oldcr 286 | (op vector-ref) 287 | (reg the-cdrs) 288 | (reg old)) 289 | (perform (op vector-set!) 290 | (reg new-cdrs) 291 | (reg new) 292 | (reg oldcr)) 293 | ;; Construct the broken heart. 294 | (perform (op vector-set!) 295 | (reg the-cars) 296 | (reg old) 297 | (const broken-heart)) 298 | (perform (op vector-set!) 299 | (reg the-cdrs) 300 | (reg old) 301 | (reg new)) 302 | (goto (reg relocate-continue)) 303 | already-moved 304 | (assign new 305 | (op vector-ref) 306 | (reg the-cdrs) 307 | (reg old)) 308 | (goto (reg relocate-continue)) 309 | ``` 310 | 311 | At the very end of the garbage-collection process, we interchange the role of old and new memories by interchanging pointers: interchanging `the-cars` with `new-cars`, and `the-cdrs` with `new-cdrs`. We will then be ready to perform another garbage collection the next time memory runs out. 312 | 313 | ``` {.scheme} 314 | gc-flip 315 | (assign temp (reg the-cdrs)) 316 | (assign the-cdrs (reg new-cdrs)) 317 | (assign new-cdrs (reg temp)) 318 | (assign temp (reg the-cars)) 319 | (assign the-cars (reg new-cars)) 320 | (assign new-cars (reg temp)) 321 | ``` 322 | --------------------------------------------------------------------------------