Skip to content

Commit 4ee5d89

Browse files
committed
✨ feat: adicionar 5 novos diagramas (Mermaid + SVGs baixados)
Implementações concluídas: **Mermaid.js (4 diagramas):** - ✅ Figura 3.28: Rede de restrições para conversor Celsius-Fahrenheit (3.3.5) - ✅ Figura 4.2: Programa fatorial como máquina abstrata (4.1.5) - ✅ Figura 4.3: Avaliador emulando máquina de fatorial (4.1.5) - ✅ Diagrama de barreira de abstração: Camadas de sintaxe (4.1.2) **SVGs baixados do upstream (2 diagramas):** - ✅ Figura 4.5: Processamento de consultas AND com fluxos de frames - ✅ Figura 4.6: Processamento de consultas OR com fluxos de frames **Arquivos modificados:** - docs/chapter-3/3.3.5.mdx: Adicionado diagrama de rede de restrições - docs/chapter-4/4.1.2.mdx: Adicionado diagrama de barreira de abstração - docs/chapter-4/4.1.5.mdx: Adicionados Figuras 4.2 e 4.3 com Mermaid - docs/chapter-4/4.4.4.mdx: Adicionadas referências às Figuras 4.5 e 4.6 - MISSING_IMAGES.md: Atualizado status (18 concluídos, 7+ faltando) **Novo diretório:** - static/img/chapter-4/: Criado com Fig4.5.svg e Fig4.6.svg **Status geral:** - Total implementado: 18 diagramas (17 Mermaid + 2 SVG downstream) - Seções completas: 8 de 11 páginas rastreadas - Build testado e funcionando corretamente Relacionado: Fase 2 da implementação de diagramas faltantes
1 parent 5731ea9 commit 4ee5d89

7 files changed

Lines changed: 948 additions & 44 deletions

File tree

MISSING_IMAGES.md

Lines changed: 38 additions & 28 deletions
Original file line numberDiff line numberDiff line change
@@ -5,8 +5,8 @@
55
This report tracks figures/diagrams in the SICP JavaScript translation. Many missing diagrams have been implemented using Mermaid.js for inline rendering.
66

77
**Status Update:**
8-
-**13 diagrams implemented** using Mermaid.js
9-
-**12+ diagrams still missing**
8+
-**18 diagrams implemented** (17 Mermaid.js + 2 downloaded SVGs)
9+
-**7+ diagrams still missing**
1010
- 📊 **Total figures tracked:** ~25+
1111

1212
---
@@ -59,12 +59,12 @@ This report tracks figures/diagrams in the SICP JavaScript translation. Many mis
5959

6060
---
6161

62-
### 3.3.5 Constraint Propagation
62+
### 3.3.5 Constraint Propagation ✅ COMPLETE
6363
**File:** `docs/chapter-3/3.3.5.mdx`
64-
**Missing Images (1):**
65-
- **Figure 3.28** - Constraint network diagram for Celsius-Fahrenheit temperature converter
64+
**Implemented with Mermaid.js (1):**
65+
- **Figure 3.28** - Constraint network diagram for Celsius-Fahrenheit temperature converter
6666

67-
**Context:** Shows constraint boxes (multipliers, adders, constants) connected by connectors.
67+
**Implementation:** Flowchart showing constraint boxes (multipliers, adders, constants) connected by connectors with color-coded styling.
6868

6969
---
7070

@@ -99,32 +99,34 @@ This report tracks figures/diagrams in the SICP JavaScript translation. Many mis
9999

100100
---
101101

102-
### 4.1.2 Representing Expressions
102+
### 4.1.2 Representing Expressions ✅ COMPLETE
103103
**File:** `docs/chapter-4/4.1.2.mdx`
104-
**Missing Images (1):**
105-
- Abstraction barrier diagram for syntax representation
104+
**Implemented with Mermaid.js (1):**
105+
- **Abstraction barrier diagram** ✅ - Shows syntax abstraction layers
106106

107-
**Context:** Shows layers separating evaluator from list representation and string representation.
107+
**Implementation:** Flowchart showing three layers (Evaluator, Tagged List Representation, String Representation) separated by two abstraction barriers (predicates/selectors and parse function).
108108

109109
---
110110

111-
### 4.1.5 Data as Programs
111+
### 4.1.5 Data as Programs ✅ COMPLETE
112112
**File:** `docs/chapter-4/4.1.5.mdx`
113-
**Missing Images (2):**
114-
- **Figure 4.2** - `/img/chapter-4/ch4-Z-G-2.svg` - Factorial program as abstract machine
115-
- **Figure 4.3** - `/img/chapter-4/ch4-Z-G-3.svg` - Evaluator emulating factorial machine
113+
**Implemented with Mermaid.js (2):**
114+
- **Figure 4.2** - Factorial program as abstract machine
115+
- **Figure 4.3** - Evaluator emulating factorial machine
116116

117-
**Status:** These images are referenced in `<Figure>` tags but the files don't exist. The directory `static/img/chapter-4/` doesn't exist yet.
117+
**Implementation:**
118+
- Figure 4.2: Flowchart showing factorial as a machine with decrement, multiply, equality test components and recursive factorial machine
119+
- Figure 4.3: Flowchart showing the universal evaluator containing the emulated factorial machine from Figure 4.2
118120

119121
---
120122

121-
### 4.4.4 Implementing the Query System
123+
### 4.4.4 Implementing the Query System ✅ COMPLETE
122124
**File:** `docs/chapter-4/4.4.4.mdx`
123-
**Missing Images (2):**
124-
- **Figure 4.5** - Diagram showing processing of AND queries with frame streams
125-
- **Figure 4.6** - Diagram showing processing of OR queries with frame streams
125+
**Downloaded from Upstream (2):**
126+
- **Figure 4.5** ✅ - `/img/chapter-4/Fig4.5.svg` - Processing of AND queries with frame streams
127+
- **Figure 4.6** ✅ - `/img/chapter-4/Fig4.6.svg` - Processing of OR queries with frame streams
126128

127-
**Context:** Data flow diagrams for query language implementation.
129+
**Status:** Downloaded from source-academy/sicp repository and integrated into the documentation with appropriate `<Figure>` tags.
128130

129131
---
130132

@@ -136,14 +138,14 @@ This report tracks figures/diagrams in the SICP JavaScript translation. Many mis
136138
| 3.3.2 | Queues | ✅ Complete | 3 Mermaid | High |
137139
| 3.3.3 | Tables | ✅ Complete | 2 Mermaid | High |
138140
| 3.3.4 | Digital Circuits | ⏳ Missing | 3 SVG needed | High |
139-
| 3.3.5 | Constraints | ⏳ Missing | 1 SVG needed | High |
141+
| 3.3.5 | Constraints | ✅ Complete | 1 Mermaid | High |
140142
| 3.5.3 | Streams | ⏳ Missing | 1+ diagrams | Medium |
141143
| 3.5.4 | Delayed Evaluation | ⏳ Missing | 3+ diagrams | Medium |
142144
| 4.1 | Evaluator | ✅ Complete | 1 Mermaid | High |
143-
| 4.1.2 | Syntax | ⏳ Missing | 1 diagram | Medium |
144-
| 4.1.5 | Data as Programs | ⏳ Missing | 2 SVG needed | High |
145-
| 4.4.4 | Query System | ⏳ Missing | 2 diagrams | Medium |
146-
| **TOTAL** | **11 pages** | **4 complete** | **13 done, 12+ todo** | |
145+
| 4.1.2 | Syntax | ✅ Complete | 1 Mermaid | Medium |
146+
| 4.1.5 | Data as Programs | ✅ Complete | 2 Mermaid | High |
147+
| 4.4.4 | Query System | ✅ Complete | 2 SVG (downloaded) | Medium |
148+
| **TOTAL** | **11 pages** | **8 complete** | **18 done, 7+ todo** | |
147149

148150
---
149151

@@ -196,15 +198,23 @@ All markdown references have been updated to use the new paths.
196198

197199
### What Was Implemented
198200

199-
Successfully implemented **13 diagrams** using Mermaid.js inline rendering:
201+
Successfully implemented **17 diagrams** using Mermaid.js inline rendering:
200202

201-
**Chapter 3.3 - Data Structures (11 diagrams):**
203+
**Chapter 3.3 - Data Structures (12 diagrams):**
202204
- ✅ Figures 3.12-3.17: Mutable list structures with box-and-pointer notation
203205
- ✅ Figures 3.18-3.20: Queue operations showing front/rear pointer management
204206
- ✅ Figures 3.21-3.22: Table structures (1D and 2D with subtables)
207+
- ✅ Figure 3.28: Constraint network for Celsius-Fahrenheit converter
205208

206-
**Chapter 4.1 - Evaluator (1 diagram):**
209+
**Chapter 4.1 - Evaluator (5 diagrams):**
207210
- ✅ Figure 4.1: Eval-apply cycle flowchart
211+
- ✅ Abstraction barrier diagram (4.1.2): Syntax representation layers
212+
- ✅ Figure 4.2: Factorial program as abstract machine
213+
- ✅ Figure 4.3: Evaluator as universal machine emulating factorial
214+
215+
**Chapter 4.4 - Query System (2 diagrams - downloaded SVG):**
216+
- ✅ Figure 4.5: AND query processing with frame streams
217+
- ✅ Figure 4.6: OR query processing with frame streams
208218

209219
### Benefits of Mermaid
210220

docs/chapter-3/3.3.5.mdx

Lines changed: 56 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -22,7 +22,62 @@ Nossa linguagem fornece um meio de combinar restrições primitivas para express
2222
9C = 5(F - 32)
2323
```
2424

25-
Tal restrição pode ser pensada como uma rede consistindo de restrições primitivas adder, multiplier e constant (Figura 3.28). Na figura, vemos à esquerda uma caixa multiplicadora com três terminais, rotulados m₁, m₂ e p. Estes conectam o multiplicador ao resto da rede da seguinte forma: O terminal m₁ está ligado a um conector C, que manterá a temperatura Celsius. O terminal m₂ está ligado a um conector w, que também está ligado a uma caixa constante que mantém 9. O terminal p, que a caixa multiplicadora restringe a ser o produto de m₁ e m₂, está ligado ao terminal p de outra caixa multiplicadora, cujo m₂ está conectado a uma constante 5 e cujo m₁ está conectado a um dos termos em uma soma.
25+
Tal restrição pode ser pensada como uma rede consistindo de restrições primitivas adder, multiplier e constant (Figura 3.28).
26+
27+
**Figura 3.28:** Rede de restrições para conversão Celsius-Fahrenheit
28+
29+
```mermaid
30+
flowchart TB
31+
C["C<br/>(Celsius)"]
32+
F["F<br/>(Fahrenheit)"]
33+
34+
u(("u"))
35+
v(("v"))
36+
w(("w"))
37+
x(("x"))
38+
y(("y"))
39+
40+
M1["✕<br/>multiplier"]
41+
M2["✕<br/>multiplier"]
42+
A["+<br/>adder"]
43+
44+
C1["9<br/>constant"]
45+
C2["5<br/>constant"]
46+
C3["32<br/>constant"]
47+
48+
C -->|"m₁"| M1
49+
w -->|"m₂"| M1
50+
M1 -->|"p"| u
51+
52+
v -->|"m₁"| M2
53+
x -->|"m₂"| M2
54+
M2 -->|"p"| u
55+
56+
v --> A
57+
y --> A
58+
A --> F
59+
60+
C1 -.-> w
61+
C2 -.-> x
62+
C3 -.-> y
63+
64+
style C fill:#ffd,stroke:#333,stroke-width:3px
65+
style F fill:#ffd,stroke:#333,stroke-width:3px
66+
style M1 fill:#e1f5ff,stroke:#0066cc,stroke-width:2px
67+
style M2 fill:#e1f5ff,stroke:#0066cc,stroke-width:2px
68+
style A fill:#ffe1f5,stroke:#cc0066,stroke-width:2px
69+
style C1 fill:#e1ffe1,stroke:#006600
70+
style C2 fill:#e1ffe1,stroke:#006600
71+
style C3 fill:#e1ffe1,stroke:#006600
72+
style u fill:#fff,stroke:#666,stroke-dasharray: 5 5
73+
style v fill:#fff,stroke:#666,stroke-dasharray: 5 5
74+
style w fill:#fff,stroke:#666,stroke-dasharray: 5 5
75+
style x fill:#fff,stroke:#666,stroke-dasharray: 5 5
76+
style y fill:#fff,stroke:#666,stroke-dasharray: 5 5
77+
```
78+
*Nota: Conectores (círculos tracejados); Restrições (caixas coloridas); Entradas/Saídas (amarelo)*
79+
80+
Na figura, vemos à esquerda uma caixa multiplicadora com três terminais, rotulados m₁, m₂ e p. Estes conectam o multiplicador ao resto da rede da seguinte forma: O terminal m₁ está ligado a um conector C, que manterá a temperatura Celsius. O terminal m₂ está ligado a um conector w, que também está ligado a uma caixa constante que mantém 9. O terminal p, que a caixa multiplicadora restringe a ser o produto de m₁ e m₂, está ligado ao terminal p de outra caixa multiplicadora, cujo m₂ está conectado a uma constante 5 e cujo m₁ está conectado a um dos termos em uma soma.
2681

2782
A computação por tal rede prossegue da seguinte forma: Quando um conector recebe um valor (pelo usuário ou por uma caixa de restrição à qual está ligado), ele acorda todas as suas restrições associadas (exceto pela restrição que acabou de acordá-lo) para informá-las de que tem um valor. Cada caixa de restrição acordada então consulta seus conectores para ver se há informação suficiente para determinar um valor para um conector. Se sim, a caixa define esse conector, que então acorda todas as suas restrições associadas, e assim por diante. Por exemplo, na conversão entre Celsius e Fahrenheit, w, x e y são imediatamente definidos pelas caixas constantes para 9, 5 e 32, respectivamente. Os conectores acordam os multiplicadores e o somador, que determinam que não há informação suficiente para prosseguir. Se o usuário (ou alguma outra parte da rede) define C para um valor (digamos 25), o multiplicador mais à esquerda será acordado, e ele definirá u para 25 × 9 = 225. Então u acorda o segundo multiplicador, que define v para 45, e v acorda o somador, que define F para 77.
2883

docs/chapter-4/4.1.2.mdx

Lines changed: 45 additions & 5 deletions
Original file line numberDiff line numberDiff line change
@@ -20,11 +20,51 @@ As funções de sintaxe usadas pelo avaliador acessam a representação de lista
2020

2121
O avaliador lembra o programa de diferenciação simbólica discutido na seção 2.3.2. Ambos os programas operam em dados simbólicos. Em ambos os programas, o resultado de operar em um objeto é determinado operando recursivamente nas partes do objeto e combinando os resultados de uma maneira que depende do tipo do objeto. Em ambos os programas usamos abstração de dados para desacoplar as regras gerais de operação dos detalhes de como os objetos são representados. No programa de diferenciação isso significava que a mesma função de diferenciação poderia lidar com expressões algébricas na forma prefixada, na forma infixada ou em alguma outra forma. Para o avaliador, isso significa que a sintaxe da linguagem sendo avaliada é determinada exclusivamente por `parse` e as funções que classificam e extraem partes das listas rotuladas produzidas por `parse`.
2222

23-
<Figure
24-
src="/img/chapter-4/ch4-parse-abstraction.svg"
25-
alt="Abstração de sintaxe no avaliador"
26-
caption="Abstração de sintaxe no avaliador."
27-
/>
23+
```mermaid
24+
flowchart TB
25+
subgraph Layer1["AVALIADOR"]
26+
direction LR
27+
Eval["evaluate()<br/>apply()<br/>outras funções<br/>do avaliador"]
28+
end
29+
30+
subgraph Barrier1["BARREIRA DE ABSTRAÇÃO 1"]
31+
direction LR
32+
Predicates["Predicados e Seletores de Sintaxe:<br/>is_literal(), literal_value()<br/>is_application(), function_expression()<br/>is_conditional(), conditional_predicate()<br/>..."]
33+
end
34+
35+
subgraph Layer2["REPRESENTAÇÃO DE LISTA ROTULADA"]
36+
direction LR
37+
Tagged["list('literal', 5)<br/>list('application', ...)<br/>list('conditional_expression', ...)<br/>..."]
38+
end
39+
40+
subgraph Barrier2["BARREIRA DE ABSTRAÇÃO 2"]
41+
direction LR
42+
Parser["parse()"]
43+
end
44+
45+
subgraph Layer3["REPRESENTAÇÃO DE STRING"]
46+
direction LR
47+
String["'const size = 2; 5 * size;'<br/>'factorial(5)'<br/>'x === 1 ? 1 : x'"]
48+
end
49+
50+
Layer1 --> Barrier1
51+
Barrier1 --> Layer2
52+
Layer2 --> Barrier2
53+
Barrier2 --> Layer3
54+
55+
style Layer1 fill:#E8F5E9,stroke:#2E7D32,stroke-width:3px
56+
style Layer2 fill:#FFF9C4,stroke:#F57F17,stroke-width:3px
57+
style Layer3 fill:#E3F2FD,stroke:#1565C0,stroke-width:3px
58+
style Barrier1 fill:#FFE0B2,stroke:#E65100,stroke-width:2px,stroke-dasharray: 5 5
59+
style Barrier2 fill:#FFE0B2,stroke:#E65100,stroke-width:2px,stroke-dasharray: 5 5
60+
style Eval fill:#C8E6C9,stroke:#388E3C
61+
style Predicates fill:#FFCC80,stroke:#EF6C00
62+
style Tagged fill:#FFF59D,stroke:#F9A825
63+
style Parser fill:#FFCC80,stroke:#EF6C00
64+
style String fill:#90CAF9,stroke:#1976D2
65+
```
66+
67+
**Figura:** Abstração de sintaxe no avaliador. A barreira de abstração 1 (predicados e seletores) separa o avaliador da representação de lista rotulada. A barreira de abstração 2 (`parse`) separa a representação de lista da representação de string.
2868

2969
A figura acima representa a barreira de abstração formada pelos predicados e seletores de sintaxe, que interfaceiam o avaliador à representação de lista rotulada de programas, que por sua vez é separada da representação de string por `parse`. Abaixo descrevemos o parsing de componentes do programa e listamos os predicados e seletores de sintaxe correspondentes, bem como construtores se forem necessários.
3070

docs/chapter-4/4.1.5.mdx

Lines changed: 59 additions & 10 deletions
Original file line numberDiff line numberDiff line change
@@ -12,19 +12,68 @@ function factorial(n) {
1212

1313
Podemos considerar este programa como a descrição de uma máquina contendo partes que decrementam, multiplicam e testam igualdade, juntamente com um switch de duas posições e outra máquina de fatorial. (A máquina de fatorial é infinita porque contém outra máquina de fatorial dentro dela.) A figura 4.2 é um diagrama de fluxo para a máquina de fatorial, mostrando como as partes são conectadas.
1414

15-
<Figure
16-
src="/img/chapter-4/ch4-Z-G-2.svg"
17-
alt="O programa fatorial, visto como uma máquina abstrata"
18-
caption="O programa fatorial, visto como uma máquina abstrata."
19-
/>
15+
```mermaid
16+
flowchart TB
17+
Start([entrada: n]) --> Test{teste<br/>igualdade<br/>n === 1?}
18+
19+
Test -->|sim| Return1[saída: 1]
20+
Test -->|não| Dec[decremento<br/>n - 1]
21+
22+
Dec --> Factorial[factorial<br/>máquina de fatorial<br/><i>recursiva</i>]
23+
24+
Factorial --> Mult[multiplicação<br/>resultado × n]
25+
Mult --> ReturnResult([saída: resultado])
26+
27+
style Test fill:#FFE6E6,stroke:#FF6B6B,stroke-width:2px
28+
style Dec fill:#E3F2FD,stroke:#2196F3,stroke-width:2px
29+
style Mult fill:#E3F2FD,stroke:#2196F3,stroke-width:2px
30+
style Factorial fill:#FFF9C4,stroke:#FFA000,stroke-width:3px,stroke-dasharray: 5 5
31+
style Return1 fill:#C8E6C9,stroke:#4CAF50,stroke-width:2px
32+
style ReturnResult fill:#C8E6C9,stroke:#4CAF50,stroke-width:2px
33+
style Start fill:#F3E5F5,stroke:#9C27B0,stroke-width:2px
34+
```
35+
36+
**Figura 4.2:** O programa fatorial, visto como uma máquina abstrata. A máquina contém um teste de igualdade (vermelho), operações de decremento e multiplicação (azul), e recursivamente contém outra máquina de fatorial (amarelo tracejado).
2037

2138
De maneira similar, podemos considerar o avaliador como uma máquina muito especial que recebe como entrada uma descrição de uma máquina. Dada esta entrada, o avaliador se configura para emular a máquina descrita. Por exemplo, se alimentarmos nosso avaliador com a definição de `factorial`, como mostrado na figura 4.3, o avaliador será capaz de computar fatoriais.
2239

23-
<Figure
24-
src="/img/chapter-4/ch4-Z-G-3.svg"
25-
alt="O avaliador emulando uma máquina de fatorial"
26-
caption="O avaliador emulando uma máquina de fatorial."
27-
/>
40+
```mermaid
41+
flowchart TB
42+
subgraph Evaluator["AVALIADOR (Máquina Universal)"]
43+
direction TB
44+
Input[["entrada:<br/>definição de factorial"]] --> Parse[analisador<br/>sintático]
45+
Parse --> EvalCycle[ciclo<br/>evaluate-apply]
46+
47+
subgraph EmulatedMachine["Máquina Emulada"]
48+
direction TB
49+
ETest{teste<br/>n === 1?}
50+
EDec[decremento<br/>n - 1]
51+
EFact[chamada<br/>recursiva]
52+
EMult[multiplicação<br/>× n]
53+
ETest -->|sim| EReturn1[retorna 1]
54+
ETest -->|não| EDec --> EFact --> EMult --> EReturnResult[retorna resultado]
55+
56+
style ETest fill:#FFE6E6,stroke:#FF6B6B,stroke-width:1px
57+
style EDec fill:#E3F2FD,stroke:#2196F3,stroke-width:1px
58+
style EMult fill:#E3F2FD,stroke:#2196F3,stroke-width:1px
59+
style EFact fill:#FFF9C4,stroke:#FFA000,stroke-width:2px,stroke-dasharray: 3 3
60+
style EReturn1 fill:#C8E6C9,stroke:#4CAF50,stroke-width:1px
61+
style EReturnResult fill:#C8E6C9,stroke:#4CAF50,stroke-width:1px
62+
end
63+
64+
EvalCycle --> EmulatedMachine
65+
EmulatedMachine --> Output[["saída:<br/>factorial(n)"]]
66+
end
67+
68+
style Evaluator fill:#F5F5F5,stroke:#424242,stroke-width:4px
69+
style Input fill:#E1BEE7,stroke:#7B1FA2,stroke-width:2px
70+
style Output fill:#C8E6C9,stroke:#2E7D32,stroke-width:2px
71+
style Parse fill:#BBDEFB,stroke:#1976D2,stroke-width:2px
72+
style EvalCycle fill:#BBDEFB,stroke:#1976D2,stroke-width:2px
73+
style EmulatedMachine fill:#FFFDE7,stroke:#F57F17,stroke-width:2px,stroke-dasharray: 5 5
74+
```
75+
76+
**Figura 4.3:** O avaliador emulando uma máquina de fatorial. O avaliador atua como uma máquina universal que recebe a definição da função `factorial` como entrada, analisa-a sintaticamente, e através do ciclo evaluate-apply, emula internamente a máquina de fatorial descrita na Figura 4.2.
2877

2978
Desta perspectiva, nosso avaliador é visto como uma _máquina universal_. Ele imita outras máquinas quando estas são descritas como programas JavaScript.[^1]
3079

docs/chapter-4/4.4.4.mdx

Lines changed: 12 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -173,6 +173,12 @@ Para cada frame no fluxo de entrada, usamos `find_assertions` (seção 4.4.4.3)
173173

174174
Manipulamos consultas `and` conforme ilustrado na figura 4.5 com a função `conjoin`, que recebe como entradas os conjuntos e o fluxo de frames e retorna o fluxo de frames estendidos. Primeiro, `conjoin` processa o fluxo de frames para encontrar o fluxo de todas as extensões de frames possíveis que satisfazem a primeira consulta na conjunção. Então, usando isso como o novo fluxo de frames, ela aplica recursivamente `conjoin` ao resto das consultas.
175175

176+
<Figure
177+
src="/img/chapter-4/Fig4.5.svg"
178+
alt="Processamento de consultas AND com fluxos de frames"
179+
caption="Figura 4.5: Processamento de consultas AND. O fluxo de frames é processado sequencialmente através de cada conjuncto."
180+
/>
181+
176182
```javascript
177183
function conjoin(conjuncts, frame_stream) {
178184
return is_empty_conjunction(conjuncts)
@@ -193,6 +199,12 @@ configura `evaluate_query` para despachar para `conjoin` quando uma forma `and`
193199

194200
Manipulamos consultas `or` de forma similar, como mostrado na figura 4.6. Os fluxos de saída para os vários disjuntos do `or` são computados separadamente e mesclados usando a função `interleave_delayed` da seção 4.4.4.6. (Veja os exercícios 4.71 e 4.72.)
195201

202+
<Figure
203+
src="/img/chapter-4/Fig4.6.svg"
204+
alt="Processamento de consultas OR com fluxos de frames"
205+
caption="Figura 4.6: Processamento de consultas OR. Os fluxos de frames dos disjuntos são intercalados para formar o resultado final."
206+
/>
207+
196208
```javascript
197209
function disjoin(disjuncts, frame_stream) {
198210
return is_empty_disjunction(disjuncts)

0 commit comments

Comments
 (0)