Table Of ContentProgramação para Arquitectura
AntónioMenezesLeitão
Setembro2012
Conteúdo
1 Prefácio 3
2 Introdução 4
2.1 LinguagensdeProgramação . . . . . . . . . . . . . . . . . . . 7
2.2 Exercícios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3 ALinguagemRacket 8
3.1 Sintaxe,SemânticaePragmática . . . . . . . . . . . . . . . . 9
3.2 SintaxeeSemânticadoRacket . . . . . . . . . . . . . . . . . . 9
3.3 OAvaliador . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.4 ElementosdaLinguagem . . . . . . . . . . . . . . . . . . . . 11
3.5 Números . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.6 Combinações . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.7 Indentação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.8 AvaliaçãodeCombinações . . . . . . . . . . . . . . . . . . . . 16
3.9 CadeiasdeCaracteres . . . . . . . . . . . . . . . . . . . . . . 16
3.10 DefiniçãodeFunções . . . . . . . . . . . . . . . . . . . . . . . 17
3.11 Nomes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
3.12 FunçõesPré-Definidas . . . . . . . . . . . . . . . . . . . . . . 22
3.13 AritméticaemRacket . . . . . . . . . . . . . . . . . . . . . . . 25
3.14 AvaliaçãodeNomes . . . . . . . . . . . . . . . . . . . . . . . 26
3.15 ExpressõesCondicionais . . . . . . . . . . . . . . . . . . . . . 27
3.16 ExpressõesLógicas . . . . . . . . . . . . . . . . . . . . . . . . 27
3.17 ValoresLógicos . . . . . . . . . . . . . . . . . . . . . . . . . . 28
3.18 Predicados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
3.19 PredicadosAritméticos . . . . . . . . . . . . . . . . . . . . . . 28
3.20 OperadoresLógicos . . . . . . . . . . . . . . . . . . . . . . . . 29
3.21 Predicadoscomnúmerovariáveldeargumentos . . . . . . . 29
3.22 Reconhecedores . . . . . . . . . . . . . . . . . . . . . . . . . . 30
3.23 Exercícios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.24 Selecção . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
3.25 SelecçãoMúltipla . . . . . . . . . . . . . . . . . . . . . . . . . 34
3.26 VariáveisLocais . . . . . . . . . . . . . . . . . . . . . . . . . . 35
3.27 VariáveisGlobais . . . . . . . . . . . . . . . . . . . . . . . . . 37
3.28 Módulos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
4 ModelaçãoGeométrica 39
4.1 Coordenadas . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
4.2 OperaçõescomCoordenadas . . . . . . . . . . . . . . . . . . 41
4.3 CoordenadasBidimensionais . . . . . . . . . . . . . . . . . . 44
4.4 CoordenadasPolares . . . . . . . . . . . . . . . . . . . . . . . 45
4.5 ModelaçãoGeométricaBidimensional . . . . . . . . . . . . . 48
1
4.6 EfeitosSecundários . . . . . . . . . . . . . . . . . . . . . . . . 52
4.7 Sequenciação . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
4.8 AOrdemDórica . . . . . . . . . . . . . . . . . . . . . . . . . . 56
4.9 ParametrizaçãodeFigurasGeométricas . . . . . . . . . . . . 59
4.10 Documentação . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
4.11 Depuração . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
4.11.1 ErrosSintáticos . . . . . . . . . . . . . . . . . . . . . . 67
4.11.2 ErrosSemânticos . . . . . . . . . . . . . . . . . . . . . 68
4.12 ModelaçãoTridimensional . . . . . . . . . . . . . . . . . . . . 69
4.12.1 SólidosTridimensionaisPré-Definidos . . . . . . . . . 69
4.12.2 CoordenadasCilíndricas . . . . . . . . . . . . . . . . . 73
4.12.3 CoordenadasEsféricas . . . . . . . . . . . . . . . . . . 75
4.12.4 ModelaçãodeColunasDóricas . . . . . . . . . . . . . 77
4.13 ProporçõesdeVitrúvio . . . . . . . . . . . . . . . . . . . . . . 79
4.14 Recursão . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
4.15 RecursãoemArquitectura . . . . . . . . . . . . . . . . . . . . 91
4.16 DepuraçãodeProgramasRecursivos . . . . . . . . . . . . . . 95
4.16.1 Trace . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
4.17 TemplosDóricos . . . . . . . . . . . . . . . . . . . . . . . . . . 98
4.18 AOrdemJónica . . . . . . . . . . . . . . . . . . . . . . . . . . 110
4.19 RecursãonaNatureza . . . . . . . . . . . . . . . . . . . . . . 117
5 Atribuição 122
5.1 Aleatoriedade . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
5.2 NúmerosAleatórios . . . . . . . . . . . . . . . . . . . . . . . 124
5.3 Estado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126
5.4 EscolhasAleatórias . . . . . . . . . . . . . . . . . . . . . . . . 128
5.4.1 NúmerosAleatóriosFraccionários . . . . . . . . . . . 130
5.4.2 NúmerosAleatóriosnumIntervalo . . . . . . . . . . 131
5.5 PlaneamentoUrbano . . . . . . . . . . . . . . . . . . . . . . . 136
2
1 Prefácio
Este livro nasceu em 2007, após um convite para leccionar uma disciplina
introdutória de Programação aos alunos de Arquitectura do Instituto Su-
perior Técnico (IST). A motivação original para a introdução da disciplina
no curso de Arquitectura era a mesma que para muitos outros cursos: à
semelhança da Matemática e da Física, a Programação tornou-se parte da
formaçãobásicadequalqueralunodoIST.
Comestapremissa,nãopareciaserumadisciplinaqueviesseadesper-
tar grande interesse nos alunos de Arquitectura, particularmente porque
era pouco clara a contribuição que ela pudesse ter para o curso. Para con-
trariaressaimpressãoinicial, decidiincorporarnoprogramadadisciplina
algumas aplicações da Programação em Arquitectura. Nesse sentido, fui
falar com alunos e docentes de Arquitectura, e pedi-lhes que me explicas-
semoquefaziamecomoofaziam. Oquevieouvifoirevelador.
Apesar dos enormes progressos que as ferramentas de Computer-Aided
Design (CAD) vieram trazer à profissão, a verdade é que a sua utilização
continua manual, laboriosa, repetitiva, aborrecida. A elaboração de um
modelo digital numa ferramenta de CAD implica uma enorme atenção ao
pormenor, impedindo a concentração no fundamental: a ideia. Frequen-
temente, os obstáculos encontrados acabam por forçar o Arquitecto a ter
de simplificar a ideia original. Infelizmente, esses obstáculos não termi-
namcomacriaçãodomodelo. Pelocontrário,agravam-sequandosurgea
inevitávelnecessidadedealteraçõesaomodelo.
Em geral, as ferramentas de CAD são concebidas para facilitar a reali-
zaçãodastarefasmaiscomuns,emdetrimentodeoutrasmenosfrequentes
oumaissofisticadas. Naverdade,paraoArquitectointeressadoemmode-
larformasmaiscomplexas,aferramentadeCADpoderáapresentarsérias
limitações. E,contudo,essaslimitaçõessãoapenasaparentes,poisépossí-
velultrapassá-lasporintermédiodaprogramação. Aprogramaçãopermite
queumaferramentadeCADsejaampliadacomnovascapacidades,elimi-
nandoosobstáculosqueimpedemotrabalhodoArquitecto.
A actividade da programação é intelectualmente muito estimulante,
masétambémumdesafio. Implicadominarumanovalinguagem,implica
adoptarumanovaformadepensar. Frequentemente,esseesforçofazmui-
tos desistirem, mas os que conseguem ultrapassar as dificuldades iniciais
ficamcomacapacidadedeirmaislongenacriaçãodesoluçõesarquitectó-
nicasinovadoras.
EstelivropretendeiraoencontrodessesArquitectos.
3
2 Introdução
A transmissão de conhecimento é um dos problemas que desde cedo pre-
ocupouahumanidade. Sendoohomemcapazdeacumularconhecimento
ao longo de toda a sua vida, é com desânimo que enfrenta a ideia de que,
comamorte,todoesseconhecimentoseperca.
Para evitar esta perda, a humanidade inventou toda uma série de me-
canismosdetransmissãodeconhecimento. Oprimeiro,atransmissãooral,
consistenatransmissãodoconhecimentodeumapessoaparaumgrupore-
duzidodeoutraspessoas,decertaformatransferindooproblemadaperda
de conhecimento para a geração seguinte. O segundo, a transmissão es-
crita,consisteemregistaremdocumentosoconhecimentoquesepretende
transmitir. Estaformatemagrandevantagemde,porumlado,poderche-
gar a muitas mais pessoas e, por outro, de reduzir significativamente o
riscodeseperderoconhecimentoporproblemasdetransmissão. Defacto,
a palavra escrita permite preservar por muito tempo e sem qualquer tipo
deadulteraçãooconhecimentoqueoautorpretendeutransmitir.
Égraçasàpalavraescritaquehojeconseguimoscompreendereacumu-
lar um vastíssimo conjunto de conhecimentos, muitos deles registados há
milharesdeanosatrás.
Infelizmente, nem sempre a palavra escrita conseguiu transmitir com
rigor aquilo que o autor pretendia. A língua natural tem inúmeras ambi-
guidadeseevoluisubstancialmentecomotempo,oquelevaaqueainter-
pretaçãodostextossejasempreumatarefasubjectiva. Querquandoescre-
vemosumtexto,querquandoolemoseointerpretamos,existemomissões,
imprecisões,incorrecçõeseambiguidadesquepodemtornaratransmissão
de conhecimento falível. Se o conhecimento que se está a transmitir for
simples, o receptor da informação, em geral, consegue ter a cultura e ima-
ginação suficientes para conseguir ultrapassar os obstáculos. No caso da
transmissão de conhecimentos mais complexos já isso poderá ser muito
maisdifícil.
Quando se exige rigor na transmissão de conhecimento, fazer depen-
deracompreensãodesseconhecimentodacapacidadedeinterpretaçãode
quem o recebe pode ter consequências desastrosas e, de facto, a história
da humanidade está repleta de acontecimentos catastróficos cuja causa é,
tão somente, uma insuficiente ou errónea transmissão de conhecimento,
ouumadeficientecompreensãodoconhecimentotransmitido.
Para evitar estes problemas, inventaram-se linguagens mais rigorosas.
Amatemática,emparticular,tem-seobssessivamentepreocupadoaolongo
dosúltimosmilénioscomaconstruçãodeumalinguagemondeorigorseja
absoluto. Istopermitequeatransmissãodoconhecimentomatemáticoseja
muitomaisrigorosaquenasoutrasáreas,reduzindoaomínimoessenciala
capacidadedeimaginaçãonecessáriadequemestáaabsorveresseconhe-
cimento.
4
Paramelhorpercebermosdoqueestamosafalar,consideremosumcaso
concretodetransmissãodeconhecimento,porexemplo,ocálculodofacto-
rialdeumnúmero. Seassumirmos,comopontodepartida,queapessoaa
quemqueremostransmitiresseconhecimentojásabedeantemãooquesão
osnúmeroseasoperaçõesaritméticas,podemosdizer-lhequeparacalcular
o factorial de um número qualquer, terá de multiplicar todos os números desde a
unidade até esse número. Infelizmente, esta descrição é demasiado extensa
e, pior, é pouco rigorosa, pois não dá ao ouvinte a informação de que os
números que ele tem de multiplicar são apenas os números inteiros. Para
evitarestasimprecisõese,simultaneamente,tornarmaiscompactaainfor-
mação a transmitir, a Matemática inventou todo um conjunto de símbolos
e conceitos cujo significado deve ser compreendido por todos. Por exem-
plo,paraindicarasequênciadenúmerosinteirosentre1e9,aMatemática
permite-nos escrever 1,2,3,...,9. Do mesmo modo, para evitarmos falar
de“umnúmeroqualquer,”aMatemáticainventouoconceitodevariável: um
nome que designa qualquer “coisa” e que pode ser reutilizado em várias
partes de uma afirmação matemática com o significado óbvio de repre-
sentar sempre essa mesma “coisa.” Deste modo, a linguagem Matemática
permite-nos formular a mesma afirmação sobre o cálculo do factorial nos
seguintestermos:
n! = 1×2×3×··· ×n
Será a definição anterior suficientemente rigorosa? Será possível inter-
pretá-la sem necessitar de imaginar a intenção do autor? Aparentemente,
simmas,naverdade,háumdetalhedadefiniçãoqueexigeimaginação: as
reticências. Aquelas reticências indicam ao leitor que ele terá de imaginar
o que deveria estar no lugar delas. Embora a maioria dos leitores imagine
correctamente que o autor pretendia a multiplicação dos sucessores dos
númerosanteriores,leitoreshaverácujaimaginaçãodelirantepoderálevá-
losatentarsubstituiraquelasreticênciasporoutracoisaqualquer.
Mesmoqueexcluamosdonossopúblico-alvoaspessoasdeimaginação
delirante, há ainda outros problemas com a definição anterior. Pensemos,
porexemplo, nofactorialde2. Qualseráoseuvalor? Sesubstituirmosna
fórmula,paran = 2obtemos:
2! = 1×2×3×··· ×2
Neste caso, o cálculo deixa de fazer sentido, o que mostra que, na ver-
dade, a imaginação necessária para a interpretação da fórmula não se res-
tringeapenasàsreticênciasmassimatodaafórmula: onúmerodetermos
aconsiderardependedonúmerodoqualqueremossaberofactorial.
Admitindo que o nosso leitor teria tido a imaginação suficiente para
descobrir esse detalhe, ele conseguiria tranquilamente calcular que 2! =
1 × 2 = 2. Ainda assim, casos haverá que o deixarão significativamente
menos tranquilo. Por exemplo, qual é o factorial de zero? A resposta não
5
parece óbvia. E quanto ao factorial de −1? Novamente, não está claro. E
quanto ao factorial de 4.5? Mais uma vez, a fórmula nada diz e a nossa
imaginaçãotambémnãoconsegueadivinhar.
Será possível encontrar uma forma de transmitir o conhecimento da
funçãofactorialqueminimizeasimprecisões,lacunaseambiguidades? Ex-
perimentemosaseguintevariantedadefiniçãodafunçãofactorial:
(cid:40)
1, sen = 0
n! =
n·(n−1)!, sen ∈ N.
Teremosagoraatingidoorigorsuficientequedispensaimaginaçãopor
parte do leitor? A resposta estará na análise dos casos que causaram pro-
blemas à definição anterior. Em primeiro lugar, não existem reticências, o
queépositivo. Emsegundolugar, paraofactorialde2temos, peladefini-
ção:
2! = 2×1! = 2×(1×0!) = 2×(1×1) = 2×1 = 2
ou seja, não há qualquer ambiguidade. Finalmente, vemos que não faz
sentidodeterminarofactorialde−1oude4.5poisadefiniçãoapresentada
N
apenasseaplicaaosmembrosde .
0
Este exemplo mostra que, mesmo na matemática, há diferentes graus
de rigor nas diferentes formas como se expõe o conhecimento. Algumas
dessas formas exigem um pouco mais de imaginação e outras um pouco
menosmas,emgeral,qualquerdelastemsidosuficienteparaqueahuma-
nidadetenhaconseguidopreservaroconhecimentoadquiridoaolongoda
suahistória.
Acontece que, actualmente, a humanidade conta com um parceiro que
tem dado uma contribuição gigantesca para o seu progresso: o computa-
dor. Esta máquina tem a extraordinária capacidade de poder ser instruída
de forma a saber executar um conjunto complexo de tarefas. A actividade
da programação consiste, precisamente, na transmissão, a um computador,
doconhecimentonecessáriopararesolverumdeterminadoproblema. Esse
conhecimentoédenominadoumprograma. Porseremprogramáveis,oscom-
putadores têm sido usados para os mais variados fins e, sobretudo nas úl-
timasdécadas,têmtransformadoradicalmenteaformacomotrabalhamos.
Infelizmente,aextraordináriacapacidadede“aprendizagem”doscompu-
tadores vem acompanhada duma igualmente extraordinária incapacidade
de imaginação. O computador não imagina, apenas interpreta rigorosa-
menteoconhecimentoquelhetransmitimossobaformadeumprograma.
Umavezquenãotemimaginação,ocomputadordependecriticamente
do modo como lhe apresentamos o conhecimento que queremos transmi-
tir: esse conhecimento tem de estar descrito numa linguagem tal que não
possa haver margem para qualquer ambiguidade, lacuna ou imprecisão.
Uma linguagem com estas características denomina-se, genericamente, de
linguagemdeprogramação.
6
2.1 LinguagensdeProgramação
Para que um computador possa resolver um problema é necessário que
consigamosfazerumadescriçãodoprocessoderesoluçãodesseproblema
numa linguagem que o computador entenda. Infelizmente, a linguagem
que os computadores entendem de forma “inata” é extraordinariamente
pobre,levandoaqueaqualquerproblemanãotrivialacabeporexigiruma
exaustiva, entediante e extremamente complexa descrição do processo de
resolução. Asinúmeraslinguagensdeprogramaçãoquetêmsidoinventa-
das visam precisamente aliviar o programador desse fardo, introduzindo
elementos linguísticos capazes de simplificar enormemente essas descri-
ções. Por exemplo, os conceitos de função, matriz, somatório, ou número ra-
cionalnãoexistemnativamentenoscomputadores,masmuitaslinguagens
de programação permitem a sua utilização de modo a facilitar a descrição
de cálculos científicos. Isto implica, naturalmente, que tem de existir um
processo capaz de transformar as descrições que o programador faz em
descrições que o computador entenda. Embora este processo seja relati-
vamente complexo, o que nos importa saber é que ele permite termos lin-
guagens de programação mais próximas das capacidades do pensamento
humanodoquedascapacidadesdepensamentodocomputador.
Esteúltimofactotemumaimportânciacrucialpoispermitequepasse-
mos a usar linguagens de programação, não só para instruir um compu-
tadorsobreumaformaderesolverumproblema,mastambémparaexpli-
car rigorosamente esse processo a outros seres humanos. A linguagem de
programaçãotorna-seassimummeiodetransmissãodeconhecimento,tal
comoalinguagemdamatemáticaofoinosúltimosmilharesdeanos.
Existe uma enorme diversidade de linguagens de programação, umas
maisapetrechadasparaaresoluçãodeumdeterminadotipodeproblemas,
outrasmaisapetrechadasparaaresoluçãodeoutro. Aescolhadeumalin-
guagemdeprogramaçãodeveestarcondicionada,naturalmente,pelotipo
de problemas que queremos resolver, mas não deve ser um comprometi-
mento total. Para quem programa é muito mais importante compreender
osfundamentosetécnicasdaprogramaçãodoquedominarestaouaquela
linguagem. No entanto, para mais rigorosamente se explicar aqueles fun-
damentos e técnicas, convém exemplificá-los numa linguagem de progra-
maçãoconcreta.
Uma vez que este texto se irá focar na programação aplicada à Arqui-
tectura, vamos empregar uma linguagem de programação que esteja par-
ticularmente vocacionada para resolver problems geométricos. Várias lin-
guagens existem com esta vocação, em geral associadas a ferramentas de
desenhoassistidoporcomputador–Computer-AidedDesign(CAD).OArchi-
CAD, por exemplo, disponibiliza uma linguagem de programação deno-
minada GDL— acrónimo de Geometric Description Language—que permite
ao utilizador programar as várias formas geométricas pretendidas. Já no
7
caso do AutoCAD, a linguagem de programação empregue é o AutoLisp,
umdialectodeumafamosalinguagemdeprogramaçãodenominadaLisp.
UmaterceirahipóteseseráalinguagemRhinoScript,disponívelnoRhino-
ceros. Apesardestaslinguagenspareceremsermuitodiferentesentresi,os
conceitos subjacentes são muito semelhantes. É sobre estes conceitos fun-
damentaisdaprogramaçãoquenosiremosdebruçar,embora,pormotivos
pedagógicos,sejaconvenienteparticularizá-losnumaúnicalinguagem.
Infelizmente,aslinguagensGDL,AutoLispeRhinoScriptforamdesen-
volvidas há já bastante tempo e não foram actualizadas, possuindo várias
característicasarcaicasquetornammaisdifícilasuaaprendizagemeoseu
uso. Para facilitar a aprendizagem e, simultaneamente, permitir que os
programas que vamos desenvolver possam ser usados em diferentes fer-
ramentas de CAD, vamos empregar uma nova linguagem, denominada
Racket, que foi adaptada propositadamente para a programação aplicada
àArquitectura. Assim,nestetextoiremosexplicarosfundamentosdapro-
gramaçãoatravésdautilizaçãodalinguagemRacket, nãosópelasuafaci-
lidade de aprendizagem, mas também pela sua aplicabilidade prática. No
entanto,umavezapreendidosessesfundamentos,oleitordeverásercapaz
deostraduzirparaqualqueroutralinguagemdeprogramação.
Para facilitar as tarefas do programador, Racket vem acompanhado de
um ambiente de programação, denominado DrRacket, que disponibiliza
umeditordetextoadaptadoàediçãodeprogramasRacket,bemcomoum
conjuntodeoutrasferramentasdestinadasafacilitaradetecçãoecorrecção
deerros.
2.2 Exercícios
Exercicio2.1 A exponenciação bn é uma operação entre dois números b e n designados
baseeexpoente,respectivamente.Quandonéuminteiropositivo,aexponenciaçãodefine-
secomoumamultiplicaçãorepetida:
bn =b×b×···×b
(cid:124) (cid:123)(cid:122) (cid:125)
n
Para um leitor que nunca tenha utilizado o operador de exponenciação, a definição
anterior levanta várias questões cujas respostas poderão não lhe ser evidentes. Quantas
multiplicaçõessãorealmentefeitas?Serãonmultiplicações?Serãon−1multiplicações?O
quefazernocasob1?Enocasob0?
Proponhaumadefiniçãomatemáticadeexponenciaçãoquenãolevanteestasquestões.
Exercicio2.2 Oqueéumalinguagemdeprogramação?Paraqueserve?
3 A Linguagem Racket
Nesta secção vamos descrever a linguagem de programação Racket que
iremos usar ao longo deste texto. Antes, porém, vamos discutir alguns
aspectosquesãocomunsatodasaslinguagens.
8
3.1 Sintaxe,SemânticaePragmática
Todasaslinguagenspossuemsintaxe,semânticaepragmática.
Emtermosmuitosimples,podemosdescreverasintaxedeumalingua-
gem como o conjunto de regras que determinam as frases que se podem
construir nessa linguagem. Sem sintaxe qualquer concatenação arbitrária
depalavrasconstituiriaumafrase. Porexemplo,dadasaspalavras“João,”
“o,” “comeu,” e “bolo,” as regras da sintaxe da língua Portuguesa dizem-
nosque“oJoãocomeuobolo”éumafraseeque“ocomeuJoãobolobolo”
não é uma frase. Note-se que, de acordo com a sintaxe do Português, “o
bolocomeuoJoão”étambémumafrasesintaticamentecorrecta.
A sintaxe regula a construção das frases mas nada diz acerca do seu
significado. Éasemânticadeumalinguagemquenospermiteatribuirsig-
nificado às frases da linguagem e que nos permite perceber que a frase “o
bolocomeuoJoão”nãofazsentido.
Finalmente,apragmáticadizrespeitoàformausualcomoseescrevem
as frases da linguagem. Para uma mesma linguagem, a pragmática varia
de contexto para contexto: a forma como dois amigos íntimos falam entre
siédiferentedaformausadaporduaspessoasquemalseconhecem.
Estestrêsaspectosdaslinguagensestãotambémpresentesquandodis-
cutimoslinguagensdeprogramação. Contrariamenteaoqueacontececom
as linguagens naturais que empregamos para comunicarmos uns com os
outros, as linguagens de programação caracterizam-se por serem formais,
obedecendoaumconjuntoderegrasmuitomaissimpleserígidoqueper-
mitequesejamanalisadaseprocessadasmecanicamente.
Neste texto iremos descrever a sintaxe e semântica da linguagem Rac-
ket. Emboraexistamformalismosmatemáticosquepermitemdescreverri-
gorosamenteaquelesdoisaspectosdaslinguagens,elesexigemumasofis-
ticação matemática que, neste trabalho, é desapropriada. Por este motivo,
iremosapenasempregardescriçõesinformais.
Quanto à pragmática, será explicada à medida que formos introdu-
zindooselementosdalinguagem.
3.2 SintaxeeSemânticadoRacket
Quando comparada com a grande maioria das outras linguagens de pro-
gramação, a linguagem Racket possui uma sintaxe extraordinariamente
simplesbaseadanoconceitodeexpressão.
Uma expressão, em Racket, pode ser construída empregando elemen-
tos primitivos como, por exemplo, os números; ou combinando outras
expressões entre si como, por exemplo, quando somamos dois números.
Como iremos ver, esta simples definição permite-nos construir expressões
de complexidade arbitrária. No entanto, convém relembrar que a sintaxe
restringeaquiloquepodemosescrever: ofactodepodermoscombinarex-
9
Description:minada GDL— acrónimo de Geometric Description Language—que 3De George Boole, matemático inglês e inventor da álgebra da verdade e da