Download PDF
ads:
SEM
ˆ
ANTICA INCREMENTAL DE
LINGUAGENS DE PROGRAMAC¸
˜
AO
ads:
Livros Grátis
http://www.livrosgratis.com.br
Milhares de livros grátis para download.
ads:
FABIO TIRELO
Orientador: Roberto da Silva Bigonha
Co-Orientador: Jo
˜
ao Alexandre Baptista Saraiva
SEM
ˆ
ANTICA INCREMENTAL DE
LINGUAGENS DE PROGRAMAC¸
˜
AO
Tese apresentada ao Programa de P´os-
Gradua¸c˜ao em Ciˆencia da Computa¸c˜ao da
Universidade Federal de Minas Gerais como
requisito parcial para a obten¸c˜ao do grau de
Doutor em Ciˆencia da Computa¸c˜ao.
Belo Horizonte, Marc¸o de 2009
c
2009, Fabio Tirelo
Todos os direitos reservados
Tirelo, Fabio
T596S XXSemˆantica Incremental de Linguagens de Programa¸c˜ao
[manuscrito] / Fabio Tirelo. – 2009.
XXxii, 121f., enc. : il.
XXOrientador: Roberto da Silva Bigonha
XXCo-orientador: Jo˜ao Alexandre Baptista Saraiva
XXTese (doutorado) – Universidade Federal de Minas Gerais.
Departamento de Ciˆencia da Computa¸c˜ao.
XX1. Computa¸c˜ao – Teses. 2. Linguagens de Programa¸c˜ao – Teses.
3. Semˆantica Processamento de Dados – Teses. I. Bigonha, Robe rto
da Silva. II. Saraiva, Jo˜ao Alexandre Baptista. III. Universidade
Federal de Minas Gerais, Departamento de Ciˆencia da Computa¸c˜ao.
IV. T´ıtulo.
CDU 519.6*33
Agradecimentos
Agrade¸co a todos que contribu´ıram de alguma maneira para a conclus˜ao deste trabalho.
Inicialmente a toda a minha fam´ılia, em especial a Leonor, minha m˜ae, pelo apoio cons-
tante, n˜ao s´o durante o doutorado, mas tamb´em em todos os momentos.
A todos os meus amigos pelo companheirismo e pelos bons momentos, que foram essen-
ciais para suportar as etapas mais dif´ıceis do trabalho. Ao Alexandre Bustamante, p ela
paciˆencia e por estar sempre do meu lado, dando apoio e coragem durante todo o processo.
`
As amigas
´
Erika e Ludmila Andrade, pela excelente acolhida na volta ao Brasil. Ao amigo
Vladimir Oliveira di Iorio, pelo exemplo e pela motiva¸c˜ao em iniciar, continuar e concluir
este trabalho.
`
As amigas Ana Paula Amazonas Soares e Raquel Hennig, pelo companhei-
rismo e acolhida nos mese s em que passei no exterior.
`
As amigas Cassia Prates-Clarke
e Adriana Andrade Oliveira, pelas palavras de apoio, por sempre motivar a concluir este
trabalho, e pelo incentivo a buscar a experiˆencia de fazer parte deste trabalho no exterior.
Aos colegas e amigos da PUC Minas, em especial Juliana do Amaral Baroni, Lucila Ishitani,
Maria Cristina Martins de Andrade (Tininha), Marcelo Souza Nery, Marco T´ulio Oliveira
Valente, Marlete Barroso Schreib er, Nelma Rocha, Rodrigo Baroni, Raquel A. F. Mini,
Rosilane Ribeiro da Mota, Silvio Jamil F. Guimar˜aes, Soraia L´ucia da Silva, Zenilton
Kleber G. Patro c´ınio Jr., pela motiva¸c˜ao em continuar este trabalho, pelas palavras de
apoio, e, por tantas vezes, auxiliarem no cumprimento de atividades a mim designadas.
Ao professor Roberto Bigonha, pela orienta¸c˜ao precisa, por confiar em meu trabalho, pe-
las palavras de apoio e motiva¸c˜ao nos momentos mais necess´arios, pela empolga¸c˜ao pelo
projeto mesmo nas ´epocas em que eu n˜ao acreditava que seria poss´ıvel conclu´ı-lo.
Ao professor Jo˜ao Saraiva, pela exce pcional acolhida em Portugal e por todo o apoio dado
durante a exec u¸c˜ao do trabalho.
`
A professora Mariza Andrade da Silva Bigonha, pelas
muitas e valiosas contribui¸c˜oes em diversos momentos deste trabalho. Ao professor Peter
Mosses, da Universidade de Walles em Swansea, pelas valiosas sugest˜oes que levaram `a
vers˜ao final do trabalho.
Aos colegas e amigos do Laborat´orio de Linguagens de Programa¸c˜ao da UFMG, em espe-
cial, a Eduardo Santos Cordeiro, Tays Cristina Soares, Italo Giovanni, Leonardo Passos
e Kristian Magnani, pelos bons momentos durante o tempo em que compartilhamos o
laborat´orio, pela confian¸ca e pelo apoio dado mesmo ap´os o t´ermino do per´ıodo em que
trabalhamos juntos.
Aos colegas e amigos do gabinete dos “Sem Estatuto”na Universidade do Minho, em espe-
cial, ao J´acome Cunha, Jo˜ao Paulo Fernandes, Paulo Filipe Silva, Miguel Vila¸ca e Ricardo
Vila¸ca, pela excelente recep¸c˜ao e pelos ´otimos momentos compartilhados durante o per´ıodo
em que morei em Portugal.
Aos professores Marco Tulio Oliveira Valente, Roberto Ierusalimskchy, Mariza D Bigonha
e Newton Jos´e Vieira, por aceitarem participar da banca e pe las valiosas sugest˜oes dadas
durante a defesa.
`
A Secretaria do Programa de P ´os-Gradua¸c˜ao em Ciˆencia da Computa¸c˜ao da UFMG, em
especial, a Renata Viana Moraes Rocha e a Sheila L´ucia dos Santos, pela simpatia e pela
agilidade e disponibilidade em fornecer informa¸c˜oes sempre que solicitadas.
`
A CAPES, pela bolsa de doutorado no per´ıodo que passei no exterior, e `a FAPEMIG, pelo
apoio financeiro ao projeto de pesquisa.
A todos os outros que contribu´ıram direta ou indiretamente para a conclus˜ao deste trabalho
e que n˜ao tenham sido citados aqui.
Resumo
Este trabalho de tese aborda uma nova metodologia para o problema da escalabilidade em
Semˆantica Denotacional, denominada Semˆantica Incremental. Neste trabalho, considera-
se que uma linguagem de programa¸c˜ao possa ser definida por meio de uma sequˆencia de
especifica¸c˜oes, onde cada especifica¸c˜ao inclui novos conceitos, com a possibilidade de for-
necer novas reinterpreta¸c˜oes `as equa¸c˜oes existentes na especifica¸c˜ao anterior. Os conceitos
mais importantes utilizados s˜ao a vagueza, no sentido que equa¸c˜oes semˆanticas s˜ao vagas
em rela¸c˜ao a conceitos a serem abordados em especifica¸c˜oes mais avan¸cadas, e fun¸c˜oes de
transforma¸c˜ao, que permitem a evolu¸c˜ao das equa¸c ˜oes semˆanticas ao longo da sequˆencia de
especifica¸c˜oes. Neste contexto, a vagueza, comum em defini¸c˜oes informais, traz melhorias
na legibilidade de defini¸c˜oes formais, uma vez que permite a remo¸c˜ao do entrela¸camento
de equa¸c˜oes semˆanticas.
Como principais contribui¸c˜oes do trabalho, podem-se citar: a defini¸c˜ao de uma nova meto-
dologia para a escrita de defini¸c˜oes incrementais e modulares; a defini¸c˜ao de um ambiente
de desenvolvimento para a metodologia, que permite a escrita de prot´otipos de interpreta-
dores para linguagens definidas, incluindo an´alises l´exica, sint´atica e semˆantica; utiliza¸c˜ao
e formaliza¸c˜ao da vagueza em m´etodos formais.
Abstract
This thesis presents a new methodology for the scalability problem in Denotational Seman-
tics, named Incremental Semantics. This work considers that a programming language can
be defined as a sequence of specifications, so that each new specification includes new ele-
ments into an existing one, and, if necessary, provides new reinterpretation to existing
equations. The main concepts of the method are vagueness, in the sense that semantic
equations are vague with respect to concepts to be presented in advanced specifications, and
transformation functions, which allows semantic equations to evolve throughout specifica-
tion sequences. In this context, vagueness, usually applied in informal definitions, brings
about improvements in the readability of formal definitions, once semantic equations may
be disentangled.
The main contributions of this work are: the definition of a new methodology for writing in-
cremental and modular definitions; the implementation of a programming environment for
applying the metho dology, which generates interpreter prototypes for a language, including
lexer, parser, and semantics; usage and formalization of vagueness in formal methods.
x
Conte´udo
1 Introdu¸c˜ao 1
2 Modularidade de Sistemas de Software 5
2.1 Evolu¸c˜ao das T´ecnicas de Modularidade . . . . . . . . . . . . . . . . . . . 6
2.2 M´etricas de Modularidade . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.3 Programa¸c˜ao Orientada por Aspectos . . . . . . . . . . . . . . . . . . . . . 8
2.3.1 Metodologia de Desenvolvimento . . . . . . . . . . . . . . . . . . . 12
2.3.2 Linguagens Orientadas por As pectos . . . . . . . . . . . . . . . . . 13
2.3.3 Aplica¸c˜oes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.3.4 Avalia¸c˜ao da T´ecnica . . . . . . . . . . . . . . . . . . . . . . . . . . 24
2.4 Conclus˜oes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3 Modularidade da Semˆantica Denotacional 29
3.1 Semˆantica de Linguagens de Programa¸c˜ao . . . . . . . . . . . . . . . . . . 29
3.1.1 Semˆantica Axiom´atica . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.1.2 Semˆantica Operacional . . . . . . . . . . . . . . . . . . . . . . . . . 33
3.1.3 Semˆantica Denotacional . . . . . . . . . . . . . . . . . . . . . . . . 36
3.2 Modularidade em Semˆantica Denotacional . . . . . . . . . . . . . . . . . . 38
3.2.1 Semˆantica de A¸c˜oes . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
3.2.2 Semˆantica de Mˆonadas . . . . . . . . . . . . . . . . . . . . . . . . . 42
xi
xii CONTE
´
UDO
3.2.3 Semˆantica de A¸c˜oes com Mˆonadas . . . . . . . . . . . . . . . . . . . 48
3.2.4 Gram´aticas de Atributos de Primeira Classe . . . . . . . . . . . . . 49
3.2.5 Semˆantica Construtiva . . . . . . . . . . . . . . . . . . . . . . . . . 49
3.3 Conclus˜oes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
4 Semˆantica Incremental 53
4.1 Vagueza e Legibilidade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
4.2 Defini¸c˜oes Incrementais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
4.3 Fun¸c˜oes de Transforma¸c˜ao . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
4.3.1 Inclus˜ao de Argumentos . . . . . . . . . . . . . . . . . . . . . . . . 60
4.3.2 Decoradores de Fun¸c˜ao . . . . . . . . . . . . . . . . . . . . . . . . . 62
4.3.3 Redefini¸c˜ao de Equa¸c˜oes . . . . . . . . . . . . . . . . . . . . . . . . 64
4.4 Formaliza¸c˜ao do Modelo . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
4.4.1 Dom´ınios Sint´aticos . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
4.4.2 Dom´ınios Semˆanticos . . . . . . . . . . . . . . . . . . . . . . . . . . 66
4.4.3 Fun¸c˜oes Semˆanticas . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
4.4.4 Equa¸c˜oes Semˆanticas . . . . . . . . . . . . . . . . . . . . . . . . . . 68
4.5 Estudos de Caso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
4.5.1 M´etodos e Tratamento de Exce¸c˜oes . . . . . . . . . . . . . . . . . . 73
4.5.2 Defini¸c˜ao de Procedimentos e Adendos . . . . . . . . . . . . . . . . 74
4.6 Conclus˜oes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
5 Ambiente Para Semˆantica Incremental 79
5.1 Organiza¸c˜ao Modular . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
5.1.1 Estrutura de Pacotes . . . . . . . . . . . . . . . . . . . . . . . . . . 80
5.1.2 M´odulos e Visibilidade . . . . . . . . . . . . . . . . . . . . . . . . . 81
5.1.3 Regras de Importa¸c˜ao de Identificadores . . . . . . . . . . . . . . . 82
5.1.4 Extens˜ao de Componentes . . . . . . . . . . . . . . . . . . . . . . . 83
CONTE
´
UDO xiii
5.1.5 Especifica¸c˜ao Inicial . . . . . . . . . . . . . . . . . . . . . . . . . . 84
5.1.6 Extens˜ao de Linguagem . . . . . . . . . . . . . . . . . . . . . . . . 86
5.2 Dom´ınios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
5.2.1 Nota¸c˜ao B´asica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
5.2.2 Dom´ınios Sint´aticos . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
5.2.3 Dom´ınios Semˆanticos . . . . . . . . . . . . . . . . . . . . . . . . . . 89
5.2.4 Extens˜oes de Dom´ınios . . . . . . . . . . . . . . . . . . . . . . . . . 95
5.3 Defini¸c˜ao Sint´atica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
5.3.1 Nota¸c˜ao B´asica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
5.3.2 Pr´e-processamento de Arquivo Fonte . . . . . . . . . . . . . . . . . 96
5.3.3 Defini¸c˜ao do Analisador L´exico . . . . . . . . . . . . . . . . . . . . 96
5.3.4 Defini¸c˜ao do Analisador Sint´atico . . . . . . . . . . . . . . . . . . . 102
5.4 Defini¸c˜ao Semˆantica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
5.4.1 Fun¸c˜oes Semˆanticas . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
5.4.2 Padr˜oes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
5.4.3 Express˜oes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126
5.5 Fun¸c˜oes de Transforma¸c˜ao . . . . . . . . . . . . . . . . . . . . . . . . . . . 137
5.6 Especifica¸c˜ao Baseada em Componentes . . . . . . . . . . . . . . . . . . . 137
5.7 Compilador de Notus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138
5.8 Conclus˜oes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141
6 Avalia¸c˜ao 145
6.1 Avalia¸c˜ao da Metodologia . . . . . . . . . . . . . . . . . . . . . . . . . . . 145
6.2 Compara¸c˜ao com Trabalhos Relacionados . . . . . . . . . . . . . . . . . . . 148
6.3 Conclus˜oes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150
7 Conclus˜oes 151
7.1 Contribui¸c˜oes do Trabalho . . . . . . . . . . . . . . . . . . . . . . . . . . . 152
xiv CONTE
´
UDO
7.2 Trabalhos Futuros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153
A The Syntax of Notus 155
A.1 Lexis Convention . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155
A.2 Modular Organization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159
A.3 Domains . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160
A.4 Lexis Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161
A.5 Syntax Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162
A.6 Function Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163
A.7 Patterns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164
A.8 Expressions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165
A.9 Transformation Clauses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168
B Examples of Language Definitions in Notus 169
B.1 Example of Syntax Definition: Language Nano . . . . . . . . . . . . . . . . 169
B.1.1 Language Definition . . . . . . . . . . . . . . . . . . . . . . . . . . 169
B.1.2 Lexis of Nano . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170
B.1.3 Syntax of Nano . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173
B.1.4 Abstract Grammar of Nano . . . . . . . . . . . . . . . . . . . . . . 173
B.1.5 Domains of Nano . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175
B.2 Example of Semantics Definition: Language Sek . . . . . . . . . . . . . . . 176
B.2.1 Kernel Language . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176
B.2.2 Memory Abstraction . . . . . . . . . . . . . . . . . . . . . . . . . . 176
B.2.3 Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178
B.2.4 Declarations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178
B.2.5 Basic Expressions . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178
B.2.6 Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178
B.2.7 Sequences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179
CONTE
´
UDO xv
B.2.8 Programs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183
B.2.9 Main Module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183
B.3 Example of Incremental Definition: Language Tiny . . . . . . . . . . . . . 186
B.3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186
B.3.2 Initial Specification . . . . . . . . . . . . . . . . . . . . . . . . . . . 186
B.3.3 Specification Tiny1 . . . . . . . . . . . . . . . . . . . . . . . . . . . 196
C Auxiliary Algorithms 201
C.1 Transforming Notus Grammars into BNF . . . . . . . . . . . . . . . . . . . 201
C.2 Simplification of Abstract Grammars . . . . . . . . . . . . . . . . . . . . . 203
C.3 Automatic Generation of Abstract Grammars . . . . . . . . . . . . . . . . 205
xvi CONTE
´
UDO
Lista de Tabelas
2.1 N´ıveis de Coes˜ao Modular . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.2 N´ıveis de Acoplamento entre M´odulos . . . . . . . . . . . . . . . . . . . . . 9
5.1 Precedˆencia de Opera¸c˜oes de Dom´ınio . . . . . . . . . . . . . . . . . . . . 90
5.2 Precedˆencia das Opera¸c˜oes de Express˜oes Regulares . . . . . . . . . . . . . 99
5.3 Exemplos de Express˜oes Regulares . . . . . . . . . . . . . . . . . . . . . . 99
5.4 Fun¸c˜oes Pr´e-Definidas em Notus . . . . . . . . . . . . . . . . . . . . . . . . 115
5.5 Operadores Aritm´eticos de Notus . . . . . . . . . . . . . . . . . . . . . . . 129
5.6 Operadores Bit-a-bit de Notus . . . . . . . . . . . . . . . . . . . . . . . . . 130
5.7 Operadores Relacionais de Notus . . . . . . . . . . . . . . . . . . . . . . . 130
5.8 Operadores L´ogicos de Notus . . . . . . . . . . . . . . . . . . . . . . . . . 130
5.9 Operadores de Lista de Notus . . . . . . . . . . . . . . . . . . . . . . . . . 131
5.10 Operador de Composi¸c ˜ao de Fun¸c˜oes de Notus . . . . . . . . . . . . . . . . 131
5.11 Operador de Casamento de Padr˜oes de Notus . . . . . . . . . . . . . . . . 131
B.1 Precedence and Associativity in Tiny . . . . . . . . . . . . . . . . . . . . . 188
xvii
xviii LISTA DE TABELAS
Lista de Figuras
2.1 Representa¸c˜ao em UML do padr˜ao wormhole. . . . . . . . . . . . . . . . . 22
2.2 Implementa¸c˜ao de transmiss˜ao de contexto via passagem de parˆametros. . 23
2.3 Representa¸c˜ao gr´afica do padr˜ao wormhole. . . . . . . . . . . . . . . . . . . 25
3.1 Exemplo de semˆantica axiom´atica de uma linguagem. . . . . . . . . . . . . 32
3.2 Exemplo de semˆantica operacional estruturada de uma linguagem simples
contendo atribui¸c˜oes e condicionais. . . . . . . . . . . . . . . . . . . . . . . 34
3.3 Exemplo de semˆantica operacional de uma linguagem. . . . . . . . . . . . . 35
3.4 Exemplo de semˆantica denotacional de uma linguagem. . . . . . . . . . . . 38
3.5 Exemplo de semˆantica de a¸c˜oes para as express˜oes de uma linguagem. . . . 40
3.6 Exemplo de semˆantica de a¸c˜oes para os comandos de uma linguagem. . . . 41
3.7 Defini¸c˜ao em semˆantica de a¸c˜oes do comando condicional if-then-else. . . . 43
3.8 Defini¸c˜ao de uma categoria. . . . . . . . . . . . . . . . . . . . . . . . . . . 44
3.9 No¸c˜oes de computa¸c˜ao. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
3.10 Defini¸c˜ao de mˆonadas. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
3.11 Exemplo de interpretador escrito em linguagem Haskell, utilizando mˆonadas. 47
3.12 Exemplos de mˆonadas para um interpretador. . . . . . . . . . . . . . . . . 48
4.1 Exemplo utilizado na explica¸c˜ao dos transformadores. . . . . . . . . . . . . 59
4.2 Defini¸c˜oes B´asicas para a Semˆantica de Adendos e Pontos de Jun¸c˜ao da
Programa¸c˜ao Orientada por Aspectos. . . . . . . . . . . . . . . . . . . . . 75
xix
xx LISTA DE FIGURAS
5.1 Exemplo de Organiza¸c˜ao Modular de Defini¸c˜ao Incremental de uma Lingua-
gem Hipot´etica L. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
5.2 Estrutura Geral do Compilador de Notus. . . . . . . . . . . . . . . . . . . 139
C.1 Example of Graph Generated by Algorithm II for Grammar G
. . . . . . . 205
Listagens
2.1 Exemplo de Entrela¸camento de C´odigo – Extra´ıdo de Gradecki and Lesieck
(2003) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.2 Aspecto Para Logging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.3 Protocolo Para o Padr˜ao de Projetos Observador . . . . . . . . . . . . . . 17
2.4 Classe Termometer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.5 Classe Temperature . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.6 Aspecto Para Observa¸c˜ao de Temperatura . . . . . . . . . . . . . . . . . . 20
2.7 Classe TermometerCelsius . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.8 Classe TermometerFahrenheit . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.9 Exemplo do Uso do Protocolo de Observa¸c˜ao . . . . . . . . . . . . . . . . . 21
2.10 Protocolo Para o Padr˜ao Wormhole – Extra´ıdo de Gradecki and Lesieck (2003) 24
4.1 Interdependˆencia de Arranjos de Objetos e Hierarquia de Tipos em Java . 56
5.1 Exemplo do Uso de Visibilidade em Notus . . . . . . . . . . . . . . . . . . 82
5.2 Exemplo de Resolu¸c˜ao de Colis˜ao de Nomes . . . . . . . . . . . . . . . . . 83
5.3 Exemplo de M´odulo Principal da Linguagem L . . . . . . . . . . . . . . . . 85
5.4 Exemplo de M´odulo de Extens˜ao Main.nts Para a Linguagem L . . . . . . 87
5.5 Exemplos de Defini¸c˜ao de Dom´ınio Sint´atico . . . . . . . . . . . . . . . . . 88
5.6 Exemplos de Defini¸c˜ao de Dom´ınio Semˆantico . . . . . . . . . . . . . . . . 89
5.7 Exemplos de Defini¸c˜ao de Enumera¸c˜oes . . . . . . . . . . . . . . . . . . . . 91
5.8 Exemplo de Dom´ınio Uni˜ao Disjunta . . . . . . . . . . . . . . . . . . . . . 92
xxi
xxii LISTAGENS
5.9 Exemplos de Defini¸c˜oes de Dom´ınios de Tuplas . . . . . . . . . . . . . . . . 93
5.10 Exemplos de Controle de Visibilidade em Dom´ınios de Tupla . . . . . . . . 93
5.11 Exemplo de Defini¸c˜ao de Dom´ınios de Lista . . . . . . . . . . . . . . . . . 93
5.12 Exemplos de Defini¸c˜ao de Dom´ınios Funcionais . . . . . . . . . . . . . . . 94
5.13 Exemplo de Defini¸c˜ao de Dom´ınios de Lista . . . . . . . . . . . . . . . . . 94
5.14 Exemplo de Extens˜ao de Dom´ınios . . . . . . . . . . . . . . . . . . . . . . 95
5.15 Exemplo de Defini¸c˜ao de Fun¸c˜ao de Pr´e-processamento do Arquivo Fonte . 96
5.16 Exemplos de Defini¸c˜ao de Tokens e Macros . . . . . . . . . . . . . . . . . . 97
5.17 Exemplos do Uso de Cl´ausulas Ignore . . . . . . . . . . . . . . . . . . . . . 98
5.18 Exemplos de Extens˜ao de Tokens . . . . . . . . . . . . . . . . . . . . . . . 100
5.19 Exemplo de Equivalˆencia da Extens˜ao de Macros – Parte I . . . . . . . . . 100
5.20 Exemplo de Equivalˆencia da Extens˜ao de Macros – Parte II . . . . . . . . . 100
5.21 Exemplo de Defini¸c˜ao de Dom´ınio Sint´atico de Tokens . . . . . . . . . . . 101
5.22 Exemplos de Ambiguidades nas Defini¸c˜oes de Tokens . . . . . . . . . . . . 102
5.23 Exemplos de Visibilidade das Vari´aveis de uma Gram´atica . . . . . . . . . 103
5.24 Exemplos de Defini¸c˜ao de Regras de Produ¸c˜ao . . . . . . . . . . . . . . . . 103
5.25 Exemplos de Repeti¸c˜ao em Regras de Produ¸c˜ao . . . . . . . . . . . . . . . 105
5.26 Exemplo de Defini¸c˜ao do S´ımbolo de Partida de uma Linguagem . . . . . . 106
5.27 Exemplo de Defini¸c˜ao de Gram´atica Concreta Para Express˜oes . . . . . . . 107
5.28 Exemplo de Defini¸c˜ao Alternativa de Sintaxe Abstrata . . . . . . . . . . . 108
5.29 Exemplo do Uso de Decora¸c˜ao na Defini¸c˜ao de Gram´atica Concreta . . . . 110
5.30 Exemplo de Linguagem de Fun¸c˜oes c om M´ultiplos Argumentos . . . . . . . 110
5.31 Exemplo de Extens˜ao de Gram´atica . . . . . . . . . . . . . . . . . . . . . . 113
5.32 Exemplo de Declara¸c˜ao de Fun¸c˜ao . . . . . . . . . . . . . . . . . . . . . . . 113
5.33 Exemplos de Defini¸c˜ao de Fun¸c˜ao . . . . . . . . . . . . . . . . . . . . . . . 114
5.34 Exemplo de Programa na Linguagem L . . . . . . . . . . . . . . . . . . . . 116
5.35 Exemplo de Fun¸c˜ao de Pr´e-Processamento . . . . . . . . . . . . . . . . . . 117
LISTAGENS xxiii
5.36 Defini¸c˜ao da Fun¸c˜ao de Pr´e-Processamento . . . . . . . . . . . . . . . . . . 118
5.37 Programa correspondente ao programa da Listagem 5.34 (p´agina 116) a se r
lido pelo analisador l´exico . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
5.38 Exemplo de Fun¸c˜ao Semˆantica . . . . . . . . . . . . . . . . . . . . . . . . . 120
5.39 Exemplo de Padr˜oes Identificadores . . . . . . . . . . . . . . . . . . . . . . 121
5.40 Exemplos de Padr˜ao Tupla em Defini¸c˜oes de Fun¸c˜ao . . . . . . . . . . . . . 122
5.41 Exemplos de Padr˜oes de Listas . . . . . . . . . . . . . . . . . . . . . . . . 123
5.42 Exemplos de Uso de Pares Cabe¸ca e Cauda . . . . . . . . . . . . . . . . . . 123
5.43 Exemplos de Padr˜oes de Listas . . . . . . . . . . . . . . . . . . . . . . . . 123
5.44 Exemplo de Padr˜ao Para N´o de
´
Arvore de Sintaxe Abstrata . . . . . . . . 124
5.45 Exemplos de N´os de
´
Arvore de Sintaxe Abstrata . . . . . . . . . . . . . . . 132
5.46 Exemplo de Express˜ao de Casamento de Padr˜ao . . . . . . . . . . . . . . . 133
5.47 Exemplos de Express˜oes Let . . . . . . . . . . . . . . . . . . . . . . . . . . 135
5.48 Exemplos de Express˜oes Where . . . . . . . . . . . . . . . . . . . . . . . . 135
5.49 Exemplo de Atualiza¸c˜ao de Fun¸c˜ao . . . . . . . . . . . . . . . . . . . . . . 136
5.50 Exemplos de Express˜oes Condicionais . . . . . . . . . . . . . . . . . . . . . 137
B.1 Module Kernel of Nano Definition . . . . . . . . . . . . . . . . . . . . . . . 169
B.2 Module Expressions of Nano Definition . . . . . . . . . . . . . . . . . . . . 171
B.3 Module Commands of Nano Definition . . . . . . . . . . . . . . . . . . . . 172
B.4 Module Programs of Nano Definition . . . . . . . . . . . . . . . . . . . . . 172
B.5 Main Module of Nano Definition . . . . . . . . . . . . . . . . . . . . . . . . 172
B.6 Definition of the Kernel of Sek . . . . . . . . . . . . . . . . . . . . . . . . . 176
B.7 Definition of Sek Memory . . . . . . . . . . . . . . . . . . . . . . . . . . . 177
B.8 Definition of Variables in Sek . . . . . . . . . . . . . . . . . . . . . . . . . 178
B.9 Definition of Declarations in Sek . . . . . . . . . . . . . . . . . . . . . . . . 179
B.10 Definition of Expressions in Sek . . . . . . . . . . . . . . . . . . . . . . . . 180
B.11 Definition of Commands in Sek . . . . . . . . . . . . . . . . . . . . . . . . 181
xxiv LISTAGENS
B.12 Definition of Sequence Expressions in Sek . . . . . . . . . . . . . . . . . . . 182
B.13 Definition of Sequence Expressions in Sek . . . . . . . . . . . . . . . . . . . 184
B.14 Definition of Programs in Sek . . . . . . . . . . . . . . . . . . . . . . . . . 185
B.15 Main Module of Sek Definition . . . . . . . . . . . . . . . . . . . . . . . . . 185
B.16 Module Kernel in the Definition of Tiny . . . . . . . . . . . . . . . . . . . 187
B.17 Module Expressions in Tiny Definition . . . . . . . . . . . . . . . . . . . . 188
B.18 Module Arithmetics in Tiny Definition . . . . . . . . . . . . . . . . . . . . 190
B.19 Module Relationals in Tiny Definition . . . . . . . . . . . . . . . . . . . . . 191
B.20 Module Booleans in Tiny Definition . . . . . . . . . . . . . . . . . . . . . . 192
B.21 Module Commands in Tiny Specification . . . . . . . . . . . . . . . . . . . 193
B.22 Module Declarations in Tiny Definition . . . . . . . . . . . . . . . . . . . . 193
B.23 Module InputOutput in Tiny Definition . . . . . . . . . . . . . . . . . . . . 194
B.24 Module Variables in Tiny Definition . . . . . . . . . . . . . . . . . . . . . . 195
B.25 Module ControlFlow in Tiny Definition . . . . . . . . . . . . . . . . . . . . 197
B.26 Module Programs in Tiny Definition . . . . . . . . . . . . . . . . . . . . . 198
B.27 Main Module of Specification Tiny0 . . . . . . . . . . . . . . . . . . . . . . 198
B.28 Main Module of Specification Tiny1 . . . . . . . . . . . . . . . . . . . . . . 198
B.29 Transformer IncludeSequencer . . . . . . . . . . . . . . . . . . . . . . . . . 199
B.30 Module Sequencers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199
Cap´ıtulo 1
Introdu¸c˜ao
Apesar da grande disponibilidade de formas de defini¸c˜ao de semˆantica de linguagens de pro-
grama¸c˜ao e do seu amplo escopo de aplica¸c˜ao, o uso real dos diversos arcabou¸cos semˆanticos
´e ainda bastante reduzido. Segundo Mosses (2001), isto se deve principalmente `as dificul-
dades em se ler e escrever defini¸c˜oes semˆanticas e ao pequeno n´umero de ferramentas de
apoio para escrita e verifica¸c˜ao das especifica¸c˜oes, assim como para gera¸c˜ao autom´atica
de interpretadores e compiladores. Itens que tamb´em levam `a populariza¸c˜ao de um for-
malismo s˜ao a existˆencia de bibliotecas ricas, documenta¸c˜ao, defini¸c˜ao formal e suporte
ferramental.
De acordo com Zhang and Xu (2004), um formalismo popular para defini¸c˜ao semˆantica
deveria possuir como caracter´ısticas b´asicas: legibilidade, modularidade, existˆencia de re-
cursos adequados para abstra¸c˜ao, facilidade em realizar compara¸c˜oes entre linguagens,
elementos te´oricos que propiciem o racioc´ınio e a prova de propriedades, aplicabilidade, e
existˆencia de ferramentas de suporte.
Essas dificuldades ficam muito evidenciadas na defini¸c˜ao da semˆantica formal de lingua-
gens de grande porte, pois o n´umero de detalhes que devem ser tratados costuma ser t˜ao
grande que a tarefa de especifica¸c˜ao torna-se muito trabalhosa e sujeita a erros. Descri¸c˜oes
semˆanticas de linguagens de grande porte s˜ao inerentemente complexas devido ao grande
n´umero de detalhes entrela¸cados com que se deve lidar (Tirelo et al. 2009). Desta maneira,
´e desej´avel que tais especifica¸c˜oes sejam modulares e extens´ıveis, e possam ser escritas e
processadas de modo incremental, de forma que constru¸c˜oes possam ser sucessivamente
adicionadas `a defini¸c˜ao de uma linguagem base. Al´em disso, este processo incremental n˜ao
deve exigir a redefini¸c˜ao de m´odulos previamente definidos e, adicionalmente, deve requerer
1
2 CAP
´
ITULO 1. INTRODUC¸
˜
AO
por parte do projetista da linguagem apenas o uso de recursos simples.
No entanto, linguagens de programa¸c˜ao de grande porte usualmente s˜ao compostas por
constru¸c˜oes que nem sempre s˜ao ortogonais, e, para as quais, n˜ao ´e trivial escrever defini¸c˜oes
separadas. Um exemplo deste problema pode ser encontrado nas defini¸c˜oes de m´etodos e
tratamento de exce¸c˜oes em Java: para a defini¸c˜ao do comando return deve-se estar ciente de
poss´ıveis blocos finally que devem ser executados antes de restaurar o controle da execu¸c˜ao
para a fun¸c˜ao chamadora, seja por retorno normal ou via mecanismo de tratamento de
exce¸c˜oes. Al´em disso, como a semˆantica de um programa ´e produzida pelas equa¸c˜oes
semˆanticas de maneira top-down, cada constru¸c˜ao pode ser respons´avel por preparar o
contexto para seus poss´ıveis constituintes. Como consequˆencia, equa¸c˜oes semˆanticas s˜ao
n˜ao apenas respons´aveis por especificar o significado de constru¸c˜oes, mas tamb´em por
definir como tais constru¸c˜oes interagem.
Assim, para a defini¸c˜ao da intera¸c˜ao entre duas constru¸c˜oes, pelo menos uma das equa¸c˜oes
semˆanticas correspondentes deve estar ciente da existˆencia da outra. Por exemplo, o pro-
blema da ocorrˆencia de comandos return dentro de blocos try pode ser resolvido por meio
da redefini¸c˜ao da continua¸c˜ao associada ao sequenciador. Como nas abordagens tradicio-
nais para semˆantica denotacional (ver Cap´ıtulo 3) h´a um mapeamento de um para um das
constru¸c˜oes lingu´ısticas nas equa¸c˜oes semˆanticas, tais intera¸c˜oes necessariamente induzem
elementos entrela¸cados em pelo menos uma das equa¸c˜oes
1
.
Esta propriedade tem impacto direto na modularidade de defini¸c˜oes de s emˆantica denota-
cional de linguagem, uma vez que a descri¸c˜ao de uma constru¸c˜ao pode conter elementos
n˜ao relacionados, o que viola o princ´ıpio da alta coes˜ao (Meyer 1997). Al´em disso, a
defini¸c˜ao incremental de uma linguagem geralmente requer que m´odulos previamente de-
finidos sejam reescritos toda vez que alguma constru¸c˜ao ´e definida, tornando o processo
de escrita e reescrita tedioso e sujeito a erros. Do ponto de vista do leitor, informa¸c˜oes
cruciais a respeito da linguagem podem ser obscurecidas por diversos detalhes presentes
nas equa¸c˜oes semˆanticas, e, por isso, compreender completamente certas constru¸c˜oes pode
ser uma tarefa bastante complicada.
Por outro lado, em desenvolvimento de sistemas de software, altos n´ıveis de modularidade
em sistemas de grande porte tˆem sido alcan¸cados por meio da aplica¸c˜ao de t´ecnicas de
decomposi¸c˜ao aderentes `as necessidades dos sistemas desenvolvidos (Dijkstra 1976, Parnas
1
Isto ´e consequˆencia direta do pigeon-hole principle. Tal observa¸c˜ao n˜ao ´e verdadeira para sistemas
baseados em semˆantica operacional estruturada, pois mais de uma cl´ausula pode ser utilizada para definir
uma constru¸c˜ao.
3
1972, von Staa 2000). Nos ´ultimos anos, um importante avan¸co nas t´ecnicas de modula-
riza¸c˜ao foi obtido a partir das propostas de decomposi¸c˜ao multidimensional (Ossher and
Tarr 2000, 2001) e da orienta¸c˜ao por aspectos (Kiczales et al. 1997), pois ao se quebra-
rem as barreiras de uma ´unica forma de decomposi¸c˜ao dominante, foi poss´ıvel modularizar
elementos de projeto que n˜ao eram adequadamente tratados pelas t´ecnicas at´e ent˜ao uti-
lizadas.
O objetivo principal deste trabalho de doutorado ´e aperfei¸coar as t´ecnicas de de fini¸c˜ao
da semˆantica denotacional de linguagens de programa¸c˜ao, oferecendo meios apropriados
para tratamento dos elementos inerentes `as linguagens de grande porte que ainda s˜ao im-
pedimentos `a escrita de defini¸c˜oes modulares, em especial o entrela¸camento de equa¸c˜oes
decorrente da interdependˆencia de constru¸c˜oes. A t´ecnica proposta utiliza recursos da
orienta¸c˜ao por aspectos para melhoria do pro cesso de e scrita incremental da semˆantica
denotacional de linguagens de programa¸c˜ao, e se baseia em um recurso fundamental `a le-
gibilidade de defini¸c˜oes informais, a vagueza. Com efeito, ao se ensinar uma linguagem
de programa¸c˜ao, um professor apresenta inicialmente os conceitos fundamentais, sem se
preocupar com a forma como aqueles conceitos se relacionam com outros que ser˜ao posteri-
ormente definidos. Somente quando fizer sentido `a l´ogica de apresenta¸c˜ao dos conceitos tais
detalhes devem ser especificados. Entretanto, para a inclus˜ao de novos elementos, alguns
conceitos devem ser revisitados, sendo necess´aria a adapta¸c˜ao do que foi visto `a luz do que
ser´a apresentado, se m que isso necessariamente implique na sua redefini¸c˜ao completa.
Organiza¸c˜ao da Tese. O Cap´ıtulo 2 discute a modularidade de sistemas de software,
m´etricas de modularidade e alguns avan¸cos recentes na ´area. O Cap´ıtulo 3 apresenta as
solu¸c˜oes mais importantes para a defini¸c˜ao da semˆantica de linguagens de programa¸c˜ao
e para a modularidade de semˆantica denotacional. O Cap´ıtulo 4 apresenta a principal
contribui¸c˜ao deste trabalho, que ´e uma t´ecnica orientada por aspectos para a melhoria do
processo de defini¸c˜ao incremental da semˆantica denotacional de linguagens de programa¸c˜ao,
denominada Semˆantica Incremental. O Cap´ıtulo 5 apresenta a linguagem de especifica¸c˜ao
Notus, cujo objetivo ´e permitir a defini¸c˜ao incremental de uma linguagem de programa¸c˜ao,
incluindo elementos sint´aticos e semˆanticos. O Cap´ıtulo 6 apresenta uma avalia¸c˜ao do tra-
balho, de acordo com crit´erios previamente discutidos. Finalmente, o Cap´ıtulo 7 apresenta
as considera¸c˜oes finais.
4 CAP
´
ITULO 1. INTRODUC¸
˜
AO
Cap´ıtulo 2
Modularidade de Sistemas de
Software
Uma das qualidades mais importantes que se deseja alcan¸car na implementa¸c˜ao de um
sistema de software de grande porte ´e, junto com a corre¸c˜ao e a eficiˆencia, a sua mo dula-
ridade. Um m´odulo ´e um artefato de programa¸c˜ao que pode ser desenvolvido e compilado
separadamente de outras partes que comp˜oem o programa (Dijkstra 1976, Parnas 1972,
von Staa 2000). Ao possibilitar que se trate separadamente cada componente de um pro-
grama, a boa divis˜ao modular traz consigo a redu¸c˜ao dos seus custos de desenvolvimento e
manuten¸c˜ao. O m´odulo ´e um dos recursos mais importantes para quebrar a complexidade
inerente de sistemas de grande porte.
Especifica¸c˜oes de semˆantica formal de linguagens de grande porte s˜ao em geral bastante
complexas e apresentam diversos problemas de modularidade em fun¸c˜ao de limita¸c˜oes dos
modelos correntes. Neste cap´ıtulo, apresentam-se os principais conceitos de modularidade
de sistemas, que ser˜ao aplicados nos Cap´ıtulos 3 a 5 na modularidade de defini¸c˜oes de
semˆantica denotacional.
Organiza¸c˜ao do Cap´ıtulo. A Se¸c˜ao 2.1 apresenta um breve hist´orico das solu¸c˜oes mais
relevantes para modularidade de sistemas, e a Se¸c˜ao 2.2 apresenta as principais m´etricas
para se avaliar o grau de modularidade de um dado sistema. Em seguida, s˜ao descritos
na Se¸c˜ao 2.3 os principais conceitos da Programa¸c˜ao Orientada por Aspectos e como esta
metodologia p ermite melhorar a modularidade de sistemas de software; esta se¸c˜ao ´e uma
vers˜ao resumida de Tirelo et al. (2004). Finalmente, a Se¸c˜ao 2.4 apresenta as conclus˜oes
5
6 CAP
´
ITULO 2. MODULARIDADE DE SISTEMAS DE SOFTWARE
do cap´ıtulo.
2.1 Evolu¸c˜ao das T´ecnicas de Modularidade
Na programa¸c˜ao estruturada, a modulariza¸c˜ao se limita `a implementa¸c˜ao de abstra¸c˜oes
dos comandos e express˜oes (procedimentos e fun¸c˜oes) necess´arios `a realiza¸c˜ao de uma
tarefa. Com o advento da orienta¸c˜ao por objetos (Kay 1993, Meyer 1997, Nygaard and
Dahl 1981), pode-se obter um grau mais elevado de modulariza¸c˜ao, por ser poss´ıvel realizar
abstra¸c˜oes de estruturas de dados, tipos e de suas opera¸c˜oes por meio da implementa¸c˜ao de
interfaces. Al´em disso, com o polimorfismo (Cardelli and Wegner 1985), ´e poss´ıvel definir
comportamentos distintos para interface comuns a objetos relacionados, sem a necessidade
de permitir o acesso a elementos b´asicos da implementa¸c˜ao.
Desenvolvedores criam sistemas a partir de requisitos que podem ser classificados como re-
quisitos funcionais, que constituem o objetivo final do sistema, e requisitos n˜ao-funcionais,
que compreendem elementos espec´ıficos de projeto, muitas vezes sem rela¸c˜ao direta com
o problema em quest˜ao. Por exemplo, em um sistema de processamento de cart˜oes de
cr´edito, um requisito funcional ´e o processamento de pagamentos, ao passo que a gera¸c˜ao
de registro de opera¸c˜oes (logging), a garantia de integridade de transa¸c˜oes, a autentica¸c˜ao
de servi¸cos, a seguran¸ca e o desempenho s˜ao requisitos n˜ao-funcionais.
Ao permitir codificar os objetos do problema em quest˜ao, a orienta¸c ˜ao por objetos permite
a boa modulariza¸c˜ao dos requisitos funcionais do sistema (Meyer 1997). No entanto,
um problema que este modelo n˜ao ´e capaz de resolver adequadamente est´a relacionado
`a modulariza¸c˜ao de requisitos n˜ao-mape´aveis diretamente em uma ou poucas classes de
um sistema, pois estes tendem a se espalhar por todo o c´odigo do programa (Kiczales
and Hilsdale 2001, Kiczales et al. 1997) e, por esta raz˜ao, s˜ao denominados preocupa¸c˜oes
ortogonais.
A Programa¸c˜ao Orientada por Aspec tos foi desenvolvida por Kiczales et al. (1997) a partir
da constata¸c˜ao de que certos requisitos n˜ao se encaixam em um ´unico m´odulo de programa,
ou pelo menos em um pequeno conjunto de m´odulos altamente relacionados. Em sistemas
orientados por objetos, a unidade de modulariza¸c˜ao ´e a classe, e as preocupa¸c˜oes ortogonais
se espalham por m´ultiplas classes.
A Separa¸c˜ao Multidimensional de Preocupa¸c˜oes, proposta por Ossher and Tarr (2000,
2001), foi desenvolvida a partir da observa¸c ˜ao de que a boa decomposi¸c˜ao dos requisitos
2.2. M
´
ETRICAS DE MODULARIDADE 7
de sistema exige que mais de uma forma de decomposi¸c˜ao seja utilizada. Na terminologia
utilizada, diz-se que os requisitos do sistema formam um espa¸co multidimensional, em
que cada requisito ocupa uma dimens˜ao; em sua dimens˜ao, um requisito pode evoluir
de maneira indepe ndente dos demais. Entretanto, ao se utilizar um ´unico mecanismo de
decomposi¸c˜ao, torna-se necess´ario adaptar o projeto de um requisito aos processos previstos
pela t´ecnica utilizada. Assim, nessa metodologia, cada requisito ´e decomposto utilizando-
se a t´ecnica que for mais conveniente e, no fim, definem- se regras de composi¸c˜ao, cujo
objetivo ´e integrar os m´odulos dese nvolvidos independentemente.
2.2 M´etricas de Modularidade
Para se avaliar o grau de modularidade de um s istema, utilizam-se m´etricas como coes˜ao,
conectividade e acoplamento, de scritos a seguir.
Coes˜ao Modular. A coes˜ao modular ´e uma medida do grau de relacionamento entre
os constituintes de um m´odulo, tal que um m´odulo ´e coeso se os seus elementos forem
fortemente relacionados. A coes˜ao de um m´odulo pode ser medida de acordo com os n´ıveis
mostrados na Tabela 2.1, segundo a divis˜ao feita por Myers (1975), sendo o maior grau de
coes˜ao o funcional, e o menor, o coincidental. Geralmente ´e mais f´acil fazer manuten¸c˜ao
em um m´odulo coeso, al´em de ser mais f´acil reutiliz´a-lo e m sistemas diferentes daquele no
qual tenha sido primeiramente implementado.
Conectividade e Acoplamento de M´odulos. A conectividade de um sistema ´e uma
medida do n´umero de rela¸c˜oes que h´a entre os seus m´odulos, sendo desej´avel que o n´umero
de conex˜oes seja o menor poss´ıvel. Uma forma intuitiva de compreender a conectividade
consiste em modelar um sistema por meio de um grafo, cujos v´ertices s˜ao seus m´odulos,
e cada aresta indica se h´a comunica¸c˜ao entre os m´odulos representados por suas extre-
midades. O grau de conectividade do sistema est´a relacionado `a densidade de arestas do
grafo correspondente. Assim, se este grafo for esparso, diz-se que o sistema possui baixa
conectividade, ao passo que, se o grafo for dens o, ent˜ao o sistema possui alta conectividade.
O acoplamento por sua vez ´e uma medida da complexidade de uma conex˜ao entre m´odulos,
servindo como medida do grau de independˆencia entre os m´odulos de um sistema. Assim
como se deseja que o n´umero de conex˜oes seja o menor poss´ıvel, espera-se, em um sistema
modular, que as conex˜oes entre os m´odulos sejam t˜ao fracas quanto poss´ıvel. Segundo
8 CAP
´
ITULO 2. MODULARIDADE DE SISTEMAS DE SOFTWARE
Classifica¸c˜ao Caracter´ısticas
funcional o m´odulo realiza uma e exatamente uma fun¸c˜ao
informacional o m´odulo implementa um tipo abstrato de dados
comunicacional as a¸c˜oes do m´odulo s˜ao dependentes de dados comuns
procedimental as a¸c˜oes do m´odulo est˜ao relacionadas `a resolu¸c˜ao de um pro-
blema e existe uma ordem espec´ıfica de execu¸c˜ao
cl´assica as a¸c˜oes do m´odulo operam sobre dados diferentes e existe uma
ordem de execu¸c˜ao pr´e-definida
l´ogica o m´odulo possui mais de uma a¸c˜ao a ser selecionada pelo usu´ario
por meio de parˆametros para uma a¸c˜ao seletora
coincidental as a¸c˜oes de um m´odulo n˜ao possuem rela¸c˜ao entre si
Tabela 2.1: N´ıveis de Coes˜ao Modular
Myers (1975), o acoplamento pode ser dividido nos n´ıveis mostrados na Tabela 2.2, sendo
prefer´ıvel que dois m´odulos sejam desacoplados. A presen¸ca de conex˜ao entre dois m´odulos
tem impacto direto no custo de manuten¸c˜ao, uma vez que, ao se alterar um m´odulo, pode
ser necess´ario fazer adapta¸c˜oes nos m´odulos com que ele se relaciona. A probabilidade
de ser necess´ario ajustar um m´odulo em raz˜ao da modifica¸c˜ao em outro est´a diretamente
relacionada ao grau de dependˆencia entre os dois.
2.3 Programa¸c˜ao Orientada por Aspectos
Especifica¸c˜oes da semˆantica denotacional de linguagens de programa¸c˜ao apresentam muitos
problemas de modularidade em fun¸c˜ao do entrela¸camento de conceitos expressos em suas
equa¸c˜oes semˆanticas, que n˜ao podem ser plenamente resolvidos pelas t´ecnicas correntes,
apresentadas no Cap´ıtulo 3.
Neste contexto, a Programa¸c˜ao Orientada por Aspectos, definida por Kiczales et al. (1997),
oferece novos recursos para modulariza¸c˜ao de sistemas que podem ser aplicados `a estru-
tura¸c˜ao de defini¸c˜oes de semˆantica denotacional. A sua apresenta¸c˜ao neste cap´ıtulo ser´a
baseada na plataforma orientada por objetos, onde ´e mais comumente utilizada, para pro-
ver o arcabou¸co necess´ario para o entendimento da t´ecnica e sua aplica¸c˜ao no ambiente
denotacional.
2.3. PROGRAMAC¸
˜
AO ORIENTADA POR ASPECTOS 9
Classifica¸c˜ao Caracter´ısticas
desacoplados n˜ao h´a comuni¸c˜ao entre os m´odulos, isto ´e, eles s˜ao completa-
mente independentes
por informa¸c˜ao a comunica¸c˜ao entre m´odulos ´e feita por meio de chamadas de
fun¸c˜oes com parˆametros passados por valor
por referˆencia a comunica¸c˜ao entre os m´odulos ´e realizada por meio de cha-
madas de fun¸c˜oes com parˆametros passados por referˆencia
por controle um m´odulo deve conhecer a estrutura de outro, ou ent˜ao passar
um parˆametro para uma de suas opera¸c˜oes com o objetivo de
controlar o seu fluxo de execu¸c˜ao
por dado externo os m´odulos tˆem acesso a um conjunto comum de dados, sem
que a altera¸c˜ao destes dados afete todos os m´odulos envolvidos
por dado comum os m´odulos tˆem acesso a um conjunto c omum de dados, e a
altera¸c˜ao de algum destes dados afetar todos os m´odulos envol-
vidos
por conte´udo um m´odulo acessa de forma direta, mas n˜ao autorizada, dados
n˜ao exportados por outro
Tabela 2.2: N´ıveis de Acoplamento entre M´odulos
10 CAP
´
ITULO 2. MODULARIDADE DE SISTEMAS DE SOFTWARE
A programa¸c˜ao orientada por aspectos tem por objetivo oferecer meios para a modula-
riza¸c˜ao de demandas do sistema que n˜ao podem ser adequadamente mo dularizadas utili-
zando as t´ecnicas de decomposi¸c˜ao vigentes, em particular, a orienta¸c˜ao por objetos. Tais
demandas s˜ao denominadas preocupa¸c˜oes ortogonais (Kiczales et al. 1997). Por estar espa-
lhado e m diversos m´odulos do sistema, torna-se dif´ıcil conceber, implementar e modificar
c´odigo relacionado `a implementa¸c˜ao de uma preocupa¸c˜ao ortogonal. Essa dificuldade ´e
exemplificada na classe definida na Listagem 2.1, extra´ıda de Gradecki and Lesieck (2003).
Nesse c´odigo, alguns problemas podem ser identificados: a parte “Outros dados membros”
(linha 4) n˜ao se refere ao objetivo principal da classe; o m´etodo performSomeOp eration
(linhas 8–17) faz mais opera¸c˜oes do que realizar a opera¸c˜ao objetivo: registra e autentica a
opera¸c˜ao, sincroniza threads, valida contrato e gerencia cache; n˜ao ´e claro se as opera¸c˜oes
save e load (linhas 21 e 22), que realizam a gerˆencia de persistˆencia, fazem parte do objetivo
principal da classe.
Outro problema ´e que a modifica¸c˜ao em alguns dos requisitos, como a altera¸c˜ao da pol´ıtica
de registro de opera¸c˜oes, pode originar modifica¸c˜oes em diversas partes do programa, o
que ´e uma tarefa desagrad´avel e propensa a erros.
Assim, a orienta¸c˜ao por aspectos preocupa-se com duas formas de manifesta¸c˜ao da falta
de modularidade de um sistema: espalhamento e intrus˜ao.
Espalhamento (scattering) diz respeito a c´odigo para implementa¸c˜ao de preocupa¸c˜oes or-
togonais estar disperso no programa; por exemplo, o c´odigo de gera¸c˜ao de registro de
opera¸c˜oes ou o c´odigo para verificar coerˆencia de cache tende a ficar distribu´ıdo ao longo
de toda a implementa¸c˜ao. O espalhamento apresenta como principal desvantagem o fato
de a preocupa¸c˜ao ortogonal n˜ao poder ser encapsulada em uma unidade modular, al´em do
seu impacto direto na conectividade do sistema.
Intrus˜ao (tangling) diz respeito `a confus˜ao gerada por c´odigos de mais de uma preocupa¸c˜ao
ortogonal estarem presentes em uma ´unica regi˜ao do programa, como o corre no m´etodo
performSomeOperation da Listagem 2.1. A intrus˜ao tem impacto direto na coes˜ao de um
m´odulo uma vez que este cont´em, al´em do tratamento de seu objetivo principal, trechos
de c´odigo respons´aveis pelo tratamento de algum outro requisito a que seja transversal.
Segundo Gradecki and Lesieck (2003), as implica¸c˜oes desses problemas s˜ao diversas. Pri-
meiramente, observa-se dificuldade em se fazer o rastreamento do programa, pois a im-
plementa¸c˜ao simultˆanea de v´arios requisitos em um ´unico m´etodo torna obscura a cor-
respondˆencia entre os requisitos e suas implementa¸c˜oes, resultando em um mapeamento
2.3. PROGRAMAC¸
˜
AO ORIENTADA POR ASPECTOS 11
1 public class SomeBusinessClass extends OtherBusinessClass {
2
3 ”Dados membros do m´odulo”
4 ”Outros dados membros: stream de logging, flag de consistˆencia de dados”
5
6 ”M´etodos redefinidos da superclasse ”
7
8 public void performSomeOperation(OperationInformation info) {
9 ”Garante autenticidade ”
10 ”Garante que info satisfa¸ca contrato”
11 ”Bloqueia o objeto para garantir consistˆencia caso outras threads o acessem”
12 ”Garante que a cache est´a atualizada ”
13 ”Faz o logging do in´ıcio da opera¸c˜ao”
14 ”REALIZA A OPERAC¸
˜
AO OBJETIVO”
15 ”Faz o logging do fim da opera¸c˜ao”
16 ”Desbloqueia o objeto”
17 }
18
19 ”Outras opera¸c˜oes semelhantes `a anterior ”
20
21 public void save( PersistenceStorage ps) { ” ... ” }
22 public void load( PersistenceStorage ps) { ” ... ” }
23
24 }
Listagem 2.1: Exemplo de Entrela¸camento de C´odigo – Extra´ıdo de Gradecki and Lesieck
(2003)
12 CAP
´
ITULO 2. MODULARIDADE DE SISTEMAS DE SOFTWARE
pobre entre os dois.
Al´em disso, obt´em-se baixa produtividade, pois a implementa¸c˜ao simultˆanea de v´arias pre-
ocupa¸c˜oes em um m´odulo pode desviar a aten¸c˜ao do desenvolvedor do objetivo principal
para os perif´ericos, levando `a ocorrˆencia constante de erros. Outro ponto importante ´e que
esse modelo possui baixo grau de re´uso, pois, dado que um ´unico m´odulo implementa v´arias
preocupa¸c˜oes, outros sistemas que precisarem de implementar funcionalidades semelhantes
podem n˜ao ser capazes de utilizar prontamente os m´odulos correspondentes, diminuindo
ainda mais a produtividade do desenvolvedor.
Por esses pontos, pode-se perceber que o c´odigo apresenta pouca qualidade interna, com
baixa coes˜ao modular e alto grau de acoplamento de m´odulos, e com poss´ıveis problemas
ocultos, pois ao se lidar com diversas preocupa¸c˜oes ao mesmo tempo, o desenvolvedor pode
n˜ao dar aten¸c˜ao suficiente a uma ou mais preocupa¸c˜oes.
Todos estes problemas levam `a produ¸c˜ao de c´odigo de dif´ıcil evolu¸c˜ao ou baixa extensibi-
lidade (Meyer 1997), visto que modifica¸c˜oes posteriores no sistema podem ser dificultadas
pela pouca modulariza¸c˜ao. Por exemplo, modifica¸c˜oes na pol´ıtica de consistˆencia da cache
ou na pol´ıtica de valida¸c˜ao de contratos podem levar `a reorganiza¸c˜ao de diversos m´odulos
de um sistema.
2.3.1 Metodologia de Desenvolvimento
Segundo Gradecki and Lesieck (2003), o desenvolvimento de software orientado por as-
pectos ´e realizado em trˆes fases: a decomposi¸c˜ao, a implementa¸c˜ao e a recomposi¸c˜ao de
requisitos.
A decomposi¸c˜ao de preocupa¸c˜oes consiste na separa¸c˜ao das preocupa¸c˜oes ortogonais dos
requisitos funcionais do sistema. No exemplo da classe SomeBusinessClass da Se¸c˜ao 2.3,
pode-se identificar as seguintes preocupa¸c˜oes ortogonais `a opera¸c˜ao objetivo: autentica¸c˜ao
e registro de opera¸c˜ao, s incroniza¸c˜ao de threads, valida¸c˜ao de contrato, coerˆencia de cache
e persistˆencia. A opera¸c˜ao objetivo deve ser implementada na classe; todas as demais
preocupa¸c˜oes devem ser implementadas em outros m´odulos.
Segundo Atkinson and K¨uhne (2003), preocupa¸c˜oes ortogonais s˜ao classificadas em infra-
estrutura, de servi¸cos e de paradigmas. Preocupa¸c˜oes de infra-estrutura s˜ao respons´aveis
por coordena¸c˜ao (escalonamento e sincroniza¸c˜ao), distribui¸c˜ao (tolerˆancia a falhas, comu-
nica¸c˜ao, serializa¸c˜ao e replica¸c˜ao) e persistˆencia. Preocupa¸c˜oes de servi¸cos s˜ao represen-
2.3. PROGRAMAC¸
˜
AO ORIENTADA POR ASPECTOS 13
tadas por seguran¸ca, recupera¸c˜ao de erros, opera¸c˜oes de retrocesso (undo), rastreamento
e registro de opera¸c˜oes. Exemplos de preocupa¸c˜oes de paradigma s ˜ao os padr˜oes visitor e
observer descritos por Gamma et al. (1995).
Ap´os a decomposi¸c˜ao, realiza-se a implementa¸c˜ao em separado. No exemplo da classe Some-
BusinessClass, deve-se implementar as unidades de l´ogica do neg´ocio, registro de opera¸c˜oes,
autoriza¸c˜ao, e ntre outros, em m´odulos separados. Para a implementa¸c˜ao de cada m´odulo,
utilizam-se os recursos da programa¸c˜ao orientada por objetos padr˜ao. Por exemplo, a
gera¸c˜ao de registro de opera¸c˜oes pode ser feita por meio da implementa¸c˜ao de classes e
interfaces espec´ıficas para o problema, possivelmente organizadas por meio de padr˜ao de
projetos.
Ap´os a implementa¸c˜ao separada de cada preocupa¸c˜ao, especificam-se as regras de recom-
posi¸c˜ao do sistema. Estas regras s˜ao implementadas em m´odulos denominados aspectos.
Os aspectos definem como as preocupa¸c˜oes s ˜ao compostas para formar o sistema, em um
processo de nominado costura (weaving). Ainda no exemplo da classe SomeBusinessClass, um
aspecto pode conter regras que definem os pontos do programa onde chamadas de m´etodos
de registro de opera¸c˜oes devem ser inseridas.
2.3.2 Linguagens Orientadas por Aspectos
Algumas linguagens e arcabou¸cos de desenvolvimento permitem a implementa¸c˜ao de pro-
gramas orientados por aspectos, dentre eles, destacam-se as implementa¸c˜oes para as lin-
guagens: Java, representada por AspectJ (Kiczales et al. 2001), Hyper/J (Ossher and
Tarr 2000, 2001) e AspectWerkz (AspectWerks 2005); C++, com a implementa¸c˜ao de As-
pectC++ (Spinczyk et al. 2002); C, com a implementa¸c˜ao de AspectC (Coady et al. 2001);
C#, com as linguagens AspectC# (Kim 2002) e Eos (Rajan and Sullivan 2003, 2005).
Existem tamb´em propostas para a AOP independente de linguagem (Lafferty and Cahill
2003).
A proposta original de programa¸c˜ao orientada por aspectos feita por Kiczales et al. (1997)
utiliza uma extens˜ao da linguagem funcional Scheme como linguagem hospedeira. Ainda
no paradigma funcional, podem- se citar a implementa¸c˜ao de AspectH, para a linguagem
Haskell feita por Andrade et al. (2004), e a implementa¸c˜ao de Tucker and Krishnamurthi
(2003) para a linguagem Scheme. Destaca-se tamb´em o trabalho de L¨ammel (1999), no
qual se prop˜oe uma t´ecnica geral de compila¸c˜ao para linguagens funcionais orientadas por
aspectos.
14 CAP
´
ITULO 2. MODULARIDADE DE SISTEMAS DE SOFTWARE
As linguagens orientadas por aspectos oferecem recursos para resolu¸c˜ao de dois problemas
de entrela¸camento de c´odigo: a transversalidade dinˆamica, que permite definir implemen-
ta¸c˜ao adicional em pontos bem definidos da execu¸c˜ao do programa, e a transversalidade
est´atica, que afeta as assinaturas dos tipos de um programa. Nesta se¸c˜ao, optou-se por
mostrar os principais conceitos de orienta¸c˜ao por aspectos, sem detalhar as diversas possi-
bilidades e recursos oferecidos. Para maior detalhamento, sugerem-se: Tirelo et al. (2004);
Kiczales et al. (2001); Laddad (2003); e Gradecki and Lesieck (2003).
2.3.2.1 Transversalidade Dinˆamica
Na transversalidade dinˆamica, pontos de jun¸c˜ao (joinpoints) s˜ao definidos como pontos
da execu¸c˜ao do programa. Exemplos de pontos de jun¸c˜ao s˜ao as chamadas de m´etodos e
de construtores de uma classe. Associados aos pontos de jun¸c˜ao mais dois conceitos s˜ao
importantes: conjuntos de jun¸c˜ao e regras de jun¸c˜ao.
As constru¸c˜oes do programa que contˆem pontos de jun¸c˜ao s˜ao denominadas conjuntos de
jun¸c˜ao (pointcuts) e tˆem a fun¸c˜ao de reunir informa¸c˜oes a respeito do contexto destes
pontos. Os c´odigos relativos aos requisitos transversais que devem se r executados em
pontos de jun¸c˜ao s˜ao denominados adendos (advices).
Linguagens orientadas por aspectos possuem como ele mentos b´asicos: um modelo de de-
fini¸c˜ao de pontos de jun¸c˜ao, uma forma de identificar pontos de jun¸c˜ao, isto ´e, definir
conjuntos de jun¸c˜ao, e uma forma de interferir na execu¸c˜ao de pontos de jun¸c˜ao. Estes
elementos s˜ao encapsulados em m´odulos denominados aspectos, que podem ser definidos
como unidades de imple menta¸c˜ao modular das regras de recomposi¸c˜ao do sistema e contˆem
defini¸c˜oes de conjuntos de jun¸c˜ao e adendos.
Considere, por exemplo, a defini¸c˜ao em AspectJ do aspecto LoggingAspect da Listagem
2.2,
que define os seguintes conjuntos de jun¸c˜ao:
• publicMethods: engloba os pontos de jun¸c˜ao de execu¸c˜ao dos m´etodos p´ublicos do
programa;
• logObjectCalls: engloba os pontos de jun¸c˜ao de execu¸c˜ao dos m´etodos da classe Logger;
• loggableCalls: engloba os pontos de jun¸c˜ao de execu¸c˜ao dos m´etodos p´ublicos do pro-
grama que n˜ao perten¸cam `a classe Logger.
2.3. PROGRAMAC¸
˜
AO ORIENTADA POR ASPECTOS 15
1 public aspect LoggingAspect {
2
3 pointcut publicMethods(): execution(public ∗ ∗(..));
4 pointcut logObjectCalls () : execution(∗ Logger .∗(..));
5 pointcut loggableCalls () : publicMethods() && ! logObjectCalls ();
6
7 before(): loggableCalls () {
8 Logger.logEntry(thisJoinPoint.getSignature (). toString ());
9 }
10
11 after (): loggableCalls () {
12 Logger. logExit (thisJoinPoint.getSignature (). toString ());
13 }
14
15 }
Listagem 2.2: Aspecto Para Logging
S˜ao tamb´em definidos os adendos before e after, contendo os c´odigos para serem executados
antes e depois das execu¸c˜oes dos m´etodos identificados nos conjuntos de jun¸c˜ao indicados.
Na regra before, define- se o c´odigo a ser executado antes da execu¸c˜ao dos m´etodos p´ublicos,
que corresponde `a gera¸c˜ao do registro de entrada no m´etodo; este c´odigo corresponde `a
chamada do m´etodo doEntry da classe Logger, passando-lhe a assinatura do ponto de jun¸c˜ao
1
.
Da mesma forma, na regra after, define-se o c´odigo a ser executado ap´os a execu¸c˜ao dos
m´etodos p´ublicos, que corresponde `a gera¸c˜ao do registro de sa´ıda do m´etodo.
2.3.2.2 Transversalidade Est´atica
Algumas implementa¸c˜oes de aspectos, como por exemplo a impleme nta¸c˜ao de padr˜oes de
projeto (Gamma et al. 1995, Hannemann and Kiczales 2002), necessitam de recursos para
alterar tanto o comportamento das classes em tempo de execu¸c˜ao, quanto a sua estrutura
est´atica.
A transversalidade dinˆamica, obtida a partir de adendos, permite modificar o comporta-
mento da execu¸c˜ao do programa, ao passo que a transversalidade est´atica permite redefinir
1
A express˜ao thisJoinPoint.getSignature().toString() obt´em uma cadeia de caracteres que corresp onde `a assi-
natura do m´etodo que cont´em o ponto de jun¸c˜ao ao qual a regra se aplica (thisJoinPoint)
16 CAP
´
ITULO 2. MODULARIDADE DE SISTEMAS DE SOFTWARE
a estrutura est´atica dos tip os – classes, interfaces ou outras estruturas – e o seu com-
portamento em tempo de execu¸c˜ao. Dentre os recursos mais importantes de linguagens
orientadas por aspectos, destacam-se modifica¸c˜ao da hierarquia de tipos e introdu¸c˜ao de
campos e m´etodos em classes e interfaces de forma transversal.
2.3.3 Aplica¸c˜oes
Nesta se¸c˜ao s˜ao apresentados como exemplos de aplica¸c˜ao as implementa¸c˜oes dos padr˜oes
de projeto Observador e Wormhole.
2.3.3.1 Padr˜ao de Projetos Observador
O padr˜ao de projeto observador tem por objetivo definir uma dependˆencia de um para
muitos entre obj etos, de modo que, quando o estado de um objeto for alterado, todos os
seus dependentes ser˜ao notificados e atualizados automaticamente (Gamma et al. 1995).
O padr˜ao observador ´e utilizado para desacoplar o objeto alvo de observa¸c˜ao de seus
observadores, permitindo maior grau de re´uso. Por exemplo, em bibliotecas de implemen-
ta¸c˜ao de interfaces gr´aficas com o usu´ario, os objetos alvo de observa¸c˜ao s˜ao componentes
de interface e os observadores s˜ao respons´aveis pela realiza¸c˜ao das opera¸c˜oes de tratamento
da manipula¸c˜ao da interface pelo usu´ario. Uma das aplica¸c˜oes do padr˜ao observador ´e a
separa¸c˜ao entre dados e apresenta¸c˜ao.
A implementa¸c˜ao do padr˜ao observador por meio de linguagens orientadas por objetos
puras, como a sugerida por Gamma et al. (1995), apresenta problemas de modulariza¸c˜ao,
devido a c´odigo de atualiza¸c˜ao dos observadores estar espalhado ao longo do c´odigo dos
objetos observados. Nesta se¸c˜ao, apresenta-se uma implementa¸c˜ao do padr˜ao observador
utilizando a linguagem AspectJ. A implementa¸c˜ao por meio de aspec tos para e ste padr˜ao
foi adaptada da solu¸c˜ao proposta por Hannemann and Kiczales (2002).
O aspecto abstrato ObserverProtocol, definido na Listagem 2.3, ´e respons´avel por mapear
objetos em seus observadores.
Este aspecto possui os seguintes elementos:
• as interfaces Subject e Observer representam, respectivamente, um objeto alvo de ob-
serva¸c˜ao, doravante denominado alvo, e um observador; estas interfaces s˜ao utilizadas
para consistˆencias de tipos nos demais elementos do aspecto;
2.3. PROGRAMAC¸
˜
AO ORIENTADA POR ASPECTOS 17
1 import java. util .∗;
2
3 public abstract aspect ObserverProtocol {
4 public interface Subject {}
5 public interface Observer {}
6 private WeakHashMap perSubjectObservers;
7 private List getObservers(Subject s) {
8 if (p e rSubjectObservers == null)
9 perSubjectObservers = new WeakHashMap();
10 List observers = (List) perSubjectObservers.get(s );
11 if ( observers == null) {
12 observers = new LinkedList();
13 perSubjectObservers.put(s , observers );
14 }
15 return observe rs ;
16 }
17 public void addObserver(Subject s , Observer o) {
18 getObservers(s ). add(o);
19 updateObserver(s,o);
20 }
21 public void removeObserver(Subject s, Observer o) {
22 getObservers(s ). remove(o);
23 }
24 abstract public pointcut subjectChange(Subject s );
25 abstract public void updateObserver(Subject s , Observer o);
26 after(Subject s ): subjectChange(s) {
27 Iterator it = getObservers(s). iterator ();
28 while ( it .hasNext())
29 updateObserver(s, (Observer) it .next ());
30 }
31 }
Listagem 2.3: Protocolo Para o Padr˜ao de Projetos Observador
18 CAP
´
ITULO 2. MODULARIDADE DE SISTEMAS DE SOFTWARE
• o mapeamento perSubjectObservers ´e respons´avel por armazenar as listas de observa-
dores de cada alvo;
• os m´etodos addObserver e removeObserver s˜ao respons´aveis por adicionar e remover um
observador da lista de observadores de um alvo, respectivamente;
• o m´etodo getObserver ´e respons´avel por retornar a lista de observadores de um alvo,
armazenada na tabela perSubjectObservers; ´e respons´avel tamb´em por criar uma nova
lista vazia e associ´a-la a um alvo, caso este ainda n˜ao esteja cadastrado na tabela;
• o conjunto de jun¸c˜ao abstrato subjectChange deve ser redefinido nos subaspectos de
ObserverProtocol; nos subaspectos, ele define os m´etodos respons´aveis por alterar o
estado interno dos objetos observados (ver aspecto TemperatureObservation, definido a
seguir);
• o m´etodo abstrato updateObserver deve ser redefinido nos subaspectos, de modo que
defina as a¸c˜oes de notifica¸c˜ao dos observadores quando o estado interno do sujeito
for alterado;
• a regra after definida para o conjunto de jun¸c˜ao subjectChange ´e respons´avel por obter
a lista de observadores de um alvo e chamar o m´etodo de notifica¸c˜ao para cada
observador; este c´odigo ´e inclu´ıdo ap´os cada ponto de jun¸c˜ao que represente uma
mudan¸ca de estado do objeto alvo.
Para implementar o padr˜ao observador utilizando aspectos, deve-se definir: (i) os objetos
alvo de observa¸c˜ao; (ii) os objetos observadores; (iii) as opera¸c˜oes dos alvos que definem
as altera¸c˜oes do estado interno; (iv) o algoritmo de atualiza¸c˜ao de cada observador; (v) os
momentos em que a observa¸c˜ao sobre um alvo inicia e termina.
Para definir que uma classe ´e observadora de outra, deve-se implementar um aspecto que
estenda ObserverProtocol e que defina o conjunto de jun¸c˜ao de modifica¸c˜ao do estado interno
e o m´etodo de notifica¸c˜ao de observadores.
Considere, por exemplo, as classes Termometer e Temperature definidas nas Listagens 2.4 e 2.5,
respectivamente.
O aspecto Te mperatureObservation, mostrado na Listagem 2.6, estende o aspecto ObserverPro-
tocol, definindo que Te rmome ter implementa a interface Observer, Temperature implementa a
interface Subject. Define-se tamb´em que o conjunto de jun¸c˜ao subjectChange representa
2.3. PROGRAMAC¸
˜
AO ORIENTADA POR ASPECTOS 19
1 public abstract class Termome ter {
2 public abstract void printTemperature(double value);
3 }
Listagem 2.4: Classe Termometer
1 public class Temperature {
2 private double value;
3 public Temperature(double initialValue ) {
4 value = initialValue ;
5 }
6 public double getValue() {
7 return value;
8 }
9 public void setValue(double value) {
10 this . value = value;
11 }
12 }
Listagem 2.5: Classe Temperature
20 CAP
´
ITULO 2. MODULARIDADE DE SISTEMAS DE SOFTWARE
1 public aspect TemperatureObservation extends ObserverProtocol {
2
3 declare parents : Temperature implements Subject;
4 declare parents : Termometer implements Observer;
5
6 public pointcut subjectChange(Subject s)
7 : target(s) && execution(void Temperature.setValue(double));
8
9 public void updateObserver(Subject s, Observer o) {
10 Temperature temperature = (Temperature) s;
11 Termometer termometer = (Termometer) o;
12 termometer.printTemperature(temperature.getValue());
13 }
14
15 }
Listagem 2.6: Aspecto Para Observa¸c˜ao de Temperatura
1 public class TermometerCelsius extends Termometer {
2 public void printTemperature(double value) {
3 System.out. println (” Celsius : ” + value);
4 }
5 }
Listagem 2.7: Classe TermometerCelsius
todas as execu¸c˜oes do m´etodo Temperature.setValue(), e que a notifica¸c˜ao dos observa-
dores ´e feita por meio da chamada do m´etodo de impress˜ao da temperatura, Termome-
ter.printTemperature().
A seguir, definem-se duas subclasses de Termometer: TermometerCelsius (Listagem 2.7) e
TermometerFahrenheit (Listagem 2.8).
Para associar uma instˆancia de uma classe termˆometro como observadora de uma ins-
tˆancia de temperatura, utiliza-se o m´etodo addObserver do aspecto, como mostrado na
Listagem 2.9.
O m´etodo aspectOf ´e utilizado para referenciar a instˆancia ´unica de um aspecto.
As principais vantagens da abordagem s˜ao:
2.3. PROGRAMAC¸
˜
AO ORIENTADA POR ASPECTOS 21
1 public class TermometerFahrenheit extends Termometer {
2 public void printTemperature(double value) {
3 System.out. println (”Fahrenheit: ” + value);
4 }
5 }
Listagem 2.8: Classe TermometerFahrenheit
1 TermometerCelsius term1 = new TermometerCelsius();
2 TermometerFahrenheit term2 = new TermometerFahrenheit();
3 TemperatureObservation.aspectOf().addObserver(t,term1);
4 TemperatureObservation.aspectOf().addObserver(t,term2);
Listagem 2.9: Exemplo do Uso do Protocolo de Observa¸c ˜ao
• a modulariza¸c˜ao completa do padr˜ao: foram retirados das classes do objeto observado
e do observador os c´odigos necess´arios para implementa¸c˜ao do padr˜ao observador;
• aumento do grau de re´uso do padr˜ao: pode-se definir de maneira n˜ao-intrusiva qual-
quer classe como observador ou alvo de observa¸c˜ao, definindo-se somente um aspecto
que implemente o respectivo protocolo de observa¸c˜ao.
2.3.3.2 Padr˜ao de Projetos Wormhole
Considere o conjunto de classes ilustrado na Figura 2.1, em que uma chamada t´ıpica de
opera¸c˜ao gera a execu¸c˜ao de diversas opera¸c˜oes secund´arias, representadas na forma do
grafo da Figura 2.2. A implementa¸c˜ao por meio de aspectos para este padr˜ao foi adaptada
da solu¸c˜ao apresentada em Gradecki and Lesieck (2003).
Se um objeto Worker precisar de informa¸c˜oes a respeito do contexto do objeto Caller que
iniciou a execu¸c˜ao das opera¸c˜oes, pode-se definir parˆametros nas chamadas de m´etodos dos
objetos Operation para que este contexto sej a propagado at´e os objetos Worker. Esta imple-
menta¸c˜ao gera intrus˜ao, pois os objetos Operation podem n˜ao neces sitar das informa¸c˜oes de
contexto. Neste caso, a existˆencia desses parˆametros pode tornar c omplexas as interfaces
das classes Operation, produzindo assim alto grau de acoplamento entre m´odulos. Outra
solu¸c˜ao poss´ıvel ´e definir uma ´area de acesso global, onde o objeto Caller armazena seus
dados para leitura pelos objetos Worker. Essa situa¸c˜ao gera acoplamento de dado externo
entre os objetos Caller e Worker, o que tamb´em desvaloriza a solu¸c˜ao.
22 CAP
´
ITULO 2. MODULARIDADE DE SISTEMAS DE SOFTWARE
< < stereotype>>
&DOOHU
< < stereotype>>
2SHUDWLRQ
+ operation( ... )
+ context: CallerContext
+ doSomething( )
suboperations
< < stereotype>>
:RUNHU
+ work( ... )
Figura 2.1: Representa¸c˜ao em UML do padr˜ao wormhole.
O padr˜ao wormhole tem por objetivo definir de forma modular um canal direto de comu-
nica¸c˜ao entre os objetos Caller e Worker, tornando dispon´ıveis para os objetos Worker as
informa¸c˜oes de contexto que ele precisar. Esse padr˜ao permite enc apsular a comunica¸c˜ao
entre esses objetos, propiciando uma implementa¸c˜ao com grau de acoplamento menor que
as implementa¸c˜oes que passam o contexto como parˆametro ou o armazenam em uma ´area
de acesso global.
A Figura 2.3 esquematiza a implementa¸c˜ao da passagem de contexto por meio do padr˜ao
wormhole. Nesta implementa¸c˜ao, a informa¸c˜ao de contexto ´e transmitida diretamente do
objeto Caller para os objetos Worker, sem a necessidade de alterar a interface dos objetos
Operation.
O aspecto WormholePattern define o padr˜ao wormhole, conforme mostrado na Listagem 2.10.
Neste aspecto, definem-se os seguintes conjuntos de jun¸c˜ao:
• invocations: pontos de chamadas de m´etodos da classe Operation, ou suas subclasses,
que ocorrerem em m´etodos cujo objeto receptor ´e da classe Caller;
• workPoints: pontos de chamadas do m´etodo doWork da classe Worker;
2.3. PROGRAMAC¸
˜
AO ORIENTADA POR ASPECTOS 23
Caller
Operation
Worker Worker
Worker
op op
opop
opop
<<context>>
<<context>> <<context>>
<<context>><<context>>
<<context>>
<<context>>
<<context>>
<<context>>
<<context>>
<<context>>
Figura 2.2: Implementa¸c˜ao de transmiss˜ao de contexto via passagem de parˆametros –
Extra´ıda de Kiczales (2002).
• perCallerWork: pontos de chamadas do m´etodo Worker.doWork() ou suas subclasses, que
ocorrerem no fluxo de execu¸c˜ao de uma invoca¸c˜ao de opera¸c˜ao a partir de m´etodos
da classe Caller.
A regra before aplicada ao conjunto de jun¸c˜ao perCallerWork propaga para o objeto Wor-
ker o contexto do objeto Caller cujo fluxo de execu¸c˜ao gerou a chamada ao m´etodo Wor-
ker.doWork().
A implementa¸c˜ao por meio de aspectos permite obter a propaga¸c˜ao direta de informa¸c˜oes
de contexto, sem aumentar a interface da classe Operation ou aumentar o acoplamento entre
as classes Caller e Worker por meio de valores globais. Al´em disso, todo o acoplamento entre
as classes Caller e Worker ´e controlado pelo aspecto WormholePattern, que funciona como me-
diador. Quaisquer altera¸c˜oes no contexto geram altera¸c˜oes somente neste aspecto, de modo
que as classes participantes n˜ao precisam ser alteradas para implementar a transmiss˜ao do
contexto.
´
E poss´ıvel definir tamb´em um aspecto abstrato que represente o protocolo do padr˜ao
wormhole de maneira semelhante `a feita nas implementa¸c˜oes do padr˜ao observador. Com
24 CAP
´
ITULO 2. MODULARIDADE DE SISTEMAS DE SOFTWARE
1 public aspect WormholePattern {
2
3 pointcut invocations ( Caller c ): this(c) && call(∗ Operation +.∗(..));
4
5 pointcut workPoints(Worker w): target(w) && call(void Worker.doWork());
6
7 pointcut perCallerWork(Caller c, Worker w): cflow(invocations (c)) && workPoints(w);
8
9 before ( Caller c, Worker w): perCallerWork(c, w) {
10 w.propagateCallerContext(c.getContext ());
11 System.out. println (thisJoinPoint.getClass ());
12 }
13
14 }
Listagem 2.10: Protocolo Para o Padr˜ao Wormhole – Extra´ıdo de Gradecki and Lesieck
(2003)
isso, este padr˜ao tamb´em pode possuir uma implementa¸c˜ao gen´erica e reutiliz´avel.
2.3.4 Avalia¸c˜ao da T´ecnica
O desenvolvimento de sistemas orientados por aspectos possui semelhan¸cas com o desenvol-
vimento de sistemas orientados por objetos. A proposta metodol´ogica consiste em definir
e implementar os requisitos do sistema por meio de orienta¸c˜ao por objetos e, em seguida,
definir regras para o entrela¸camento das preocupa¸c˜oes em diferentes m´odulos. Com isto, ´e
poss´ıvel definir componentes de software com baixo acoplamento e alta coes˜ao.
No paradima imperativo, a programa¸c˜ao orientada por aspectos n˜ao se trata de um subs-
tituto para a programa¸c˜ao orientada por objetos. Os requisitos funcionais de um sistema
continuar˜ao a ser implementados por meio da POO. A orienta¸c˜ao por aspectos simples-
mente adiciona novos conceitos `a POO, facilitando a implementa¸c˜ao de preocupa¸c˜oes or-
togonais e retirando grande parte da aten¸c˜ao dada a tais preocupa¸c˜oes nas fases iniciais de
desenvolvimento. Com efeito, o desenvolvedor p ode se concentrar na implementa¸c˜ao dos
m´odulos de requisitos funcionais do sistema, permitindo que a implementa¸c˜ao da distri-
bui¸c˜ao de preocupa¸c˜oes ortogonais aos m´odulos seja feita separadamente.
2.3. PROGRAMAC¸
˜
AO ORIENTADA POR ASPECTOS 25
Caller
Operation
Worker Worker
Worker
op op
opop
opop
<<context>>
<<context>><<context>>
<<context>>
Figura 2.3: Representa¸c˜ao gr´afica do padr˜ao wormhole – Extra´ıda de Kiczales (2002).
Apesar de a proposta inicial de orienta¸c˜ao por aspectos ter sido feita utilizando uma lin-
guagem funcional, ainda h´a poucas implementa¸c˜oes de linguagens funcionais orientadas
por aspectos, de modo que este ´e um campo de trabalho ainda bastante inexplorado.
O desenvolvimento orientado por aspectos permite definir claramente as responsabilidades
dos m´odulos individuais, uma vez que cada m´odulo ´e respons´avel unicamente por seu re-
quisito principal. Al´em disso, o n´ıvel de modulariza¸c˜ao do sistema ´e melhorado, com baixo
acoplamento e alta coes˜ao modular. Com efeito, ao retirar c´odigo intruso dos m´odulos, ´e
poss´ıvel diminuir a interface de cada m´odulo e, ao mesmo tempo, aumentar o seu n´ıvel
de coes˜ao, por tratar somente um requisito. As consequˆencias diretas s˜ao a melhoria do
processo de manuten¸c˜ao de sistemas e aumento no grau de re ´uso. Al´em disso, a evolu¸c˜ao
de sistemas ´e facilitada, visto que, se novos aspectos forem criados para implementar no-
vas preocupa¸c˜oes ortogonais, as classes do programa podem permanecer inalteradas. Da
mesma forma, ao adicionar novas classes ao programa, os aspectos existentes tamb´em s˜ao
transversais a essas classes.
Como principal ponto negativo, tem-se que a orienta¸c˜ao por aspectos pode quebrar a
encapsula¸c˜ao de m´odulos, ao permitir acesso a detalhes de sua implementa¸c˜ao e a altera¸c˜ao
da estrutura est´atica de tipos. Al´em disso, os mecanismos para defini¸c˜ao de conjuntos
26 CAP
´
ITULO 2. MODULARIDADE DE SISTEMAS DE SOFTWARE
de jun¸c˜ao apresentam uma dificuldade inerente denominada fragilidade no sentido que
altera¸c˜oes nas interfaces de m´odulos podem tornar obsoletas as express˜oes de defini¸c˜ao dos
pontos afetados, exigindo sua redefini¸c˜ao.
Outro ponto relevante de pesquisa ´e a defini¸c˜ao formal completa das linguagens orientadas
por aspectos. Wand et al. (2004) definiram a semˆantica formal de conjuntos de jun¸c˜ao
e adendos da transversalidade dinˆamica de AspectJ utilizando a Semˆantica Denotacional.
Walker et al. (2003) definem a Semˆantica Op e racional Estruturada de uma linguagem con-
ceitual orientada por aspectos, com o objetivo de oferecer um arcabou¸co para defini¸c˜ao
da semˆantica de linguagens orientadas por aspectos. O trabalho de L¨ammel (1999) mos-
tra a semˆantica formal de uma linguagem funcional orientada por aspectos e formaliza o
mecanismo de costura de c´odigo realizado tamb´em por meio da Semˆantica Operacional
Estruturada.
Aldrich (2004), Clifton and Leavens (2002), Kiczales and Mezini (2005), Krishnamurthi
et al. (2004) discutem o impacto da utiliza¸c˜ao da orienta¸c˜ao por aspectos no racioc´ınio
modular. Segundo os autores, a leitura de um m´odulo em um sistema orientado por
aspectos exige algum conhecimento global do sistema. No entanto, pode-se argumentar que,
na presen¸ca de preocupa¸c˜oes ortogonais, o acoplamento tende a ser muito alto e a coes˜ao
dos m´odulos, muito baixa, o que pode resultar na mesma necessidade de conhecimento
global no sistema. A vantagem destacada do uso da orienta¸c˜ao por aspectos neste ponto
reside principalmente no fato de que essa necessidade se torna expl´ıcita e o racioc´ınio
modular pode ser feito uma vez terminada essa an´alise global.
2.4 Conclus˜oes
A modularidade ´e um elemento chave na implementa¸c˜ao de sistemas de grande porte,
por permitir que o desenvolvedor se concentre em pequenas partes do problema a cada
momento. Recentemente, percebeu- se que certas preocupa¸c˜oes em sistemas n˜ao eram ade-
quadamente separ´aveis de outras, principalmente pela falta de constru¸c˜oes lingu´ısticas para
lidar com partes do programa cuja codifica¸c˜ao se apresenta entrela¸cada. Essa dificuldade
gera problemas a longo prazo, uma vez que, com o tempo, pode ser necess´ario que elementos
entrela¸cados evoluam independentemente.
A partir dessa constata¸c˜ao, definiram-se mecanismos te´oricos de decomposi¸c˜ao de siste-
mas em v´arias dimens˜oes, nomenclatura oriunda da interpreta¸c˜ao das etapas da evolu¸c˜ao
independente dos requisitos como pontos de um eixo em um espa¸co multidimensional.
2.4. CONCLUS
˜
OES 27
As t´ecnicas propostas para solu¸c˜ao desse problema, a orienta¸c˜ao por aspectos e a de-
composi¸c˜ao multidimensional, encontram-se em estado de pleno desenvolvimento, cujas
pesquisas tˆem gerados resultados pr´aticos de grande impacto na modularidade de siste-
mas.
Defini¸c˜oes de semˆantica denotacional de linguagens de programa¸c˜ao apresentam problemas
de modularidade devidos a entrela¸camento de constituintes nas equa¸c˜oes, conforme ser´a
mostrado nos Cap´ıtulo 3, de modo que a utiliza¸c˜ao dos mecanismos de decomposi¸c˜ao
multidimensional e orienta¸c˜ao por aspectos podem trazer ganhos significativos na defini¸c˜ao
de m´odulos independentes e na escrita incremental de especifica¸c˜oes.
O pr´oximo cap´ıtulo aborda as principais t´ecnicas para defini¸c˜ao semˆantica, com ˆenfase
dada especialmente `as t´ecnicas para modularizar especifica¸c˜oes de semˆantica denotacional.
28 CAP
´
ITULO 2. MODULARIDADE DE SISTEMAS DE SOFTWARE
Cap´ıtulo 3
Modularidade da Se mˆantica
Denotacional
Este cap´ıtulo apresenta uma descri¸c˜ao geral das t´ecnicas de especifica¸c˜ao da semˆantica
de linguagens de programa¸c˜ao, com ˆenfase na semˆantica denotacional e nas metodologias
correntes para modulariza¸c˜ao de especifica¸c˜oes nesse arcabou¸co.
Organiza¸c˜ao do Cap´ıtulo. Na Se¸c˜ao 3.1, s˜ao relatadas as principais metodologias de
defini¸c˜ao de semˆantica de linguagens de programa¸c˜ao. A modularidade das defini¸c˜oes de
Semˆantica Denotacional e suas t´ecnicas de modulariza¸c˜ao mais importantes s˜ao mostradas
na Se¸c˜ao 3.2. Finalmente, a Se¸c˜ao 3.3 apresenta as conclus˜oes do cap´ıtulo.
3.1 Semˆantica de Linguagens de Programa¸c˜ao
Defini¸c˜oes formais da semˆantica de linguagens de programa¸c˜ao s˜ao de grande relevˆancia,
uma vez que possibilitam a defini¸c˜ao n˜ao-amb´ıgua dos constituintes de uma linguagem,
o que n˜ao pode ser garantido ao se definir a semˆantica de maneira informal por meio
da linguagem natural. A consequˆencia direta de seu uso ´e a viabiliza¸c˜ao de uma s´erie
de atividades de importˆancias te´orica e pr´atica, dentre as quais destacam-se: projeto e
prototipa¸c˜ao de novas linguagens, gera¸c˜ao autom´atica de interpretadores e compiladores,
verifica¸c˜ao de propriedades e padroniza¸c˜ao da linguagem (Mosses 2001, Schmidt 1996,
Zhang and Xu 2004). Tennent (1976) argumenta ainda que, mesmo se uma defini¸c˜ao
29
30 CAP
´
ITULO 3. MODULARIDADE DA SEM
ˆ
ANTICA DENOTACIONAL
formal n˜ao for acess´ıvel ao programador m´edio, ela ainda ser´a ´util ao prover a base para
uma descri¸c˜ao informal mais precisa.
Zhang and Xu (2004) mostram sete ´areas de aplica¸c˜ao para semˆantica formal de linguagens
de programa¸c˜ao:
1. a semˆantica ´e o produto do processo de elabora¸c˜ao de uma linguagem, podendo ser
usada para comunicar as decis˜oes tomadas pelos projetistas;
2. durante a implementa¸c˜ao da linguagem, a especifica¸c˜ao da semˆantica permite garantir
o comportamento c orreto da implementa¸c˜ao;
3. a padroniza¸c˜ao da linguagem pode ser obtida publicando-se semˆantica n˜ao-amb´ıgua;
4. a compreens˜ao dos programadores sobre a linguagem requer o aprendizado do seu
comportamento, isto ´e, da sua semˆantica;
5. a semˆantica auxilia o programador a raciocinar a respeito de seu programa, permi-
tindo por exemplo verificar se este faz o que deveria fazer;
6. a semˆantica permite que os te´oricos da ´area obtenham novos insights sobre conceitos
de programa¸c˜ao, abrindo assim novas ´areas de pesquisa;
7. descri¸c˜oes semˆanticas podem ser utilizadas na gera¸c˜ao autom´atica de interpretadores
e compiladores.
Segundo Boute (2005) um formalismo ´e composto por uma nota¸c˜ao e um conjunto de
regras formais de manipula¸c˜ao, de modo que o seu m´erito ´e medido n˜ao somente pelo seu
escopo e expressividade, mas principalmente pe lo grau em que auxilia no racio c´ınio e na
prova de propriedades. Com isso, ´e essencial que a obten¸c˜ao de um alto n´ıvel de abstra¸c˜ao
seja um dos objetivos principais do projeto de qualquer mecanismo de defini¸c˜ao formal.
Para avaliar as t´ecnicas de especifica¸c˜ao semˆantica, Gayo (2002), Mosses (1988), Moura
(1996) sugerem os seguintes crit´erios:
1. ausˆencia de ambiguidade: a t´ecnica deve possibilitar o desenvolvimento de descri¸c˜oes
precisas que identifiquem claramente o comportamento de um dado programa;
2. possibilidade de demonstra¸c˜ao: a t´ecnica deve possuir base matem´atica que permita
demonstrar propriedades de programas;
3.1. SEM
ˆ
ANTICA DE LINGUAGENS DE PROGRAMAC¸
˜
AO 31
3. prototipa¸c˜ao: deve ser poss´ıvel gerar automaticamente algum ambiente de execu¸c˜ao
a partir da descri¸c˜ao semˆantica da linguagem;
4. modularidade: deve ser poss´ıvel escrever a especifica¸c˜ao de maneira incremental e
adicionar recursos ortogonais `a linguagem sem a necessidade de alterar defini¸c˜oes j´a
existentes;
5. reusabilidade: a t´ecnica deve permitir a reutiliza¸c˜ao da especifica¸c˜ao de recursos
comuns entre linguagens diferentes;
6. legibilidade: descri¸c˜oes semˆanticas devem ser leg´ıveis para pess oas com diferentes
conhecimentos de programa¸c˜ao;
7. flexibilidade: deve ser poss´ıvel especificar a grande variedade de linguagens, paradig-
mas e recursos de programa¸c˜ao;
8. escalabilidade: deve ser poss´ıvel aplicar a t´ecnica formal a linguagens de programa¸c˜ao
de grande porte;
9. abstra¸c˜ao: deve ser poss´ıvel ao projetista concentrar-se nos elementos de projeto mais
relevantes, sem a necessidade de se preocupar com detalhes da implementa¸c˜ao;
10. compara¸c˜ao: deve ser f´acil comparar duas linguagens a partir de suas defini¸c˜oes
formais.
Os arcabou¸cos de defini¸c˜ao semˆantica s˜ao comumente classificados em trˆes categorias:
(i) axiom´atica, que descreve propriedades de programas por meio de asser¸c˜oes; (ii) opera-
cional, que especifica as diversas constru¸c˜oes de uma linguagem por meio de uma sequˆencia
de passos para se obter um resultado em alguma m´aquina abstrata hipot´etica; (iii) deno-
tacional, que define a semˆantica de uma linguagem por me io de mapeamentos de suas
constru¸c˜oes em objetos matem´aticos denominados denota¸c˜oes.
3.1.1 Semˆantica Axiom´atica
A semˆantica axiom´atica definida por Hoare (1969) ´e baseada na l´ogica de predicados e
descreve a semˆantica de uma linguagem por meio das propriedades de suas constru¸c˜oes.
O prop´osito deste modelo ´e oferecer uma base l´ogica para a prova de propriedades de
programas. Para isso, a semˆantica de constru¸c˜oes ´e dada por meio de asser¸c˜oes sobre os
valores de vari´aveis antes e depois das suas execu¸c˜oes.
32 CAP
´
ITULO 3. MODULARIDADE DA SEM
ˆ
ANTICA DENOTACIONAL
Axioma de atribui¸c˜ao: (P [x → a]){x ← a}P
Regras de consequˆencia:
P {Q}R R ⇒ S
P {Q}S
P {Q}R S ⇒ P
S{Q}R
Regra de composi¸c˜ao:
P {Q
1
}R
1
R
1
{Q
2
}R
P {Q
1
; Q
2
}R
Regra de condicional:
(B ∧ P ){Q
1
}R (¬B ∧ P ){Q
2
}R
P {if B then Q
1
else Q
2
}R
Regra de repeti¸c˜ao:
(B ∧ P ){Q}P
P {while B do Q}(¬B ∧ P )
Figura 3.1: Exemplo de semˆantica axiom´atica de uma linguagem contendo atribui¸c˜oes,
condicionais e repeti¸c˜ao. As regras s˜ao baseadas em Hoare (1969), Zhang and Xu (2004).
Uma especifica¸c˜ao semˆantica axiom´atica ´e um conjunto de asser¸c˜oes da forma P {Q}R,
onde Q ´e uma constru¸c˜ao da linguagem, P ´e uma pr´e-condi¸c˜ao `a execu¸c˜ao de Q, e R ´e a
descri¸c˜ao do resultado da execu¸c˜ao de Q. Tamb´em ´e poss´ıvel definir regras de inferˆencia
da forma:
R
1
R
2
· · · R
n
R
em que R
1
, R
2
, · · · , R
n
s˜ao as premissas, e R ´e a conclus˜ao. Por exemplo, a Figura 3.1
mostra as regras para os comandos de uma linguagem simples que cont´em atribui¸c˜oes,
condicionais e repeti¸c˜ao.
A semˆantica axiom´atica ´e uma forma bastante simples de se definir propriedades das cons-
tru¸c˜oes de uma linguagem, sendo portanto uma boa t´ec nica para se provar propriedades
de programas. Entretanto, conforme destacado por Mosses (2001), uma dificuldade do
modelo est´a no fato de que express˜oes da linguagem n˜ao podem ter efeitos colaterais nem
gerar erros ao serem avaliadas, uma vez que a semˆantica de comandos de atribui¸c˜ao en-
volve a substitui¸c˜ao nas cl´ausulas l´ogicas de vari´aveis pelos valores das express˜oes no lado
direito das atribui¸c˜oes. Al´em disso, Zhang and Xu (2004) destacam que esta t´ecnica n˜ao
3.1. SEM
ˆ
ANTICA DE LINGUAGENS DE PROGRAMAC¸
˜
AO 33
´e adequada para gera¸c˜ao autom´atica de compiladores.
3.1.2 Semˆantica Operacional
A semˆantica operacional define a semˆantica das constru¸c˜oes de uma linguagem por meio
dos passos para a sua execu¸c˜ao em uma m´aquina abstrata hipot´etica. O foco dessa t´ecnica
est´a, portanto, na forma como um resultado ´e obtido e n˜ao no seu significado (Zhang and
Xu 2004). Segundo Mosses (2001), a computa¸c˜ao geralmente ´e dada por uma sequˆencia
possivelmente infinita de passos entre estados, de modo que a semˆantica operacional tem
por objetivo modelar as computa¸c˜oes que um programa realiza para chegar a um resultado.
Existem diversas t´ecnicas baseadas em semˆantica operacional, dentre as quais destacam-
se: a semˆantica operacional estruturada (Plotkin 1981), as m´aquinas de estado abstratas
(Gurevich 1994, 1995) e a semˆantica operacional modular Mosses (2004).
3.1.2.1 Semˆantica Operacional Estruturada
Na semˆantica operacional estruturada (Plotkin 1981), uma computa¸c˜ao ´e modelada como
uma sequˆencia de transi¸c˜oes em um sistema de transi¸c˜oes rotuladas, isto ´e, uma estrutura
Γ, A, →, onde Γ ´e um c onjunto de configura¸c˜oes – os estados do sistema –, A ´e um
conjunto de r´otulos, e →⊆ Γ×A×Γ ´e uma rela¸c˜ao de transi¸c˜ao. A defini¸c˜ao das transi¸c˜oes
na m´aquina s˜ao dadas em geral por meio de regras de inferˆencia.
Durante uma computa¸c˜ao em semˆantica operacional estruturada, a ´arvore de sintaxe abs-
trata do programa ´e atualizada, substituindo-se partes da ´arvore pelos valores correspon-
dentes gerados pela computa¸c˜ao. As informa¸c˜oes de contexto necess´arias para c´alculo dos
resultados, tais como estados e ambientes, pertencem em geral aos estados da computa¸c˜ao.
A Figura 3.2, inspirada em Plotkin (1981), mostra um exemplo de defini¸c˜ao da semˆantica
operacional estruturada de uma linguagem simples contendo constantes, vari´aveis, atri-
bui¸c˜oes e condicionais.
A semˆantica operacional estruturada ´e uma t´ecnic a bastante poderosa de defini¸c˜ao semˆan-
tica, permitindo a especifica¸c˜ao de praticamente todos os recursos presentes em linguagens
de programa¸c˜ao. Al´em disso, a gera¸c˜ao de interpretadores a partir da defini¸c˜ao de uma
linguagem utilizando semˆantica operacional estruturada ´e bastante simples.
34 CAP
´
ITULO 3. MODULARIDADE DA SEM
ˆ
ANTICA DENOTACIONAL
Atribui¸c˜ao:
e, σ →
∗
m, σ
v ← e, σ → σ
[m/v]
Composi¸c˜ao:
c
0
, σ → c
0
, σ
c
0
; c
1
, σ → c
0
; c
1
, σ
c
0
, σ → σ
c
0
; c
1
, σ → c
1
, σ
Condicional:
e, σ →
∗
true, σ
if e then c
1
el s e c
2
, σ → c
1
, σ
e, σ →
∗
false, σ
if e then c
1
el s e c
2
, σ → c
2
, σ
Figura 3.2: Exemplo de semˆantica operacional estruturada de uma linguagem simples
contendo atribui¸c˜oes e condicionais. As equa¸c˜oes foram adaptadas de Plotkin (1981). Neste
sistema, m representa um valor, σ, σ
representam stores, c, c
0
, c
1
, c
2
representam comandos,
e representa uma express˜ao, e os estados s˜ao elementos de Γ = {e, σ} ∪ {c, σ} ∪ {σ}.
Entretanto, conforme apontado por Gayo (2002), al´em de ser dif´ıcil escrever especifica¸c˜oes
modulares e reutiliz´aveis, algumas defini¸c˜oes formais s˜ao muito longas, o que dificulta a
verifica¸c˜ao de propriedades de programas.
3.1.2.2 M´aquinas de Estado Abstratas
O modelo de M´aquinas de Estado Abstratas
1
(Gurevich 1994, 1995) tem por objetivo
favorecer a defini¸c˜ao de semˆantica formal operacional com n´ıvel de abstra¸c˜ao mais alto que
o obtido com t´e cnicas anteriores, ao mesmo tempo em que possui base matem´atica precisa
que permite a demonstra¸c˜ao de propriedades da linguagem. Nesta t´ecnica, os estados s˜ao
definidos por meio de fun¸c˜oes e rela¸c˜oes sobre um conjunto denominado superuniverso;
as transi¸c˜oes de estado s˜ao feitas por meio da redefini¸c˜ao das interpreta¸c˜oes de fun¸c˜oes
e rela¸c˜oes. Com efeito, uma regra de transi¸c˜ao ´e composta por regras de atualiza¸c˜ao
cuja fun¸c˜ao ´e atualizar fun¸c˜oes em pontos definidos. O exemplo da Figura 3.3 mostra
uma defini¸c˜ao da semˆantica operacional de uma linguagem simples composta por valores
1
Uma introdu¸c˜ao a m´aquinas de estado abstratas ´e dada por Tirelo et al. (1999).
3.1. SEM
ˆ
ANTICA DE LINGUAGENS DE PROGRAMAC¸
˜
AO 35
Fun¸c˜oes dinˆamicas:
val : Expr → Int
loc : Var → Value
Regras de transi¸c˜ao:
if task is num then
val(task) := num
if task is e
1
+ e
2
then
val(task) := val(e
1
) + val(e
2
)
if task is var then
val(task) := loc(var)
if task is x := e then
loc(x) := val(e)
Figura 3.3: Exemplo de semˆantica operacional de uma linguagem simples contendo ex-
press˜oes, vari´aveis e atribui¸c˜oes, por meio de m´aquinas de estado abstratas. As equa¸c˜oes
foram adaptadas de Gayo (2002).
inteiros, opera¸c˜oes aritm´eticas, vari´aveis e atribui¸c˜oes. Esse exemplo, foi extra´ıdo de Gayo
(2002), inspirado em B¨orger and Schulte (1998).
Ao se definir uma especifica¸c˜ao de m´aquinas de estado abstratas, parte-se de um modelo
de alto n´ıvel denominado ground model (B¨orger and Schulte 1998, Gurevich 1995), que
´e reificado at´e se obter uma vers˜ao execut´avel da especifica¸c˜ao. Esse m´etodo permite a
defini¸c˜ao de especifica¸c˜oes modulares e execut´aveis. Al´em disso, o modelo ´e relativamente
simples, sendo as defini¸c˜oes bastante parecidas com programas em uma linguagem de
programa¸c˜ao impe rativa de alto n´ıvel. A vantagem principal deste m´eto do, no entanto, ´e
a p ossibilidade de se realizar o racioc´ınio equacional que leva a prova de propriedades da
especifica¸c˜ao.
36 CAP
´
ITULO 3. MODULARIDADE DA SEM
ˆ
ANTICA DENOTACIONAL
3.1.2.3 Semˆantica Operacional Modular
Mosses (2004) propˆos um modelo inspirado em semˆantica mon´adica para a defini¸c˜ao da
semˆantica operacional estruturada modular (MSOS) de linguagens de programa¸c˜ao. Em
sua abordagem, `a medida que novas constru¸c˜oes s˜ao adicionadas `a especifica¸c˜ao, o contexto
pode evoluir sem exigir que equa¸c˜oes previamente escritas sejam redefinidas. Informa¸c˜ao
de contexto ´e transmitida por meio de r´otulos nas regras de transi¸c˜ao, e modularidade e
extensibilidade s˜ao obtidas ao se deixar que as transi¸c˜oes sejam independentes da estrutura
dos r´otulos. O resultado ´e um conjunto de regras de transi¸c˜ao abstratas que n˜ao fazem
referˆencia expl´ıcita a informa¸c˜oes de contexto. Al´em disso, o modelo prese rva a propriedade
da semˆantica operacional estruturada em permitir defini¸c˜ao separada da intera¸c˜ao entre
constru¸c˜oes.
Com o objetivo de simplificar a escrita de defini¸c˜oes de semˆantica operacional estruturada,
associa-se `as regras de transi¸c˜ao uma mˆonada (Moggi 1989, 1991, Wadler 1990, 1992).
Esta mˆonada possibilita que stores, environments e continua¸c˜oes sejam passadas implici-
tamente nas regras, sem a necessidade da men¸c˜ao impl´ıcita feita na semˆantica operacional
estruturada. Resultado semelhante foi obtido por Turi and Plotkin (1997), em que as re-
gras de transi¸c˜ao s˜ao modeladas como transforma¸c˜oes da teoria das categorias (Fokkinga
1992, Fokkinga and Meertens 1994, Menezes and Haeusler 2001, Shutt 2003).
No entanto, a defini¸c˜ao de certas intera¸c˜oes podem exigir a listagem de todos os poss´ıveis
casos, como na defini¸c˜ao de Java fornecida por Cenciarelli et al. (1999); mesmo sem a
defini¸c˜ao de repeti¸c˜ao e se quenciadores, h´a trinta e trˆes regras de transi¸c˜ao para a defini¸c˜ao
de chamada e retorno de fun¸c˜ao, tratamento de exce¸c˜oes e suas intera¸c˜oes
2
.
3.1.3 Semˆantica Denotacional
A semˆantica denotacional (Gordon 1979, Scott and Strachey 1971, Stoy 1981, Tennent
1976) define a semˆantica de uma linguagem mapeando suas constru¸c˜oes em objetos ma-
tem´aticos denominados denota¸c˜oes. Geralmente, denota¸c˜oes s˜ao fun¸c˜oes cont´ınuas de or-
dem mais alta dos dom´ınios de Scott (1976), cujos argumentos s˜ao informa¸c˜oes do contexto
e o resultado ´e a influˆencia da constru¸c˜ao no comportamento global do programa. Uma
2
Na verdade, as regras apenas definem o comportamento de comandos de retorno em blocos try, sem
especificar o seu comportamento dentro de blocos catch; assim, pelas regras apresentadas, se um retorno
for executado dentro de um bloco catch, o bloco finally correspondente n˜ao ser´a executado, diferentemente
da especifica¸c˜ao padr˜ao da linguagem.
3.1. SEM
ˆ
ANTICA DE LINGUAGENS DE PROGRAMAC¸
˜
AO 37
diferen¸ca b´asica entre esse modelo e a semˆantica operacional ´e que, enquanto a semˆantica
operacional define como o resultado de um programa ´e obtido, a semˆantica denotacional
define o efeito de cada constru¸c˜ao no resultado final do programa.
Defini¸c˜oes de semˆantica denotacional podem ser feitas de duas maneiras: utilizando-se
semˆantica direta, em que o sequenciamento ´e feito por composi¸c˜ao de fun¸c˜oes; ou por meio
da semˆantica de continua¸c˜ao (Strachey and Wadsworth 1974), em que o sequenciamento ´e
feito por meio de fun¸c˜oes de continua¸c˜ao. Enquanto na semˆantica direta, a semˆantica de
um programa ´e dada pela composi¸c˜ao das fun¸c˜oes semˆanticas, na semˆantica de continua¸c˜ao
cada constru¸c˜ao semˆantica propaga o efeito de sua execu¸c˜ao por meio de suas continua¸c˜oes.
A semˆantica de continua¸c˜ao torna poss´ıvel definir a semˆantica de sequenciadores, pois
permite que a constru¸c˜ao continue sua execu¸c˜ao em outro ponto do programa, ignorando
a continua¸c˜ao normal recebida como argumento.
Uma defini¸c˜ao de semˆantica denotacional ´e constitu´ıda por: sintaxe abstrata da linguagem,
dom´ınios sint´aticos e semˆanticos, fun¸c˜oes semˆanticas e equa¸c˜oes semˆanticas. Tipicamente,
as fun¸c˜oes semˆanticas possuem como parˆametros as seguintes informa¸c˜oes de contexto:
(i) environments, ou ambientes, que mapeiam identificadores em localiza¸c˜oes na mem´oria;
(ii) stores, que mapeiam localiza¸c˜oes na mem´oria em valores; (iii) continua¸c˜oes, que repre-
sentam o passo seguinte `a execu¸c ˜ao de cada constru¸c˜ao.
A Figura 3.4 mostra um exemplo de defini¸c˜ao da semˆantica denotacional de uma lingua-
gem simples contendo somente constantes, vari´aveis, express˜oes aritm´eticas, atribui¸c˜oes e
condicionais. Neste exemplo, definem-se os dom´ınios semˆanticos, as fun¸c˜oes semˆanticas
para express˜oes, comandos e programas, e as equa¸c˜oes semˆanticas para as constru¸c˜oes da
linguagem por meio da semˆantica direta.
A semˆantica denotacional ´e um mecanismo bastante poderoso e preciso para defini¸c˜ao de
semˆantica de linguagens de programa¸c˜ao. Sua base matem´atica permite a prova de propri-
edades da defini¸c˜ao e inclui elementos importantes tais como n˜ao-termina¸c˜ao e condi¸c˜oes
de erro. Entretanto, segundo Gayo (2002), Mosses (2004), a defini¸c˜ao denotacional de
n˜ao-determinismo e concorrˆencia requer o uso de dom´ınios potˆencia, o que exige uma
quantidade significativa de nota¸c˜ao extra. Al´em disso, ´e poss´ıvel gerar prot´otipos para
linguagens a partir de defini¸c˜oes semˆanticas denotacionais. No entanto, o grande problema
do modelo de semˆantica denotacional reside na falta de modularidade e dificuldade em
re´uso das defini¸c˜oes, conforme discutido na Se¸c˜ao 3.2.
38 CAP
´
ITULO 3. MODULARIDADE DA SEM
ˆ
ANTICA DENOTACIONAL
Dom´ı nios Semˆanticos:
Num = {0, 1, 2, · · · }
State = [Ide → Num]
n ∈ Num, s ∈ State
Fun¸c˜oes Semˆanticas:
E : Exp → State → Num
C : Com → State → State
P : Prog → Num → Num
Equa¸c˜oes Semˆanticas:
E[[0]]s = 0
E[[I]]s = s I
E[[suc E]]s = E[[E]]s + 1
C[[I := E]]s = s[E[[E]]s/I]
C[[C
1
; C
2
]]s = C[[C
2
]](C[[C
1
]]s )
Figura 3.4: Exemplo de semˆantica denotacional de uma linguagem simples contendo ex-
press˜oes, vari´aveis e atribui¸c˜oes e repeti¸c˜oes – extra´ıdo de Bigonha (2003).
3.2 Modularidade em Semˆantica Denotacional
Modularizar uma especifica¸c˜ao semˆantica significa ser capaz de dividi-la em unidades coesas
e independentes, isto ´e, com baixa conectividade e baixo acoplamento. Segundo Mosses
(1988), a modularidade de uma especifica¸c˜ao pode ser avaliada por meio de trˆes crit´erios:
a granularidade da defini¸c˜ao, que indica a capacidade de um sistema em ser dividido
em partes independentes; a independˆencia entre seus m´odulos, isto ´e, a conectividade
do sistema e o acoplamento das conex˜oes; e a padroniza¸c˜ao de seus constituintes.
Ainda de acordo com Mosses (1988), a modularidade de uma espec ifica¸c ˜ao semˆantica ´e
muito importante, uma vez que defini¸c˜oes com alto grau de modularidade tendem a possuir
as seguintes caracter´ısticas, desej´aveis em qualquer projeto de grande porte:
1. extensibilidade (Meyer 1997), isto ´e, pequenas modifica¸c˜oes na linguagem devem
exigir pequenas altera¸c˜oes na sua especifica¸c˜ao semˆantica;
2. reusabilidade, isto ´e, ao se escrever a especifica¸c˜ao de uma linguagem, deve ser poss´ıvel
3.2. MODULARIDADE EM SEM
ˆ
ANTICA DENOTACIONAL 39
utilizar prontamente m´odulos j´a escritos em defini¸c˜oes anteriores, em especial quando
as linguagens apresentam muitas semelhan¸cas;
3. legibilidade, no sentido que deve ser poss´ıvel pela defini¸c˜ao formal da linguagem
compreender e provar suas propriedades mais importantes.
Como observado na literatura (Liang et al. 1995, Mosses 1988, 2001, Zhang and Xu 2004),
a semˆantica denotacional apresenta problemas s´erios de modularidade. O mais importante
desses problemas est´a relacionado ao fato de as fun¸c˜oes semˆanticas dependerem totalmente
das defini¸c˜oes dos dom´ınios semˆanticos, o que pode acarretar modifica¸c˜oes ao longo de toda
a defini¸c˜ao quando a inclus˜ao de novos recursos na linguagem exigirem a altera¸c˜ao desses
dom´ınios. Um exemplo significativo desse problema est´a relacionado `a dificuldade em se
passar de semˆantica direta para semˆantica de continua¸c˜ao, pois isto implica na altera¸c˜ao
de todas as equa¸c˜oes semˆanticas da especifica¸c˜ao.
Al´em disso, o λ-c´alculo, nota¸c˜ao padr˜ao utilizada na semˆantica denotacional, apesar de
permitir isolar detalhes da teoria de dom´ınios, n˜ao ´e suficiente para abstrair stores, envi-
ronments e continua¸c˜oes. Por exemplo, a equa¸c˜ao semˆantica de um comando condicional,
apesar de n˜ao precisar fazer referˆencia direta ao environment e `a continua¸c˜ao correntes,
deve inclu´ı-los em sua defini¸c˜ao, como mostrado na equa¸c˜ao a seguir
3
:
C[[if E then C
1
else C
2
]] = λrc.R[[E]]r; cond(C[[C
1
]]rc, C[[C
2
]]rc)
Como solu¸c˜ao aos problemas apresentados, v´arias abordagens j´a foram propostas, den-
tre as quais destacam-se a semˆantica de a¸c˜oes (Se¸c˜ao 3.2.1), a semˆantica de mˆonadas
(Se¸c˜ao 3.2.2), e a semˆantica de a¸c˜oes com mˆonadas (Se¸c˜ao 3.2.3). Mais recentemente, fo-
ram propostas abordagens para a separa¸c˜ao de preocupa¸c˜oes em especifica¸c˜oes semˆanticas,
com destaque para as gram´aticas de atributos de primeira classe (Se¸c˜ao 3.2.4) e a aborda-
gem construtiva para semˆantica (Se¸c˜ao 3.2.5).
3.2.1 Semˆantica de A¸c˜oes
Semˆantica de A¸c˜oes (Mosses 1977, 1993, Mosses and Watt 1987, Moura 1996) ´e uma
proposta h´ıbrida de semˆantica denotacional e operacional, que tem por objetivo permitir
3
Neste exemplo, r represe nta o environment e c, a continua¸c˜ao; a nota¸c˜ao utilizada ´e baseada naquela
utilizada por Gordon (1979).
40 CAP
´
ITULO 3. MODULARIDADE DA SEM
ˆ
ANTICA DENOTACIONAL
Semˆantica de Express˜oes:
• evaluate :: Expr → Action [ giving Integer ]
(1) evaluate [[ n : Numeral ]] = give n
(2) evaluate [[ E
1
: Expr “+”E
2
: Expr ]] =
evaluate E
1
and
evaluate E
2
then give sum(given Integer#1, given Integer#2)
Figura 3.5: Exemplo de semˆantica de a¸c˜oes para as express˜oes de uma linguagem simples
contendo express˜oes, vari´aveis, atribui¸c˜oes e sequenciamento – extra´ıdo de Gayo (2002).
a cria¸c˜ao de defini¸c˜oes de semˆantica denotacional leg´ıveis e modulares. Em semˆantica de
a¸c˜oes, define-se uma linguagem por meio do mapeamento de suas constru¸c˜oes em a¸c˜oes,
que s˜ao por sua vez definidas por meio de semˆantica operacional estruturada. Segundo
Zhang and Xu (2004), este elemento ´e chave para a se mˆantica de a¸c˜oes, pois sua base
te´orica ´e mais acess´ıvel que a teoria de fun¸c˜oes cont´ınuas de ordem mais alta.
O elemento mais importante da semˆantica de a¸c˜oes ´e a a¸c˜ao, que consiste em uma entidade
que pode ser executada, recebendo e produzindo dados e/ou alterando stores. Associados
`as a¸c˜oes, definem-se combinadores de a¸c˜oes, cujo objetivo ´e definir a¸c˜oes compostas. A
execu¸c˜ao de uma a¸c˜ao c onsiste em uma sequˆencia de passos atˆomicos executados por um
agente, que pode ser visto como uma m´aquina abstrata da semˆantica operacional.
Um dos pontos fortes do modelo ´e a legibilidade das defini¸c˜oes semˆanticas, devido princi-
palmente `a sua “aparˆencia completamente verbal”(Mosses 1988) que ´e gerada pela escolha
por exemplo de verbos para nomear a¸c˜oes e substantivos para dados. Este fator pode ser
claramente observado na defini¸c˜ao das linguagens Pascal (Mosses and Watt 1993), JOOS
4
(Watt 1997) e Standard ML (Watt 1988). As Figuras 3.5 e 3.6 contˆem um exemplo ex-
tra´ıdo de Gayo (2002), em que ´e dada a semˆantica de a¸c˜oes de uma pequena linguagem
contendo n´umeros, express˜oes aritm´e ticas, vari´aveis, atribui¸c˜oes e sequenciamento.
4
JOOS ´e um subconjunto da linguagem Java contendo classes, heran¸ca, chamada dinˆamica de m´etodos
e construtores.
3.2. MODULARIDADE EM SEM
ˆ
ANTICA DENOTACIONAL 41
Semˆantica de Comandos:
• execute :: Comm → Action [ completing | storing ]
(1) execute [[ “skip” ]] = complete
(2) execute [[ x : Ident “:=”E : Expr ]] =
give the cell bound to x
and
evaluate E
then
store the given Value#2 in the given cell#1
(3) execute [[ C
1
: Comm “;”C
2
: Comm ]] =
execute C
1
and then execute C
2
Figura 3.6: Exemplo de s emˆantica de a¸c˜oes para os comandos de uma linguagem simples
contendo express˜oes, vari´aveis, atribui¸c˜oes e sequenciamento – extra´ıdo de Gayo (2002).
Outro ponto forte deste modelo ´e a possibilidade de se reutilizar partes de defini¸c˜oes an-
teriores, como pode ser visto por exemplo na defini¸c˜ao da linguagem Pascal (Mosses and
Watt 1993) em que se inclue m elementos definidos por Mosses (1992). Um dos elementos
que melhoram o grau de re´uso obtido ´e o fato da nota¸c˜ao de a¸c˜oes (Mosses 2000) ser
padronizada.
Quanto `a sua expressividade, segundo Mosses (2001), semˆantica de a¸c˜oes permite o suporte
direto a fluxo de controle e de dados, amarra¸c˜oes de identificadores, efeitos colaterais, abs-
tra¸c˜ao de comandos e express˜oes, abstra¸c˜ao de tipos, comunica¸c˜ao ass´ıncrona de processos.
Al´em disso, segundo Moura (1996), a modelagem de concorrˆencia pode ser feita por meio
da defini¸c˜ao de m´ultiplos agentes.
No entanto, este modelo apresenta limita¸c˜oes no que diz respeito `a modularidade. A prin-
cipal dificuldade, apontada por Wansbrough and Hamer (1997), Zhang and Xu (2004), est´a
no fato de que o modelo ´e incompleto, no sentido que os ´unicos conceitos de linguagens de
programa¸c˜ao que podem ser representados diretamente s˜ao aqueles definidos para compˆor
o n´ucleo do sistema, e a inclus˜ao de novos elementos neste n´ucleo ´e uma tarefa bastante
complexa. Esta dificuldade se deve principalmente ao fato de que, apesar de haver modu-
42 CAP
´
ITULO 3. MODULARIDADE DA SEM
ˆ
ANTICA DENOTACIONAL
laridade no n´ıvel das equa¸c˜oes semˆanticas, as a¸c˜oes s˜ao definidas de forma monol´ıtica e n˜ao
h´a uma t´ecnica padronizada para a inclus˜ao de novas defini¸c˜oes. Um exemplo de recurso
que n˜ao pode ser inclu´ıdo diretamente no modelo ´e continua¸c˜ao de primeira classe.
Outra dificuldade do modelo ´e que, apesar de conseguir abstrair elementos de contexto tais
como stores e environments, as continua¸c˜oes n˜ao s˜ao completamente abstra´ıdas, como pode
ser visto na defini¸c˜ao da semˆantica da linguagem Pascal (Mosses and Watt 1993). Nessa
defini¸c˜ao, a presen¸ca do comando goto interfere nas equa¸c˜oes semˆanticas de comandos,
pois, em vez da a¸c˜ao execute comumente utilizada, ´e necess´ario o uso da a¸c˜ao jumpily
execute, que tem p or objetivo coletar os r´otulos da defini¸c˜ao e ativar a fun¸c˜ao execute. A
Figura 3.7 mostra as defini¸c˜oes do comando condicional if-then-else por meio de semˆantica
de a¸c˜oes, na ausˆencia e na presen¸ca do comando goto. Estas defini¸c˜oes foram extra´ıdas
respectivamente das defini¸c˜oes das linguagens JOOS (Watt 1997) e Pascal (Mosses and
Watt 1993). Apesar de n˜ao fazer muita diferen¸ca na legibilidade da defini¸c˜ao, percebe-se
que existe uma limita¸c˜ao em rela¸c˜ao ao re´uso, uma vez que, apesar de tratarem a mesma
constru¸c˜ao, as duas defini¸c˜oes s˜ao distintas em raz˜ao da existˆencia de comando goto em
uma das linguagens definidas.
3.2.2 Semˆantica de Mˆonadas
A semˆantica de mˆonadas teve in´ıcio com os trabalhos de Moggi (1989, 1991), nos quais
durante a interpreta¸c˜ao de uma linguagem de programa¸c˜ao em uma categoria C (ver Fi-
gura 3.8), distinguem-se dois objetos: A, representando o dom´ınio dos valores, e T A,
que representa o dom´ınio das computa¸c˜oes de valores. Neste contexto, a denota¸c˜ao de
programas ´e um elemento de T A. Assim, uma vez identificado o tipo A dos valores de
uma computa¸c˜ao, o objeto de computa¸c˜ao ´e obtido aplicando-se o transformador T a A.
O construtor T ´e denominado no¸c˜ao de computa¸c˜ao, uma vez que abstrai os tipos de valo-
res que a computa¸c˜ao pode produzir. A Figura 3.9 mostra alguns exemplos de no¸c˜oes de
computa¸c˜ao comuns em defini¸c˜oes de semˆantica denotacional, extra´ıdas de Moggi (1991).
Intuitivamente, uma mˆonada para Moggi (1989, 1991) consiste em um trio (T, η, µ), tal
que T ´e uma no¸c˜ao de computa¸c˜ao, η
A
: A → T A ´e um operador de inclus˜ao de valores
em computa¸c˜oes, e µ
A
: T
2
A → T A ´e um operador de composi¸c˜ao de computa¸c˜oes.
O ponto forte deste modelo consiste no fato de que uma vez que uma no¸c˜ao de computa¸c˜ao
T pode incorporar estados, continua¸c˜oes e erros, pode-se aumentar o grau de modularidade
por meio da abstra¸c˜ao destes elementos das assinaturas das fun¸c˜oes semˆanticas.
3.2. MODULARIDADE EM SEM
ˆ
ANTICA DENOTACIONAL 43
(a) Semˆantica do comando if-then-else na ausˆencia do comando goto:
execute [[ “if” E : Expr “then” S
1
“else” S
2
]] =
evaluate E then
check (the given value is true) then execute S
1
and
check (the given value is false) then execute S
2
(b) Semˆantica do comando if-then-else na presen¸ca do comando goto:
execute [[ “if” E : Expr “then” S
1
“else” S
2
]] =
evaluate E then
check (the given value is true) then jumpily execute S
1
and
check (the given value is false) then jumpily execute S
2
Figura 3.7: Defini¸c˜ao em semˆantica de a¸c˜oes do comando condicional if-then-else: (a) na
ausˆencia de comando goto – e xtra´ıdo de Watt (1997); (b) na presen¸ca do comando goto –
extra´ıdo de Mosses and Watt (1993).
A partir dos trabalhos de Moggi, Wadler (1990) propˆos uma nova t´ecnica para estrutura¸c˜ao
de programas em linguagens func ionais baseado no conceito de mˆonadas. Os resultados
mais importantes da aplica¸c˜ao de mˆonadas nesse trabalho foi uma forma de encapsular
conceitos impuros em linguagens funcionais – em especial, entrada/sa´ıda e estados –, al´em
de permitir a unifica¸c˜ao de propostas anteriores de incorp ora¸c˜ao de v´arios recursos em
linguagens funcionais, dentre os quais se destacam estados, exce¸c˜oes e n˜ao-determinismo. A
incorpora¸c˜ao de forma transparente de entrada e sa´ıda e recursos inerentemente imperativos
em linguagens funcionais ´e mostrada por Jones and Wadler (1993), Wadler (1997), com
exemplos na linguagem Haskell.
Em outro trabalho, Wadler (1992) estende as propostas de Moggi, mostrando como es-
truturar em linguagem funcional um interpretador para uma linguagem de programa¸c˜ao
simples, utilizando uma mˆonada para representar a computa¸c˜ao de um valor. As prin-
cipais contribui¸c˜oes desta proposta s˜ao uma nomenclatura simples para represe nta¸c˜ao de
mˆonadas (ver Figura 3.10) e uma t´ecnica incremental de escrita de um interpretador. Nesta
44 CAP
´
ITULO 3. MODULARIDADE DA SEM
ˆ
ANTICA DENOTACIONAL
Uma categoria ´e uma sˆextupla C = Ob j
C
, Mor
C
, ∂
0
, ∂
1
, ι, ◦, onde:
• Obj
C
´e uma cole¸c˜ao de elementos denominados objetos;
• Mor
C
´e um conjunto de morfismos entre objetos de Obj
C
;
• ∂
0
e ∂
1
s˜ao opera¸c˜oes sobre morfismos denominadas dom´ınio e
contra-dom´ınio, respectivamente; quando ∂
0
(f) = A e ∂
1
(f) = B,
ent˜ao e screve-se f : A → B;
• ◦ : Mor
C
× Mor
C
→ Mor
C
´e uma opera¸c˜ao ass ociativa de com-
posi¸c˜ao de morfismos, de modo que a cada par de morfismos
f : A → B, g : B → C, existe um morfismo g ◦ f : A → C;
• ι ´e uma opera¸c˜ao denominada identidade, tal que para cada objeto
X ∈ Obj
C
, existe um morfismo ι
X
: X → X ∈ Mor
C
, que satisfaz a
propriedade:
∀f : A → B ∈ Mor
C
: f ◦ ι
A
= ι
B
◦ f = f
Figura 3.8: Defini¸c˜ao de uma categoria, extra´ıda de Menezes and Haeusler (2001). Para
referˆencias adicionais a respeito da teoria de categorias, recomendam-se: Fokkinga (1992),
Fokkinga and Meertens (1994), Shutt (2003).
t´ecnica, novos recursos s˜ao adicionados `a linguagem alterando-se a mˆonada que representa
a computa¸c˜ao, sendo necess´ario alterar um ´unico ponto do programa para incorporar esta-
dos, ambientes e continua¸c˜oes. As Figuras 3.11 e 3.12 contˆem um extrato do interpretador
definido por Wadler e a incorpora¸c˜ao de alguns recursos ao interpretador. Em Wadler
(1995), estas ideias s˜ao estendidas, mostrando-se como incorporar de forma transparente
parsers e arranjos em linguagens funcionais.
Os trabalhos de Jones and Duponcheel (1993), King and Wadler (1993), Steele Jr. (1994)
foram baseados na percep¸c˜ao de que apesar de mˆonadas serem um recurso de abstra¸c˜ao
interessante na defini¸c˜ao da semˆantica de linguagens, havia uma dificuldade em se utilizar
mais de uma mˆonada em uma mesma defini¸c˜ao. Por exemplo, para se compˆor as mˆonadas
de estado e continua¸c˜ao era necess´aria a escrita de uma nova mˆonada, totalmente indepen-
dente das j´a existentes, diminuindo significativamente o potencial de re´uso do modelo.
3.2. MODULARIDADE EM SEM
ˆ
ANTICA DENOTACIONAL 45
Exemplos de no¸c˜oes de computa¸c˜ao:
• n˜ao-termina¸c˜ao: T A = A
⊥
= A + {⊥}, onde ⊥ ´e a computa¸c˜ao
divergente;
• n˜ao-determinismo: T A = P(A);
• efeitos colaterais: T A = S → (A × S);
• exce¸c˜oes: T A = A + E, onde E ´e o conjunto das exce¸c˜oes;
• continua¸c˜oes: T A = (A → R) → R, onde R ´e o conjunto das
respostas;
• entrada interativa: T A = µ (λγ.A + (U → γ)), onde µ ´e o opera-
dor de ponto fixo;
• sa´ıda interativa: T A = µ (λγ.A + (U × γ)).
Figura 3.9: No¸c˜oes de computa¸c˜ao definidas por Moggi (1991). Variando-se a no¸c˜ao de
computa¸c˜ao, isto ´e, o construtor de tipos T , pode-se alterar os dom´ınios das denota¸c˜oes de
cada constru¸c˜ao lingu´ıstica.
Este problema foi resolvido inicialmente por Espinosa (1995) na t´ecnica denominada Se-
mantic Lego . Nesse trabalho, Espinosa prop˜oe transformadores de mˆonadas, e oferece
um mecanismo incremental de defini¸c˜ao da mˆonada subjacente `a defini¸c˜ao semˆantica.
Um transformador de mˆonadas ´e um par (t, lift), tal que t ´e um construtor de tipos e
lift : m a → t m a ´e uma opera¸c˜ao que transforma uma mˆonada m em uma nova mˆonada
t m. A proposta original foi estendida por Liang (1997), Liang et al. (1995), que forma-
lizaram o modelo e propuseram um arcabou¸co completo de escrita de defini¸c ˜ao semˆantica
execut´avel para uso na linguagem Haskell.
Os principais transformadores propostos por Liang et al. (1995) s˜ao os seguintes:
• transformador de estados:
typ e StateT s m a = s → m (s, a)
• transformador de erros:
typ e Err a = Ok a | Err String
46 CAP
´
ITULO 3. MODULARIDADE DA SEM
ˆ
ANTICA DENOTACIONAL
Uma mˆonada ´e uma tripla (M, return, >>=), em que M ´e um construtor
de tipos, e return e >>= s˜ao fun¸c˜oes polim´orficas com assinaturas:
return :: a → M a
>>= :: M a → (a → M b) → M b
e que satisfazem as seguintes propriedades:
Left unit: (return a) >>= k = k a
Right unit: m >>= return = m
Associatividade: m >>= (λa.(k a) >>= (λb.h b))
= (m >>= (λa.(k a)) >>= (λb.h b)
Os constituintes de uma mˆonada neste modelo s˜ao mapeados diretamente
no modelo proposto por Moggi, de modo que M corresponde `a no¸c˜ao de
computa¸c˜ao T , return corresponde ao transformador η e >>= corresponde
a µ.
Figura 3.10: Defini¸c˜ao de mˆonadas de acordo com Wadler (1992). A nomenclatura utili-
zada ´e baseada em Liang et al. (1995).
typ e ErrT m a = m (Err a)
• transformador de environments:
typ e EnvT r m a = r → m a
• transformador de continua¸c˜oes:
typ e ContT c m a = (a → m c) → m c
Assim, a mˆonada utilizada na especifica¸c˜ao das equa¸c˜oes semˆanticas passa a ser a seguinte:
type M a = EnvT Env −− environments
(ContT Answer −− contina¸c˜oes
(StateT Store −− stores
(StateT IO −− entrada e sa´ıda
ErrT))) a −− tratamento de erros
Uma consequˆencia do mecanismo de transformadores de mˆonadas ´e abordada por Liang
and Hudak (1996), em que gera¸c˜ao de c´odigo em um compilador ´e generalizado por meio da
defini¸c˜ao de uma mˆonada padr˜ao com um conjunto de combinadores primitivos, mape´aveis
diretamente para a linguagem do c´odigo gerado. Os trabalhos de Harrison and Kamin
3.2. MODULARIDADE EM SEM
ˆ
ANTICA DENOTACIONAL 47
Equa¸c˜oes semˆanticas:
type Environment = [(Name,Value)]
interp :: Term → Environment → M Value
interp (Var x) e = lookup x e
interp (Con i) e = return (Num i)
interp (Add u v) e = interp u e >>= \a → interp v e
>>= \b → add a b
interp (Lam x v) e = return (Fun (\a → interp v ((x,a):e)))
interp (App t u) e = interp t e >>= \f → interp u e
>>= \a → apply f a
Figura 3.11: Exemplo de interpretador escrito em linguagem Haskell, utilizando mˆonadas
– extra´ıdo de Wadler (1992).
(2000, 1998) tamb´em utilizam transformadores de mˆonadas para a gera¸c˜ao de compiladores,
mas diferentemente de Liang and Hudak (1996), o processo de gera¸c˜ao de compiladores
consiste em aplicar avalia¸c˜ao parcial (Jones et al. 1993) no programa do interpretador.
Ivanovi´c and Kuncak (2000) proveem uma forma de defini¸c˜ao modular de sintaxe e semˆantica
de uma linguagem utilizando Haskell e semˆantica de mˆonadas. A t´ecnica aplicada nesse
trabalho ´e a modulariza¸c˜ao em duas dimens˜oes: as fases de compila¸c˜ao, isto ´e, an´alises
l´exica, sint´atica e semˆantica; e as constru¸c˜oes da linguagem. A t´ecnica proposta consiste
em um conjunto de diretrizes para a implementa¸c˜ao r´apida de prot´otipos de linguagens,
permitindo a sua execu¸c˜ao para depura¸c˜ao. Al´em disso, a escrita da especifica¸c˜ao ´e in-
cremental, de modo que a cada nova constru¸c˜ao lingu´ıstica, cria-se um m´odulo que define
seus elementos l´exicos, sint´aticos e semˆanticos.
A semˆantica de mˆonadas ´e um modelo computacional bastante poderoso e oferece meios
para se abstrair stores, environments e continua¸c˜oes, muitas vezes indesej´aveis nas equa¸c˜oes
semˆanticas. Al´em disso, o modelo ´e completamente denotacional, de modo que a possibi-
lidade de se provar propriedades da especifica¸c˜ao ´e compartilhado pelas duas t´ecnicas.
Por outro lado, o poder de express˜ao deste modelo depende da forma como os transfor-
madores de mˆonadas s˜ao combinados. Como destacado por Liang et al. (1995), algumas
opera¸c˜oes de lift sobre fun¸c˜oes b´asicas n˜ao pode m ser feitas de forma autom´atica, sendo
necess´ario um tratamento caso a caso em diversas situa¸c˜oes. No pior caso, para n trans-
48 CAP
´
ITULO 3. MODULARIDADE DA SEM
ˆ
ANTICA DENOTACIONAL
Exemplos de Mˆonadas:
• Mˆonada de estado:
type M a = State → (a, State)
return a = \s0 → (a, s0)
m >>= k = \s0 → let (a,s1) = m s0 in k a s1
• Mˆonada de estado:
type M a = (a −> Answer) −> Answer
return a = \c −> c a
m >>= k = \c −> m (\a −> k a c)
Figura 3.12: Exemplos de mˆonadas para o interpretador escrito em linguagem Haskell da
Figura 3.11.
formadores de mˆonadas, pode ser necess´ario especificar O(n
2
) opera¸c˜oes ad-hoc de lift.
Segundo Liang et al. (1995), isto n˜ao constitui um grande problema, pois o n´umero de
transformadores utilizados na pr´atica ´e relativamente pequeno; no entanto, mostra que a
escalabilidade do modelo ´e comprometida.
3.2.3 Semˆantica de A¸c˜oes com Mˆonadas
A semˆantica de a¸c˜oes com mˆonadas foi proposta por Wansbrough and Hamer (1997) e ´e
uma fus˜ao da semˆantica de mˆonadas de Liang et al. (1995) e da semˆantica de a¸c˜oes de Mos-
ses (1993). Nesse formalismo, a semˆantica de cada constru¸c˜ao lingu´ıstica ´e uma se quˆe ncia
de a¸c˜oes, definidas por meio de semˆantica de mˆonadas, e n˜ao por meio de semˆantica ope-
racional estruturada.
Segundo Wansbrough and Hamer (1997), Zhang and Xu (2004), esse modelo compartilha
as principais vantagens das semˆantica de a¸c˜oes e de mˆonadas: as defini¸c˜oes semˆanticas s˜ao
leg´ıveis, uma vez que a nota¸c˜ao utilizada ´e a mesma da semˆantica de a¸c˜oes; por utilizar
a semˆantica de mˆonadas, a defini¸c˜ao da nota¸c˜ao de a¸c˜oes fica modularizada, diferente da
defini¸c˜ao monol´ıtica oferecida pela semˆantica operacional estruturada; a inclus˜ao de novas
3.2. MODULARIDADE EM SEM
ˆ
ANTICA DENOTACIONAL 49
no¸c˜oes de computa¸c˜ao pode ser feita por meio dos mecanismos apresentados por Liang
et al. (1995), o que torna o modelo mais flex´ıvel que a semˆantica de a¸c˜oes; o racioc´ınio
equacional ´e proporcionado pela base matem´atica subjacente `a semˆantica denotacional e
`a semˆantica de mˆonadas.
Entretanto, de acordo com Wansbrough and Hamer (1997), ao substituir a semˆantica
operacional estrutura pela semˆantica de mˆonadas, limita-se o poder da semˆantica de a¸c˜oes,
tornando invi´avel lidar com m´ultiplos processos que se comuniquem. Al´em disso, no modelo
original de Mosses ´e poss´ıvel que a semˆantica de um programa n˜ao-determinista seja o
conjunto de todas as poss´ıveis respostas geradas pelo programa.
3.2.4 Gram´aticas de Atributos de Primeira Classe
de Moor et al. (2000) prop˜oem uma t´ecnica orientada por aspectos para melhorar a mo-
dularidade de gram´aticas de atributos, que pode ser aplicada a defini¸c˜oes semˆanticas. No
modelo apresentado, atributos podem ser definidos em se¸c˜oes separadas e podem ser in-
tercalados para formar uma gram´atica de atributos pura. Estas se¸c˜oes permitem que a
defini¸c˜ao de um atributo indique a forma como ele se comporta ao longo da especifica¸c˜ao,
podendo ser sintetizado, herdado ou transmitido automaticamente ao longo de uma cadeia
de defini¸c˜oes recursivas.
O suporte de aspectos na defini¸c˜ao de atributos permite, por exemplo, a cria¸c˜ao de de-
fini¸c˜ao para repeti¸c˜ao que ´e vaga em rela¸c˜ao a sequenciadores. No entanto, intera¸c˜oes entre
constru¸c˜oes lingu´ısticas pode precisar de informa¸c˜oes que n˜ao est˜ao dispon´ıveis para de-
fini¸c˜ao do atributo, especialmente quando forem desacopladas da estrutura sint´atica. Por
exemplo, a rela¸c˜ao entre chamadas de m´etodos e tratamento de exce¸c˜oes em uma lingua-
gem orientada por objetos t´ıpica n˜ao pode ser expressa diretamente por meio de atributos
herdados, sintetizados ou encadeados, uma vez que em geral n˜ao h´a rela¸c˜ao sint´atica entre
estas constru¸c˜oes em um programa t´ıpico.
3.2.5 Semˆantica Construtiva
Reusabilidade pode ainda ser obtida por meio da abordagem construtiva proposta por
Mosses (2005). Essa abordagem parte do pressuposto que uma linguagem pode ser definida
como a combina¸c˜ao de um conjunto representativo de constru¸c˜oes b´asicas abstratas, que
s˜ao formalmente definidas. Assim, a semˆantica das diversas constru¸c˜oes de uma linguagem
50 CAP
´
ITULO 3. MODULARIDADE DA SEM
ˆ
ANTICA DENOTACIONAL
pode ser traduzida nestas abstra¸c˜oes, sendo poss´ıvel a defini¸c˜ao direta da semˆantica da
linguagem.
Por exemplo, sequenciadores podem ser definidos como exce¸c˜oes a serem tratadas por meio
de um mecanismo de tratamento de exce¸c˜oes associado aos comandos de repeti¸c˜ao. No
entanto, como resultado, elementos para tratamento de sequenciadores podem permanecer
entrela¸cados `a defini¸c˜ao de repeti¸c˜oes, o que pode trazer prematuramente a preocupa¸c˜oes
sobre o efeito de tais exce¸c˜oes.
3.3 Conclus˜oes
A especifica¸c˜ao da semˆantica formal ´e um campo de pesquisa bastante relevante, moti-
vado especialmente pelo pontencial de aplica¸c˜oes poss´ıveis. Entretanto, ao contr´ario da
especifica¸c˜ao formal da sintaxe, que ´e amplamente utilizada em diversas sub-´areas da
Computa¸c˜ao, h´a grandes barreiras `a populariza¸c˜ao das t´ecnicas de especifica¸c˜ao formal
da semˆantica de linguagens de programa¸c˜ao.
Dentre os principais dificultadores encontra-se o fato de que nenhum dos modelos vigentes
tenha se consolidado, oferecendo um arcabou¸co de uso pr´atico e te´orico. Em particular, o
baixo grau de modularidade que se obt´em nos diversos modelos dificulta a escrita de novas
defini¸c˜oes e o seu uso para a prova de propriedades.
Do ponto de vista da apresenta¸c˜ao de uma linguagem, uma caracter´ıstica desej´avel ´e definir
uma ordem de leitura na qual, a partir de defini¸c˜oes mais simples, o leitor ´e levado suces-
sivamente a n´ıveis de maior complexidade, at´e chegar `a compreens˜ao de toda a linguagem.
No entanto, nas t´ecnicas vigentes, as equa¸c˜oes semˆanticas tendem a n˜ao ser coesas, uma
vez que a defini¸c˜ao de uma constru¸c˜ao pode conter muitos detalhes relacionados a outras
constru¸c˜oes. Neste caso, a leitura tende a ser mais dif´ıcil, pois n˜ao h´a uma ordem para
a leitura que leve o aprendiz de um n´ıvel mais simples para um n´ıvel de maior complexi-
dade. Com efeito, encontram-se dificuldades relacionadas `a apresenta¸c˜ao para as t´ecnicas
de defini¸c˜ao de semˆantica denotacional vigentes.
As t´ecnicas de se mˆantica de a¸c˜oes e semˆantica de a¸c˜oes com mˆonadas definem um vo-
cabul´ario mais rico para especifica¸c˜ao da semˆantica, permitindo que o uso de elementos
prosaicos, tais como stores e environments, sejam abstra´ıdos nas equa¸c˜oes semˆanticas. No
entanto, n˜ao ´e poss´ıvel separar as equa¸c˜oes semˆanticas para as diversas constru¸c˜oes. Com
isso, n˜ao ´e poss´ıvel derivar uma ordem de leitura sugerida para a defini¸c˜ao. Por exemplo,
3.3. CONCLUS
˜
OES 51
em ambas as t´ecnicas, a defini¸c˜ao de um comando de repeti¸c˜ao deve levar em considera¸c˜ao
a existˆencia de poss´ıveis sequenciadores que levem ao t´ermino abrupto das itera¸c˜oes.
Em semˆantica de mˆonadas, as fun¸c˜oes semˆanticas mapeiam cada constru¸c˜ao em uma com-
puta¸c˜ao de valores, de modo que a forma como a computa¸c˜ao ´e definida pode evoluir
durante a apresenta¸c˜ao. No entanto, a quest˜ao da separa¸c˜ao de constru¸c˜oes ainda n˜ao ´e
resolvida, o que leva a equa¸c˜oes semˆanticas n˜ao-coesas, de maneira semelhante `a Semˆantica
de A¸c˜oes. Com isso, ainda existe o entrela¸camento de defini¸c˜oes, o que pode dificultar en-
contrar uma ordem de leitura para as equa¸c˜oes semˆanticas. Por exemplo, o t´ermino abrupto
de repeti¸c˜oes por meio de sequenciadores deve tamb´em ser levado e m considera¸c˜ao ao se
especificar comandos de repeti¸c˜ao.
A t´ecnica de gram´aticas de atributos de primeira classe ´e um passo `a frente na solu¸c˜ao deste
problema, uma vez que permite a defini¸c˜ao separada da intera¸c˜ao entre constru¸c˜oes que
possuam rela¸c˜ao de hie rarquia na ´arvore de sintaxe abstrata de um programa. No entanto,
a t´ecnica n˜ao ´e apropriada quando a comunica¸c˜ao se d´a de maneira independente da ´arvore,
como por exemplo, no retorno abrupto de fun¸c˜ao devido a lan¸camento de exce¸c˜oes.
Uma abordagem diferente para o problema ´e a semˆantica construtiva, em que as cons-
tru¸c˜oes de uma linguagem de programa¸c˜ao s˜ao definidas como combina¸c˜oes de um con-
junto de constru¸c˜oes padr˜ao de uma linguagem base. Neste caso, o leitor deve inicialmente
compreender algumas constru¸c˜oes da linguagem base, pois as equa¸c˜oes semˆanticas da lin-
guagem em estudo consistem na tradu¸c˜ao de cada constru¸c˜ao e m uma combina¸c˜ao de
constru¸c˜oes da linguagem base. Esta t´ecnica permite a leitura de um n´ıvel mais simples
para n´ıveis mais sofisticados, mas ainda n˜ao permite a defini¸c˜ao separada de constru¸c˜oes
mais elementares da pr´opria linguagem.
O pr´oximo cap´ıtulo apresenta a t´ecnica de semˆantica incremental, que ´e a principal con-
tribui¸c˜ao deste trabalho de Tese. A t´ecnica proposta permite que o projetista apresente
uma especifica¸c ˜ao inicial vaga da linguagem, em que detalhes e constru¸c˜oes mais comple-
xas possam ser ignorados. Para permitir extens˜oes lingu´ısticas, a linguagem de defini¸c˜ao
permite que as denota¸c˜oes de constru¸c˜oes j´a definidas evoluam de maneira uniforme, de
modo que novas constru¸c˜oes possam ser adicionadas. Al´em disso, a forma como a de-
fini¸c˜ao incremental ´e feita n˜ao impede que se utilizem as contribui¸c˜oes das demais t´ecnicas
de modularidade de semˆantica denotacional existentes.
Com as t´ecnicas existentes, se o projetista desejar apresentar vers˜oes iniciais mais s imples
ao leitor, torna-se necess´ario criar e entregar-lhe v´arias vers˜oes de um ´unico documento,
em que todas as constru¸c˜oes s˜ao novamente definidas. Na t´ecnica proposta neste trabalho,
52 CAP
´
ITULO 3. MODULARIDADE DA SEM
ˆ
ANTICA DENOTACIONAL
o projetista pode entregar um ´unico documento que apresenta vers˜oes simplificadas das
constru¸c˜oes e como estas evoluem para que novas constru¸c˜oes possam ser acrescentadas.
Cap´ıtulo 4
Semˆantica Incremental
Este cap´ıtulo apresenta a metodologia desenvolvida como parte da solu¸c˜ao para os pro-
blemas levantados nos cap´ıtulos anteriores, apresentada resumidamente por Tirelo et al.
(2009). A premissa desta abordagem consiste no conjunto de vantagens que se obtˆem se
defini¸c˜oes da semˆantica de linguagens de programa¸c˜ao forem apresentadas de maneira in-
cremental, uma vez que tais defini¸c˜oes s˜ao geralmente sistemas muito grandes e complexos.
Desta maneira, a partir de uma defini¸c˜ao existente da linguagem, seria desej´avel que novas
constru¸c˜oes pudessem ser definidas sobre as equa¸c˜oes j´a existentes.
O cen´ario imaginado no desenvolvimento deste trabalho consiste em um projetista (espe-
cialista) de linguagem que tenta desenvolver uma vers˜ao leg´ıvel da especifica¸c˜ao semˆantica
para um leitor (n˜ao-especialista).
´
E foco do trabalho do projetista encontrar a maneira
mais clara de apresentar as constru¸c˜oes ao leitor, e, por isso, o trabalho de reescrita de
constru¸c˜oes j´a definidas ´e muitas vezes prefer´ıvel, se isso facilitar posteriormente a com-
preens˜ao de constru¸c˜oes mais avan¸cadas. Do ponto de vista do leitor, o documento gerado
apresenta inicialmente vers˜oes simplificadas das constru¸c˜oes fundamentais de sua lingua-
gem, que posteriormente evoluem para vers˜oes mais completas e que englobem todos os
aspectos de seu funcionamento.
Utilizando as t´ecnicas existentes, o projetista consegue esse efeito fornecendo vers˜oes com-
pletas da especifica¸c˜ao, em que cada equa¸c˜ao semˆantica pode ser totalmente redefinida.
Na t´ecnica proposta, tem-se por objetivo permitir que o projetista forne¸ca um ´unico do-
cumento, no qual a denota¸c˜ao de cada constru¸c˜ao seja inicialmente definida de maneira
simplificada (ou vaga) e evolua `a medida que novas constru¸c˜oes sejam adicionadas.
53
54 CAP
´
ITULO 4. SEM
ˆ
ANTICA INCREMENTAL
Organiza¸c˜ao do Cap´ıtulo. A Se¸c˜ao 4.1 discute aspectos essenciais de uma defini¸c˜ao
incremental e a importˆancia da vagueza, conceito fundamental `a metodologia proposta. A
Se¸c˜ao 4.2 apresenta a forma geral de uma defini¸c˜ao incremental segundo o modelo proposto.
A Se¸c˜ao 4.3 elabora os mecanismos lingu´ısticos utilizados para defini¸c˜ao incremental. A
Se¸c˜ao 4.4 apresenta a formaliza¸c˜ao do modelo prop osto. A Se¸c˜ao 4.5 cont´em estudos de
caso com o intuito de se verificar a aplicabilidade da t´ecnica a linguagens de grande porte
e da teoria subjacente baseada em semˆantica denotacional c l´assica e semˆantica mon´adica.
Finalmente, a Se¸c˜ao 4.6 apresenta as conclus˜oes do cap´ıtulo.
4.1 Vagueza e Legibilidade
Neste trabalho, utiliza-se a vagueza como mecanismo de melhoria da legibilidade das de-
fini¸c˜oes semˆanticas. Esta ideia se baseia em uma pr´atica muito usual por parte de profes-
sores de programa¸c˜ao, que consiste em abstrair conceitos avan¸cados durante a explica¸c˜ao
de conceitos b´asicos. Em um momento futuro, a introdu¸c˜ao destes conceitos avan¸cados
pode exigir a adequa¸c˜ao dos conceitos previamente apresentados, sem no entanto implicar
na completa quebra de sua natureza b´asica. Tal explica¸c˜ao vaga ´e adequada naquele con-
texto porque em geral requer menos esfor¸co do aprendiz para o entendimento dos conceitos
lingu´ısticos.
Tal pr´atica ´e tamb´em amplamente utilizada em livros e manuais de linguagens de pro-
grama¸c˜ao, onde ao se introduzir um novo conceito, basta explicar como to do o corpo de
conhecimento j´a adquirido deve ser repensado para se adequar aos novos conceitos. Por
exemplo, na defini¸c˜ao de uma linguagem orientada por objetos t´ıpica, considere que o
cap´ıtulo onde se explicam m´etodos anteceda o cap´ıtulo correspondente a tratamento de
exce¸c˜oes; ´e plenamente poss´ıvel explicar m´etodos sem mencionar tratamento de exce¸c˜oes,
apesar de amb os compartilharem contexto comum. Neste caso, a defini¸c˜ao de m´etodos
n˜ao pode ser considerada incorreta, pois o programador pode construir uma s´erie de pro-
gramas corretos sem se preocupar naquele primeiro momento com a forma com que casos
excepcionais devam ser tratados. A apresenta¸c˜ao pode ser feita de maneira incremental,
fornecendo-se defini¸c˜oes vagas em rela¸c˜ao a conceitos ainda n˜ao explorados, a¸c˜ao em que
se espera que o aprendiz adquira experiˆencia em conceitos b´asicos antes de estudar aqueles
mais avan¸cados.
Por´em, no momento da explica¸c˜ao dos conceitos mais avan¸cados, pode ser necess´ario rever
os conceitos b´asicos sob uma nova ´otica, pois o contexto fornecido pelas explica¸c˜oes vagas
4.1. VAGUEZA E LEGIBILIDADE 55
anteriores pode ser insuficiente para as novas defini¸c˜oes. No exemplo anterior, a explica¸c˜ao
de tratamento de exce¸c˜oes exige explicar que o retorno de um m´etodo pode passar pela
execu¸c˜ao do corpo de cl´ausula finally, antes do retorno ao ponto de chamada. Vale ressaltar
no entanto que esta reinterpreta¸c˜ao consiste na escrita de alguns p oucos par´agrafos e n˜ao
na reescrita completa dos cap´ıtulos anteriores. No texto informal, tais reinterpreta¸c˜oes
podem ser feitas de diversas maneiras, com destaque para algumas t´aticas, que s˜ao as
tratadas neste trabalho de Tese dentro do contexto de m´e todos formais.
A primeira t´atica consiste na defini¸c˜ao de um novo elemento associado a diversas cons-
tru¸c˜oes da linguagem com influˆencia direta em algumas poucas constru¸c˜oes. Por exemplo,
considere a defini¸c˜ao de sequenciador break ap´os a defini¸c˜ao de comandos de repeti¸c˜ao
em uma linguagem imperativa t´ıpica. O ponto de desvio do sequenciador ´e definido pelo
comando de repeti¸c˜ao para ser utilizado somente na defini¸c˜ao do sequenciador; todos os
demais comandos da linguagem, tais como comandos condicionais, ignoram este valor e
simplesmente o propagam para seus sub-comandos.
Outra t´atica usual ´e a redefini¸c˜ao de valores propagados pelas constru¸c˜oes para seus consti-
tuintes. No exemplo anterior de defini¸c˜ao de sequenciadores ap´os a defini¸c˜ao de comandos
de repeti¸c˜ao, pode-se considerar que o ambiente de execu¸c˜ao de comandos mapeia uma
posi¸c˜ao especial no ponto de desvio do sequenciador.
Al´em destas duas t´aticas, pode-se considerar ainda que valores compostos produzidos du-
rante a computa¸c˜ao incorporem informa¸c˜oes adicionais. Por exemplo, considere a defini¸c˜ao
semˆantica da linguagem Java, em que a hierarquia de tipos ´e explicada ap´os a apresenta¸c˜ao
de arranjos de objetos na linguagem; erros como o da Figura 4.1 n˜ao podem ser detectados
na semˆantica est´atica, e para detect´a-los, pode-se considerar que cada express˜ao do lado
esquerdo de uma atribui¸c˜ao carregue consigo o tipo mais alto na hierarquia que pode ser
atribu´ıdo.
No contexto de defini¸c˜oes informais, a vagueza, aliada a um mecanismo de reinterpreta¸c˜ao
de conceitos anteriormente definidos, ´e recurso essencial `a escrita de explica¸c˜oes incremen-
tais leg´ıveis.
Ao contr´ario, especifica¸c˜oes de semˆantica denotacional possuem um ´unico conjunto de
equa¸c˜oes que fornecem um ´unico mapeamento do universo sint´atico no universo semˆantico,
e, por isso, a especifica¸c˜ao de uma constru¸c˜ao n˜ao pode ser fornecida em etapas. Assim,
dois cen´arios t´ıpicos podem ser vislumbrados tendo como atores o projetista da linguagem
e o leitor da especifica¸c˜ao.
56 CAP
´
ITULO 4. SEM
ˆ
ANTICA INCREMENTAL
1 // Consider A superclass of B
2 A f(int x) {
3 if (x >= 0) return new B();
4 else return new A();
5 }
6 ...
7 int y = ...;
8 A arr [] = new B[10];
9 arr [0] = f(y ); // If y < 0, an execution error is issued
Listagem 4.1: Interdependˆencia de Arranjos de Objetos e Hierarquia de Tipos em Java
No primeiro, o projetista far´a a defini¸c˜ao incremental da linguagem e fornecer´a somente
a vers˜ao final ao le itor. Do ponto de vista do projetista, e ssa atividade pode requerer a
reescrita de diversas equa¸c˜oes principalmente quando as altera¸c˜oes necess´arias exigirem,
por exemplo, a inclus˜ao de um novo argumento em algumas equa¸c˜oes. Do ponto de vista
do leitor, a defini¸c˜ao fornecida pode s er bastante confusa e com diversos elementos in-
trusos e espalhados nas equa¸c˜oes. Tome, por exemplo, a defini¸c˜ao denotacional de uma
linguagem orientada por objetos t´ıpica contendo m´etodos e tratamento de exce¸c˜oes. Uma
forma de definir as constru¸c˜oes correspondentes consiste no seguinte conjunto de equa¸c˜oes
semˆanticas, onde os elementos destacados s˜ao intrusos nas equa¸c˜oes:
• C[[try C
1
catch I C
2
finally C
3
]]rc = C[[C
1
]]r
; C[[C
3
]]rc
where r
= r[k
R
, k
T
/return, throw]
k
R
= λv.C[[C
3
]]r; r return v
k
T
= ref; λl .C[[C
2
]]r

; C[[C
3
]]r; r throw v
r

= r[k
R
, k

T
, l/return, throw, I]
k
T

= λv.C[[C
3
]]r; r throw v
• C[[throw E]]rc = E[[E]]r; r throw
• D[[I
1
(I
2
) { C }]] ru = u r[f/I
1
]
where f = λk
R
k
T
.ref; λl.C[[C]] r
; k
R
novalue
r
= r[f, l, k
R
, k
T
/I
1
, I
2
, return, throw]
• C[[return E]]rc = E[[E]]r; r return
• E[[E
1
(E
2
)]]rk = E[[E
1
]]r; λf.E[[E
2
]]r; f k (r throw)
4.2. DEFINIC¸
˜
OES INCREMENTAIS 57
No segundo cen´ario, o projetista fornecer´a todas as especifica¸c˜oes intermedi´arias da lingua-
gem, e com isso o leitor pode estudar os conceitos fundamentais em um conjunto simplifi-
cado das equa¸c˜oes. Esta solu¸c˜ao ainda n˜ao ´e satisfat´oria, pois outro problema ainda mais
complexo pode ser vislumbrado tanto para o projetista quanto para o leitor. Do ponto
de vista do projetista, altera¸c˜oes feitas nas especifica¸c˜oes iniciais podem ser replicadas ao
longo de diversas vers˜oes do documento. Al´em disso, n˜ao h´a garantias de que as proprieda-
des v´alidas em uma especifica¸c˜ao continuem v´alidas na seguinte; esta garantia s´o pode ser
obtida a partir de argumenta¸c˜ao favor´avel para cada reifica¸c˜ao realizada. Do ponto de vista
do leitor, o trabalho de releitura das diversas equa¸c˜oes pode ser bastante trabalhoso, e a
evolu¸c˜ao das denota¸c˜oes pode ficar perdida no meio de um grande volume de dados. Al´em
disso, a reescrita de um grande n´umero de equa¸c˜oes continua uma exigˆencia em potencial,
mesmo para altera¸c˜oes simples.
A metodologia desenvolvida tem por objetivo permitir a especifica¸c˜ao incremental de lin-
guagens de programa¸c˜ao com recurso de vagueza. A t´ecnica subjacente ´e a usualmente
utilizada em livros de linguagens de programa¸c˜ao:
• primeiramente, apresentam-se em um primeiro cap´ıtulo os elementos mais fundamen-
tais para a escrita de um programa completo; em geral, tal defini¸c˜ao pode incluir o
conceito de programas, m´odulos, fun¸c˜oes, comandos b´asicos e express˜oes b´asicas;
• os cap´ıtulos subsequentes tˆem por objetivo agregar novos conceitos ao conjunto j´a
existente, o que por vezes pode exigir adequa¸c˜ao dos elementos j´a apresentados.
As pr´oximas se¸c˜oes deste cap´ıtulo apresentam os conceitos de especifica¸c˜ao semˆantica e de-
fini¸c˜ao incremental e apresenta os mecanismos lingu´ısticos propostos para permitir alcan¸car
adequado grau de incrementabilidade em defini¸c˜oes semˆanticas.
4.2 Defini¸c˜oes Incrementais
Uma defini¸c˜ao incremental da semˆantica de uma linguagem ´e uma sequˆencia S
0
, S
1
, · · · , S
n
,
onde cada S
i
´e a especifica¸c˜ao da semˆantica de um subconjunto da linguagem, tal que S
0
´e
uma especifica¸c˜ao inicial, e cada S
i+1
define uma extens˜ao de S
i
. Cada nova especifica¸c˜ao
pode adicionar novos elementos, mas por vezes pode ser necess´ario adaptar equa¸c˜oes previ-
amente de finidas. Dada uma especifica¸c˜ao S
i
, uma nova especifica¸c˜ao S
i+1
= t
i
(S
i
) + ∆S
i
pode ser obtida incluindo-se novos elementos (∆S
i
) a uma vers˜ao adaptada de S
i
por meio
de uma fun¸c˜ao de transforma¸c˜ao t
i
.
58 CAP
´
ITULO 4. SEM
ˆ
ANTICA INCREMENTAL
A transforma¸c˜ao t
i
´e uma fun¸c˜ao que mapeia especifica¸c˜oes semˆanticas em especifica¸c˜oes
semˆanticas e tem por objetivo adaptar o comportamento de equa¸c˜oes semˆanticas. Uma
inclus˜ao em uma especifica¸c˜ao S, denotada por ∆S, representa um conjunto de novos ele-
mentos adicionados `a especifica¸c˜ao, usualmente elementos relacionados a novas constru¸c˜oes
lingu´ısticas.
O exemplo explorado ao longo deste cap´ıtulo consiste em uma especific a¸c˜ao S
i
de uma
linguagem hipot´etica L, composta por express˜oes, comandos e declara¸c˜oes. A sintaxe
abstrata, as fun¸c˜oes semˆanticas e as equa¸c˜oes semˆanticas da especifica¸c˜ao S
i
para as cons-
tru¸c˜oes mais relevantes para a discuss˜ao s˜ao apresentadas na Figura 4.1. Nestas equa¸c˜oes
1
,
a defini¸c˜ao do comando while ´e vaga em rela¸c˜ao `a existˆencia de sequenciadores. No caso de
a especifica¸c˜ao S
i+1
definir o sequenciador break, torna-se necess ´ario adaptar, por meio da
transforma¸c˜ao t
i
, a equa¸c˜ao relativa ao comando while para preparar o contexto no qual
eventuais sequenciadores possam ser executados. As inclus˜oes correspondentes consistem,
desta maneira, em definir uma nova regra na gram´atica abstrata para o sequenciador break
e em uma nova equa¸c˜ao semˆantica que o defina.
O restante deste texto tratar´a das fun¸c˜oes de transforma¸c˜ao, que s˜ao a principal contri-
bui¸c˜ao deste trabalho. Outros tipos de inclus˜ao podem ser obtidos por meio de recursos
de modularidade usuais em linguagens de programa¸c˜ao modernas e, portanto, n˜ao ser˜ao
discutidos em profundidade. Apesar de o exemplo utilizado ser baseado em semˆantica de
continua¸c˜oes tradicional, a t´ecnica proposta ´e adequada ao uso com outros recursos de
melhoria de modularidade, tais como mˆonadas, conforme mostrado no estudo de caso da
Se¸c˜ao 4.5.2.
4.3 Fun¸c˜oes de Transforma¸c˜ao
Uma extens˜ao da linguagem pode afetar fun¸c˜oes e equa¸c˜oes semˆanticas existentes ao re-
querer que:
1. assinaturas de fun¸c˜oes sejam redefinidas para inclus˜ao de novos argumentos (Se¸c˜ao 4.3.1);
1
fix representa o operador de ponto fixo.
4.3. FUNC¸
˜
OES DE TRANSFORMAC¸
˜
AO 59
Abstract syntax:
P ∈ Prog → D; C
C ∈ Com → while E C | C
1
; C
2
| · · ·
E ∈ Exp → · · ·
D ∈ Dec → · · ·
Semantic Functions:
P : Prog → Ans
C : Com → Env → Cc → Cc
E : Exp → Env → (Val → Cc) → Cc
D : Dec → Env → (Env → Cc) → Cc
Semantic Equations:
P[[D; C]] = D[[D]] r
0
(λr.C[[C]] r (λs.stop)) s
0
C[[C
1
; C
2
]] r c = C[[C
1
]] r; C[[C
2
]] r c
C[[while E C]] r = fix λfc.E[[E]] r; λv.if v then C[[C]] r (f c) else c
Other equations defining C, E, and D
Figura 4.1: Exemplo utilizado na explica¸c˜ao dos transformadores – apenas constru¸c˜oes
relevantes `a discuss˜ao s˜ao apresentadas.
2. argumentos de fun¸c˜ao e valores de retorno sejam decorados
2
, no intuito de tratar si-
tua¸c˜oes n˜ao previstas ou adequar as equa¸c˜oes a altera¸c˜oes de assinatura (Se¸c˜ao 4.3.2);
3. algumas equa¸c˜oes sejam completamente redefinidas no caso de transforma¸c˜oes au-
tom´aticas n˜ao serem adequadas ou simples de definir (Se¸c˜ao 4.3.3).
Uma fun¸c˜ao ´e promovida por uma transforma¸c˜ao t se for suje ita a alguma modifica¸c˜ao
definida em t. Transforma¸c˜oes podem ser definidas por meio das seguintes constru¸c˜oes,
cujos constituintes s er˜ao definidos nas Se¸c˜oes 4.3.1-4.3.3:
transformation transformation-name
signature signature clauses
default default clauses
replace decoration clauses
redefine redefinition clauses
Dada uma especifica¸c˜ao S e uma transforma¸c˜ao t, S
= t(S) ´e definida em duas etapas:
a primeira coleta as transforma¸c˜oes que dever˜ao ser realizadas em cada fun¸c˜ao individu-
almente, produzindo uma sequˆencia t
1
, t
2
, · · · , t
m
, onde cada t
i
pode ser uma inclus˜ao
de argumento, uma decora¸c˜ao ou uma redefini¸c˜ao de equa¸c˜ao; o segundo passo aplica
2
Decora¸c˜ao possui o sentido estabelecido na defini¸c˜ao de padr˜oes de projeto por Gamma et al. (1995).
Na verdade, neste trabalho, uma decora¸c˜ao pode ser vista como a implementa¸c˜ao orientada por aspectos
deste padr˜ao por m eio de adendos de contorno (Kiczales et al. 1997).
60 CAP
´
ITULO 4. SEM
ˆ
ANTICA INCREMENTAL
cada transforma¸c˜ao a cada uma das fun¸c˜oes promovidas. A ordem de aplica¸c˜ao destas
transforma¸c˜oes ´e a ordem em que elas aparecem na sua defini¸c˜ao.
4.3.1 Inclus˜ao de Argumentos
A inclus˜ao de argumentos ´e feita por meio da cl´ausula signature, que possui o seguinte
formato:
signature f
1
: T
1
, f
2
: T
2
, · · · , f
m
: T
m
Nesta cl´ausula, cada fun¸c˜ao f
i
do tipo T
i
deve ser transformada em uma fun¸c˜ao cujo tipo
´e T
i
. Cada T
i
´e um tipo funcional com a forma t
1
→ t
2
→ · · · → t
n
, em que cada t
j
pode
ser uma express˜ao de tipos ou uma express˜ao de tipos rotulada, com a forma l : t, onde
l ´e um r´otulo e t ´e uma express˜ao de tipos. Tipos rotulados s˜ao utilizados para indicar
inclus˜ao de novos argumentos na fun¸c˜ao.
Uma cl´ausula de altera¸c˜ao de assinatura ´e v´alida somente se as seguintes regras de valida¸c˜ao
puderem ser aplicadas:
• (´unica ocorrˆencia) cada r´otulo aparece uma ´unica vez em cada T
i
;
• (consistˆencia interna) se (l : t
1
) ´e um componente de T
i
, e (l : t
2
) ´e um componente
de T
j
, ent˜ao t
1
= t
2
;
• (consistˆencia externa) se T
i
= t
1
→ t
2
→ · · · → t
n
e T
i
= t
1
→ t
2
→ · · · → t
m
, ent˜ao
a express˜ao de T
i
deve apenas prever a inclus˜ao de novos argumentos, respeitando
os tipos e a ordem dos argumentos j´a existentes; para isso, t
1
→ t
2
→ · · · → t
n
e
t
1
→ t
2
→ · · · → t
m
devem obedecer `as seguintes regras de consistˆencia:
– o tipo do resultado da fun¸c˜ao n˜ao pode ser alterado, isto ´e, t
n
= t
m
;
– se t
1
n˜ao for um tipo rotulado, ent˜ao t
1
= t
1
e t
2
→ · · · → t
n
e t
2
→ · · · → t
m
s˜ao consistentes;
– se t
1
for um tipo rotulado, ent˜ao t
1
→ t
2
→ · · · → t
n
e t
2
→ · · · → t
m
s˜ao
consistentes, e t
1
corresponde a um novo argumento que deve ser inclu´ıdo na
fun¸c˜ao correspondente.
Novos argumentos inclu´ıdos por meio de cl´ausulas de altera¸c˜ao de assinatura s˜ao automa-
ticamente transmitidos ao longo das aplica¸c˜oes recursivas das fun¸c˜oes envolvidas. Na falta
4.3. FUNC¸
˜
OES DE TRANSFORMAC¸
˜
AO 61
de tal argumento, um valor padr˜ao a ser inserido nas aplica¸c˜oes originais pode ser definido
por meio da cl´ausula default da transforma¸c˜ao, que possui o formato:
default l
1
= c
1
, l
2
= c
2
, · · · , l
n
= c
n
onde cada l
i
´e um r´otulo para o tipo t
i
em algum tipo rotulado nas cl´ausulas de altera¸c˜ao
de assinatura, e cada c
i
´e uma express˜ao cujo tipo ´e t
i
.
Por exemplo, considere a necessidade de se adaptarem equa¸c˜oes do exemplo da Figura 4.1
para a inclus˜ao do sequenciador break. Uma poss´ıvel solu¸c˜ao consiste em incluir um novo
argumento na fun¸c˜ao semˆantica C, representando a continua¸c˜ao para o break, conforme
definido na transforma¸c˜ao include break a:
transformation include break a
signature C : Com → Env → b : Cc → Cc → Cc
default b = λs.error
Em toda aplica¸c˜ao da fun¸c˜ao C um novo terceiro argumento λs.error ser´a automaticamente
inserido, exceto quando se tratar de uma aplica¸c˜ao recursiva da fun¸c˜ao, situa¸c˜ao em que
o parˆametro formal correspondente ser´a simplesmente propagado. A aplica¸c˜ao da trans-
forma¸c˜ao include break a produz as seguintes vers˜oes modificadas das equa¸c˜oes semˆanticas
da Figura 4.1
3
:
C : Com → Env → Cc → Cc → Cc
P[[D; C]] = D[[D]] r
0
(λr.C[[C]] r (λs.error) (λs.stop)) s
0
C[[C
1
; C
2
]] r b c = C[[C
1
]] r b; C[[C
2
]] r b c
C[[while E C]] r b c = (fix λfc
.E[[E]] r; λv.if v then C[[C]] r b (f c
) else c
) c
O sequenciador break pode ent˜ao ser definido como: C [[break]] r b c = b.
Em certas s itua¸c˜oes, a inser¸c˜ao de valor default para argumento pode ser feita de maneira
mais simples se for poss´ıvel associar na express˜ao a ser inserida informa¸c˜oes de contexto
da fun¸c˜ao em que a chamada ocorre. Por exemplo, para a inclus˜ao do sequenciador break
na defini¸c˜ao da Figura 4.1, p oder-se-ia considerar que o valor da nova continua¸c˜ao seria
propagado nas chamadas recursivas da f un¸c˜ao semˆantica de comandos, e a continua¸c˜ao
de sa´ıda do comando de repeti¸c˜ao seria automaticamente inserida como continua¸c˜ao de
interrup¸c˜ao na chamada do comando a ser repetido.
3
Equa¸c˜oes n˜ao afetadas pela transforma¸c˜ao n˜ao foram reproduzidas. Esta vers˜ao ainda n˜ao permite a
incorpora¸c˜ao completa do sequenciador break, pois ser´a ainda necess´ario o uso de decoradores.
62 CAP
´
ITULO 4. SEM
ˆ
ANTICA INCREMENTAL
Isto pode ser feito associando-se a cada cl´ausula default uma indica¸c˜ao de contexto defi-
nida por meio de um nome de fun¸c˜ao e dos parˆametros que identifiquem a equa¸c˜ao onde
a ins er¸c˜ao se dar´a. Desta maneira, cada cl´ausula l
i
= c
i
pode opcionalmente possuir
identifica¸c˜ao de contexto, assumindo nestes casos a forma:
l
i
[ within g
i
p
i1
· · · p
ik
i
] = c
i
,
onde g
i
´e um nome de fun¸c˜ao, e cada p
ij
´e um padr˜ao utilizado para identificar a equa¸c˜ao
onde a inser¸c˜ao ser´a feita. Os identificadores presentes em cada p
ij
podem ser utilizados
na express˜ao c
i
e ser˜ao amarrados aos valores correspondentes nos parˆametros reais da
aplica¸c˜ao da fun¸c˜ao g
i
.
Por exemplo, a transforma¸c˜ao a seguir inclui a continua¸c˜ao de sa´ıda do comando de re-
peti¸c˜ao como valor default na chamada da fun¸c˜ao semˆantica referente ao corpo da repeti¸c˜ao:
transformation include
break b
signature C : Com → Env → b : Cc → Cc → Cc
default b = λs.error,
b within C [[while E C]] r c = c
4.3.2 Decoradores de Fun¸c˜ao
Certas extens˜oes lingu´ısticas podem ser implementadas de maneira bastante simples se os
argumentos passados para as fun¸c˜oes semˆanticas forem adaptados. Por exemplo, o sequen-
ciador break pode ser inclu´ıdo sem dificuldades na especifica¸c˜ao alterando-se o ambiente de
execu¸c˜ao do corpo do comando while para armazenar a continua¸c˜ao de sa´ıda da repeti¸c˜ao.
Tal adapta¸c˜ao ´e feita por meio de cl´ausulas de decora¸c˜ao, cujo formato ´e o seguinte:
replace f
1
p
11
· · · p
1k
1
[ within g
1
p
11
· · · p
1m
1
] by e
1
,
· · · ,
f
n
p
n1
· · · p
nk
n
[ within g
n
p
n1
· · · p
nm
n
] by e
n
onde cada f
i
´e uma fun¸c˜ao do tipo t
i1
→ t
i2
→ · · · → t
ik
i
→ t
i
, p
ij
´e um padr˜ao para o
j-´esimo argumento de f
i
, e e
i
´e uma express˜ao do tipo t
i
. O efeito desta transforma¸c˜ao
´e substituir todas as aplica¸c˜oes da fun¸c˜ao f
i
que casem com os padr˜oes correspondentes
pela express˜ao e
i
. Opcionalmente, cada cl´ausula replace pode definir o contexto no qual a
decora¸c˜ao se aplica, de maneira semelhante `as cl´ausulas default. Neste caso, a decora¸c˜ao s´o
´e feita para aplica¸c˜oes da fun¸c˜ao f
i
que ocorrerem nas equa¸c˜oes correspondentes `a fun¸c˜ao
g
i
definidas pelos padr˜oes p
ij
.
4.3. FUNC¸
˜
OES DE TRANSFORMAC¸
˜
AO 63
O ambiente de avalia¸c˜ao da express˜ao e
i
amarra os identificadores presentes nos padr˜oes
p
ij
e p
ij
aos valores deduzidos pelo casamento dos padr˜oes com os parˆametros reais corres-
pondentes. Desta maneira, uma defini¸c˜ao de decora¸c˜ao t´ıpica no formato:
replace f p
1
· · · p
k
within g p
1
· · · p
m
by f e
1
· · · e
k
pode elaborar os novos argumentos para a fun¸c˜ao a partir dos argumentos passados nas
equa¸c˜oes j´a existentes.
Por exemplo, pode-se completar a transforma¸c˜ao include break a da Se¸c˜ao 4.3.1, incluindo-
se uma cl´ausula de decora¸c˜ao, o que produz a seguinte transforma¸c˜ao:
transformation include break a
signature C : Com → Env → b : Cc → Cc → Cc
default b = λs.error
replace C [[while E C]] r b c by C [[while E C]] r c c
A cl´ausula de decora¸c˜ao acima afeta somente a equa¸c˜ao que define o comando de repeti¸c˜ao
alterado da Se¸c˜ao 4.3.1, e a vers˜ao modificada ´e:
C[[while E C]] r b c = (fix λfc
.E[[E]] r; λv.if v then C[[C]] r c (f c
) else c
) c.
Outra forma de preparar a defini¸c˜ao para a inclus˜ao do sequenciador break ´e apresentada
na transforma¸c˜ao include break c a seguir, em que n˜ao h´a a necessidade de se alterar a
assinatura da fun¸c˜ao de denota¸c ˜ao de comandos. Esta solu¸c˜ao consiste em substituir a
aplica¸c˜ao da fun¸c˜ao semˆantica de comandos, no contexto da defini¸c˜ao da repeti¸c˜ao, para
que o ambiente considerado associe a continua¸c˜ao de sa´ıda da repeti¸c˜ao a uma posi¸c˜ao
especial break:
transformation include
break c
replace C [[C]] r c within C [[while E C
]] r
c
by C [[C]] r[c
/break] c
Esta cl´ausula de decora¸c˜ao afetar´a somente a equa¸c˜ao que define o comando de repeti¸c˜ao
na Figura 4.1, e a vers˜ao modificada ´e:
C[[while E C]] r c = (fix λfc
.E[[E]] r; λv.if v then C[[C]] r[c/break] (f c
) else c
) c.
64 CAP
´
ITULO 4. SEM
ˆ
ANTICA INCREMENTAL
4.3.3 Redefini¸c˜ao de Equa¸c˜oes
Em algumas situa¸c˜oes, pode ser mais apropriado reescrever a defini¸c˜ao de algumas cons-
tru¸c˜oes por meio de cl´ausulas de redefini¸c˜oes do que tentar adaptar equa¸c˜oes existentes.
Estas cl´ausulas possuem o seguinte formato:
redefine f
1
p
11
· · · p
1k
1
by e
1
, · · · , f
n
p
n1
· · · p
nk
n
by e
n
onde cada f
i
´e uma fun¸c˜ao do tipo t
i1
→ t
i2
→ · · · → t
ik
i
→ t
i
, p
ij
´e um padr˜ao para o
j-´esimo argumento de f
i
, e e
i
´e um express˜ao do tipo t
i
. Por exemplo, o comando while
pode ser redefinido por meio da seguinte transforma¸c˜ao, cujo objetivo ´e fazer com que a
continua¸c˜ao para o sequenciador seja passada via ambiente de execu¸c˜ao para o corpo da
repeti¸c˜ao:
transformation include break d
redefine C [[while E C]] r by
fix λfc.E[[E]] r; λv.if v then C[[C]] r[c/break] (f c) else c
4.4 Formaliza¸c˜ao do Modelo
Esta se¸c˜ao apresenta a semˆantica denotacional de defini¸c˜oes incrementais, por meio dos
dom´ınios sint´aticos, dom´ınios semˆanticos, fun¸c˜oes semˆanticas e equa¸c˜oes semˆanticas. Con-
sidera-se que uma especifica¸c˜ao pode ser uma especifica¸c˜ao inicial ou uma extens˜ao de
alguma especifica¸c˜ao existente.
4.4.1 Dom´ınios Sint´aticos
Uma especifica¸c˜ao inicial ´e composta por um conjunto de m´odulos nos quais se pode
definir sintaxe concreta, sintaxe abstrata, dom´ınios semˆanticos e fun¸c˜oes semˆanticas da
especifica¸c˜ao. Uma extens˜ao ´e composta por uma transforma¸c˜ao, a especifica¸c˜ao transfor-
mada e um conjunto de m´odulos. Especifica¸c˜oes s˜ao, desta maneira, definidas por meio da
seguinte gram´atica abstrata:
s ∈ S → specification M
∗
| extension T S M
∗
onde M representa o dom´ınio dos m´odulos e T o dom´ınio das transforma¸c˜oes. Uma trans-
forma¸c˜ao pode ser uma inclus˜ao de argumento, uma decora¸c˜ao, uma redefini¸c˜ao ou um
conjunto de transforma¸c˜oes, e possui a estrutura a seguir:
4.4. FORMALIZAC¸
˜
AO DO MODELO 65
t ∈ T → include I Q X
∗
| replace I P
∗
W E
| redefine I P
∗
E
| T
1
; T
2
A cl´ausula include corresponde a uma inclus˜ao de um mesmo argumento definida por
meio de cl´ausulas signature com valores especificados por meio de cl´ausulas default.
Os dom´ınios D, P , E e I representam, respectivamente, dom´ınios, padr˜oes, express˜oes
e identificadores. O dom´ınio Q representa a inclus˜ao de um mesmo argumento em uma
fun¸c˜ao, possuindo o seguinte formato:
q ∈ Q → inclusion I D
∗
D D
| Q
1
; Q
2
O dom´ınio X corresponde a uma defini¸c˜ao de valor default sendo repres entado por um
contexto do dom´ınio W e uma express˜ao. O dom´ınio W pode ser representado por um nome
de fun¸c˜ao e uma lista de padr˜oes que designem uma equa¸c˜ao, ou pelo s´ımbolo anywhere,
que representa que n˜ao h´a contexto espec´ıfico para inser¸c˜ao do valor default.
x ∈ Q → default W E
w ∈ W → within I P
∗
| anywhere
Por exemplo, o n´o de ´arvore de sintaxe abstrata correspondente `a transforma¸c˜ao include break b
da Se¸c˜ao 4.3.1 (p´agina 62) ´e igual a t
b
= include b q x
1
, x
2
, onde:
q = inclusion C Com, Env Cc (Cc → Cc)
x
1
= default anywhere (λs.error)
x
2
= default (within C p
∗
) (λs.error)
p
∗
= [[while E C]], r, b, c
O n´o de ´arvore de sintaxe abstrata correspondente `a transforma¸c˜ao include break a da
Se¸c˜ao 4.3.2 (p´agina 62) ´e igual a t
a
= t
a
; t

a
, onde:
t
a
= include b q x
q = inclusion C Com, Env Cc (Cc → Cc)
x = default anywhere (λs.error)
t

a
= r eplace C p
∗
anywhere e
p
∗
= [[while E C]], r, b, c
e = C[[while E C]] r c c
66 CAP
´
ITULO 4. SEM
ˆ
ANTICA INCREMENTAL
A ´arvore de s intaxe abstrata correspondente `a transforma¸c˜ao include break c da Se¸c˜ao 4.3.2
(p´agina 4.3.2) ´e igual a t
c
= replace C p
∗
w e, onde:
p
∗
= [[C]], r, c
w = within C p
∗
p
∗
= [[while E C
]], r
, c
e = C[[while E C]] r[c
/break] c
A ´arvore de sintaxe abstrata correspondente `a transforma¸c˜ao include break d da Se¸c˜ao 4.3.3
(p´agina 4.3.3) ´e igual a t
d
= redefine C p
∗
e, onde:
p
∗
= [[while E C]], r
e = fix λfc.E[[E]] r; λv.if v then C[[C]] r[c/break] (f c) else c
4.4.2 Dom´ınios Semˆanticos
A de nota¸c˜ao de uma especifica¸c˜ao ´e um valor φ ∈ Φ = Str → Str → Str, isto ´e, uma fun¸c˜ao
cujos argumentos s˜ao uma cadeia de caracteres representando um programa na linguagem
especificada e uma cadeia de caracteres representando a sequˆencia de entrada, e produz
uma cadeia de caracteres representando a sa´ıda produzida.
Transforma¸c˜oes s˜ao fun¸c˜oes que operam sobre a estrutura de uma especifica¸c˜ao, de modo
que antes de se produzir um valor φ ∈ Φ, elas s˜ao denotadas por um valor σ ∈ Σ. Assim,
internamente, uma especifica¸c˜ao ´e repres entada por meio da tupla σ = (g
c
, g
a
, d
∗
, ρ, main) ∈
Σ, onde g
c
: G representa a gram´atica concreta da especifica¸c˜ao, g
a
: G, a sua gram´atica
abstrata, d
∗
: D
∗
uma lista dos dom´ınios sint´aticos e semˆanticos, ρ : Env um ambiente que
mapeia nomes de fun¸c˜ao em listas de cl´ausulas de defini¸c˜ao, isto ´e, nas equa¸c˜oes semˆanticas
correspondentes, e main : I ´e o nome da fun¸c˜ao semˆantica que produz a denota¸c˜ao de
programas na linguagem especificada. Se P for o dom´ınio sint´atico de programas na
linguagem especificada, ent˜ao o dom´ınio da fun¸c˜ao main dever´a ser P → Str → Str.
O dom´ınio Env ´e definido por Env = I → F
∗
, onde F = P
∗
× E representa o dom´ınio
das cl´ausulas de fun¸c˜ao, compostas por uma lista de padr˜oes, representando seus argu-
mentos declarados, e uma express˜ao, representando o seu corpo. Em todas as fun¸c˜oes da
especifica¸c˜ao ´e acrescentado um argumento ρ : Env, para permitir a amarra¸c˜ao dinˆamica
de fun¸c˜oes. Com isso, toda oc orrˆencia do identificador de fun¸c˜ao f no corpo de uma das
cl´ausulas da fun¸c˜ao g ´e substitu´ıda pela express˜ao ((retrieve-f ρ) ρ), onde ρ corresponde
ao argumento inserido na cl´ausula correspondente da fun¸c˜ao g, e retrieve-f ´e uma fun¸c˜ao
4.4. FORMALIZAC¸
˜
AO DO MODELO 67
que recupera a defini¸c˜ao de f do ambiente ρ e monta uma fun¸c˜ao que possa ser utilizada na
aplica¸c˜ao correspondente. Para cada fun¸c˜ao f
i
: T da especifica¸c˜ao, ser´a criada uma fun¸c˜ao
especial retrieve-f
i
: Env → Env → T. Este artif´ıcio tem por objetivo tornar mais sim-
ples as defini¸c˜oes dos transformadores, uma vez que v´arias das transforma¸c˜oes executadas
consistir˜ao simplesmente em alterar o ambiente de amarra¸c˜ao de identificadores.
Por exemplo, considere uma especifica¸c˜ao composta pela fun¸c˜ao E : Exp → R → Val, cujas
cl´ausulas s˜ao as seguintes:
• E[[Id]] r = r Id;
• E[[E
1
+ E
2
]] r = E[[E
1
]] r + E[[E
2
]] r.
O ambiente ρ ´e definido por ρ = {E → {f
1
, f
2
}}, onde:
• f
1
= (ρ, [[Id]], r , r Id);
• f
2
= (ρ, [[E
1
+ E
2
]], r , ((retrieve-E ρ) ρ) [[E
1
]] r + ((retrieve-E ρ) ρ) [[E
2
]] r)
Al´em desses dom´ınios, definem-se ainda os dom´ınios Ω = {anywhere} + I × P
∗
, que re-
presenta uma informa¸c˜ao de contexto para cl´ausulas default e replace, e Ξ = Ω × E,
que representa uma cl´ausula default com express˜ao do dom´ınio E a ser inclu´ıda em um
contexto representado por um valor do dom´ınio Ω.
4.4.3 Fun¸c˜oes Semˆanticas
A especifica¸c˜ao do modelo consiste nas seguintes fun¸c˜oes semˆanticas:
• run : S → Φ
φ = run [[s]] ´e a denota¸c˜ao da especifica¸c˜ao s;
• S : S → Σ
σ = S[[s]] ´e a representa¸c˜ao interna de uma especifica¸c˜ao, possivelmente alvo de
transforma¸c˜ao;
• T : T → Env → Env
ρ
= T [[t]] ρ ´e o ambiente resultante da aplica¸c˜ao da transforma¸c˜ao t ao ambiente ρ;
68 CAP
´
ITULO 4. SEM
ˆ
ANTICA INCREMENTAL
• M : M
∗
→ Σ → Σ
σ
= M[[m
∗
]] σ ´e a espe cifica¸c ˜ao resultante da inclus˜ao dos m´odulos na lista m
∗
na
especifica¸c˜ao σ;
• E : E → E
e
= E[[e]] ´e uma express˜ao equivalente a e em que as ocorrˆencias dos identificadores
de fun¸c˜ao s˜ao substitu´ıdas pela express˜ao de pesquisa no ambiente dinˆamico;
• P : P
∗
→ P
∗
p
∗
= P[[p
∗
]] ´e uma lista de padr˜oes equivalentes a p
∗
em que as adapta¸c˜oes pertinentes
s˜ao realizadas;
• Q : Q → Γ
γ = Q[[q]] ´e uma fun¸c˜ao que mapeia cada nome de fun¸c˜ao f em que houve inclus˜ao
de argumento em um trio γ f = ((d
1
, · · · , d
n
), d, d
), indicando que a fun¸c˜ao f cujo
tipo era d
1
→ · · · → d
n
→ d
passar´a a ter tipo d
1
→ · · · → d
n
→ d → d
;
• W : W → Ω
ω = W[[w]] denota a informa¸c˜ao de contexto corresponde a w;
• X : X → Ξ, X
∗
: X
∗
→ Ξ
∗
χ = X [[x]] denota a cl´ausula default x, e χ
∗
= X
∗
[[x
∗
]] denota a lista de cl´ausulas
default x
∗
.
4.4.4 Equa¸c˜oes Semˆanticas
Execu¸c˜ao da Espe cifica¸c˜ao
A execu¸c˜ao de uma especifica¸c˜ao s consiste em aplicar a fun¸c˜ao semˆantica que gera a
denota¸c˜ao de programas ao programa fonte e `a sequˆencia de entrada. A equa¸c˜ao semˆantica
correspondente ´e dada por:
run [[s]] str
1
str
2
= apply-main σ (parse σ str
1
) str
2
where σ = S[[s]]
onde as fun¸c˜oes auxiliares parse e apply-main s˜ao respons´aveis respectivamente por gerar a
´arvore de sintaxe abstrata correspondente ao programa fonte e aplicar a fun¸c˜ao semˆantica
de programas `a ´arvore gerada.
4.4. FORMALIZAC¸
˜
AO DO MODELO 69
Gera¸c˜ao da Representa¸c˜ao Interna da Especifica¸c˜ao
Dada uma especifica¸c˜ao s, a fun¸c˜ao semˆantica S tem por objetivo agrupar as defini¸c˜oes pre-
sentes nos m´odulos e, no caso de extens˜oes, aplicar a fun¸c˜ao de transforma¸c˜ao, produzindo
como resultado uma representa¸c˜ao interna da especifica¸c˜ao.
No caso de especifica¸c˜ao inicial, deve-se compilar todos os m´odulos da especifica¸c˜ao, in-
cluindo os itens definidos em uma especifica¸c˜ao σ
0
inicialmente vazia:
S [[specification m
∗
]] = M[[m
∗
]] σ
0
No caso de extens˜ao de uma especifica¸c˜ao, deve-se inicialmente compilar a especifica¸c˜ao
original, em seguida aplicar o transformador correspondente produzindo a espe cifica¸c˜ao
adaptada e, por fim, processar todos os m´odulos da especifica¸c˜ao, incluindo os novos ele-
mentos definidos:
S [[extension t s m
∗
]] = let (g
c
, g
a
, d
∗
, ρ) = S[[s]] in M[[m
∗
]] (g
c
, g
a
, d
∗
, T [[t]] ρ)
Aplica¸c˜ao de Transforma¸c˜oes em Sequˆencia
Transforma¸c˜oes s˜ao denotadas por fun¸c˜oes que mapeiam especifica¸c˜oes em especifica¸c˜oes
e s˜ao produzidas pela fun¸c˜ao T .
Sequˆencias de transforma¸c˜oes s˜ao processadas na ordem em que s˜ao definidas, de modo
que a segunda transforma a especifica¸c˜ao resultante da primeira transforma¸c˜ao:
T [[T
1
; T
2
]] = T [[T
2
]] ◦ T [[T
1
]]
Aplica¸c˜ao de Transforma¸c˜oes de Inclus˜ao de Argumentos
A inclus˜ao de argumento com r´otulo i, com valor default dado pela express˜ao e e com
cl´ausulas de inclus˜ao q, tal como definido na Se¸c˜ao 4.3.1, produz um novo ambiente de
amarra¸c˜ao de identificadores de fun¸c˜ao a partir de um ambiente existente, sendo definida
70 CAP
´
ITULO 4. SEM
ˆ
ANTICA INCREMENTAL
por meio da seguinte equa¸c˜ao
4
:
T [[include i q x
∗
]] ρ = ρ
1
∪ ρ
2
where ρ
1
= {(f
i
→ map (include i γ) f
∗
) | f
∗
= ρ f
i
, f
i
bound in γ}
ρ
2
= {(f
i
→ map (include
f
i
γ χ
∗
) f
∗
) | f
∗
= ρ f
i
, f
i
unbound in γ}
γ = Q[[q]]
χ
∗
= X
∗
[[x
∗
]]
A fun¸c˜ao include ´e respons´avel pela inclus˜ao do novo argumento em fun¸c˜oes promovidas e
´e definida por:
include i γ (ρ : p
∗
1
, e) = (ρ : p
∗
2
, e[ρ
/ρ]),
onde p
∗
2
corresponde `a inclus˜ao de um novo padr˜ao identificador i na posi¸c˜ao esperada em
p
∗
1
, e ρ
´e o ambiente no qual o argumento i ´e propagado para toda aplica¸c˜ao de fun¸c˜ao
amarrada em γ.
A fun¸c˜ao include
ajusta o corpo de fun¸c˜oes n˜ao-promovidas e ´e definida por:
include
f
i
γ χ
∗
(ρ : p
∗
, e) = (ρ : p
∗
, e[ρ
/ρ]),
onde ρ
´e o ambiente no qual o valor default e
´e inserido em toda aplica¸c˜ao de fun¸c˜ao
amarrada em γ, nos casos em que χ = (p
∗
, e
) ´e uma informa¸c˜ao de contexto em χ
∗
, tal
que p
∗
´e a generaliza¸c˜ao mais estrita
5
de p
∗
.
Aplica¸c˜ao de Transforma¸c˜oes de Decora¸c˜ao
A decora¸c˜ao da fun¸c˜ao de nome i com lista de padr˜oes p
∗
, contexto de aplica¸c˜ao w e
express˜ao de substitui¸c˜ao e consiste na cria¸c˜ao de um novo ambiente no qual a fun¸c˜ao ´e
substitu´ıda por uma vers˜ao em que todas as chamadas da fun¸c˜ao s˜ao decoradas, tal como
definido na Se¸c˜ao 4.3.2, caso os padr˜oes que designem a equa¸c˜ao sejam aplic´aveis:
T [[replace i p
∗
w e]] ρ = ρ
where ρ
= {(i
→ map dec f
∗
) | (i
→ f
∗
) ∈ ρ}
dec = decorate i P[[p
∗
]] W[[w]] E[[e]]
4
A fun¸c˜ao map f l aplica a fun¸c˜ao f a cada elemento na l, pro duzindo uma lista composta pelos
resultados.
5
Um padr˜ao p ´e uma generaliza¸c˜ao do padr˜ao p
se todas as express˜oes que casarem com p
tamb´em
casarem com p. Um padr˜ao p ´e uma generaliza¸c˜ao mais estrita de p
se p for generaliza¸c˜ao de p
e n˜ao
houver padr˜ao p

tal que p ´e generaliza¸c˜ao de p

e p

´e generaliza¸c˜ao de p
. Ver defini¸c˜ao por casos na
Se¸c˜ao 5.4.2.
4.4. FORMALIZAC¸
˜
AO DO MODELO 71
A fun¸c˜ao decorate toma como argumentos os dados de uma decora¸c˜ao e uma cl´ausula
de fun¸c˜ao da especifica¸c˜ao e faz a substitui¸c˜ao da fun¸c˜ao decorada, caso a cl´ausula seja
compat´ıvel com o contexto designado por ω, e ´e definida por:
decorate i p
∗
ω e f = f
,
onde f
´e definida de acordo com os seguintes casos:
1. se ω = anywhere, ent˜ao f
= replace i p
∗
e f;
2. se ω = (i, p
∗

), f = (ρ
: p
∗
, e
) e p
∗

for generaliza¸c˜ao de p
∗
, ent˜ao a nova fun¸c˜ao
´e dada por f
= replace i p
∗
e

f, onde e

= e[ρ
∗
/ρ
∗

] corresponde `a express˜ao e
na qual os identificadores de contexto s˜ao amarrados aos valores correspondentes dos
parˆametros formais da cl´ausula decorada;
3. se as condi¸c˜oes 1 e 2 n˜ao puderem ser aplicadas, ent˜ao a cl´ausula n˜ao deve ser
decorada, e, portanto, f
= f.
A fun¸c˜ao replace tem como argumentos o nome da fun¸c˜ao decorada i, o padr˜ao aplic´avel
`a decora¸c˜ao p
∗
, a express˜ao que substitui a aplica¸c˜ao e, e a cl´ausula onde a substitui¸c˜ao
deve ocorrer (ρ : p
∗
, e
) e gera uma nova cl´ausula (ρ

: p
∗
, e
). Nesta nova cl´ausula, o
ambiente ρ

mapeia a fun¸c˜ao decorada i na express˜ao e, amarrando os identificadores em
p
∗
aos parˆametros formais originais em p
∗
e o identificador i `a vers˜ao antiga da fun¸c˜ao,
conforme amarra¸c˜ao feita no ambiente original ρ. Para que isso seja poss´ıvel, p
∗
deve ser
generaliza¸c˜ao de p
∗
.
Aplica¸c˜ao de Transforma¸c˜oes de Redefini¸c˜ao
A redefini¸c˜ao de uma equa¸c˜ao referente a uma fun¸c˜ao de nome i com lista de padr˜oes
p
∗
e express˜ao de substitui¸c˜ao e, tal como definido na Se¸c˜ao 4.3.3, consiste na cria¸c˜ao de
um novo ambiente no qual a cl´ausula correspondente da fun¸c˜ao ´e substitu´ıda pela nova
cl´ausula:
T [[redefine i p
∗
e]] ρ = ρ[(map (redefine i P[[p
∗
]] E[[ e]]) (ρ i))/i]
A function redefine recebe como argumentos os dados da redefini¸c˜ao e uma cl´ausula da
fun¸c˜ao redefinida, produzindo um novo ambiente no qual a cl´ausula especificada ´e subs-
titu´ıda. Esta fun¸c˜ao ´e definida por
6
:
redefine i (p
1
, · · · , p
m
) e ((p
1
, · · · , p
n
), e
) = f
,
6
Compare com a defini¸c˜ao de replace, que aplica a vers˜ao original da fun¸c˜ao.
72 CAP
´
ITULO 4. SEM
ˆ
ANTICA INCREMENTAL
onde se (p
1
, · · · , p
m
) for uma generaliza¸c˜ao de (p
1
, · · · , p
m
), ent˜ao:
f
= ([p
1
, · · · , p
m
, p
m+1
, · · · , p
n
], e

p
m+1
· · · p
n
),
e

= e[p
1
/p
1
, · · · , p
m
/p
m
],
ou
f
= ((p
1
, · · · , p
n
), e
),
caso contr´ario.
O efeito da fun¸c˜ao redefine ´e substituir toda ocorrˆencia da fun¸c˜ao de nome i no ambiente por
sua nova vers˜ao, em que toda vez que os argumentos da aplica¸c˜ao casarem com p
1
, · · · , p
m
,
a nova express˜ao substitui a aplica¸c˜ao original da fun¸c˜ao. Se os padr˜oes n˜ao casarem, ent˜ao
a vers˜ao original da fun¸c˜ao ´e utilizada. Vale ressaltar que todas as ocorrˆencias livres do
nome da fun¸c˜ao em e s˜ao localizadas no ambiente corrente, e, por esta raz˜ao, qualquer
aplica¸c˜ao da fun¸c˜ao se refere `a sua nova defini¸c˜ao.
4.5 Estudos de Caso
Para valida¸c˜ao, a metodologia foi aplicada na defini¸c˜ao incremental da parte sequencial de
Java (Crepalde et al. 2008a). Esta defini¸c˜ao ´e composta por trˆes partes:
• Java 0: o programa ´e composto por uma ´unica classe e cont´em os tipos primitivos
inteiro e l´ogico, comandos b´asicos da linguagem, express˜oes e fun¸c˜oes e st´aticas;
• Java 1: estende a especifica¸c˜ao inicial inc luindo todos os tipos primitivos, arranjos
e sequenciadores;
• Java 2: estende a especifica¸c˜ao anterior permitindo a defini¸c˜ao de instˆancias de
classes, m´etodos dinˆamicos, arranjos de objetos e aloca¸c˜ao dinˆamica de objetos.
O Apˆendice B apresenta a defini¸c˜ao de linguagens utilizando os recursos da metodologia
proposta.
Este cap´ıtulo apresenta os alguns estudos de caso simples para compreens˜ao dos recursos
propostos:
1. defini¸c˜ao incremental de m´etodos e tratamento de exce¸c˜oes em linguagem orientada
por objetos t´ıpica;
4.5. ESTUDOS DE CASO 73
2. defini¸c˜ao incremental de procedimentos e adendos em linguagem orientada por as-
pectos.
4.5.1 M´etodos e Tratamento de Exce¸c˜oes
Esta se¸c˜ao apresenta uma solu¸c˜ao para o problema da separa¸c˜ao da defini¸c˜ao de m´etodos
e tratamento de exce¸c˜oes em uma linguagem orientada por objetos t´ıpica, cuja solu¸c˜ao
entrela¸cada ´e apresentada na Se¸c˜ao 4.1, p´agina 56.
Considere inicialmente a defini¸c˜ao semˆantica da Figura 4.1, p´agina 59. Para a inclus˜ao de
m´etodos, ser´a criada uma nova continua¸c˜ao de retorno associada a todos os comandos e
propagada por meio do environment. Esta continua¸c˜ao ser´a definida no in´ıcio da execu¸c˜ao
de corpo de m´etodo e ser´a propagada recursivamente ao longo das aplica¸c˜oes da fun¸c˜ao
de denota¸c˜ao de comandos. Uma continua¸c˜ao de erro ser´a inserida em todas as chamadas
de C que n˜ao se originarem da e xecu¸c˜ao de m´etodos. As constru¸c˜oes relativas a m´etodos
podem ser definidas por meio das seguintes equa¸c˜oes:
• D[[I
1
(I
2
) { C }]] r u = u r[(f, r)/I
1
]
where f = fix (λf r
.ref; λl.C[[C]]r
[(f, r), l/I
1
, I
2
]; r
return novalue)
• C[[return E]]r c = E[[E]]r; r return
• E[[E
1
(E
2
)]]r k = E[[E
1
]]r; λ(f, r
).E[[E
2
]]r; apply (f, r
[k/return])
onde a fun¸c˜ao apply ´e definida por apply (f, r) = f r.
Para a inclus˜ao de tratamento de exce¸c˜oes, considera-se que uma nova continua¸c˜ao para
o sequenciador de lan¸camento de exce¸c˜oes ser´a inclu´ıda nas fun¸c˜oes semˆanticas de ex-
press˜oes e comandos. Para isso, define-se a transforma¸c˜ao include exceptions que realiza a
propaga¸c˜ao da nova continua¸c˜ao tamb´em por meio do environment:
transformation include exceptions
replace apply (f, r
) within E[[E
1
(E
2
)]] r
by apply (f, r
[r throw/throw])
A decora¸c˜ao especificada recupera do environment da chamada de fun¸c˜ao o valor da con-
tinua¸c˜ao de exce¸c˜ao e a propaga via environment para a execu¸c˜ao do corpo da fun¸c˜ao.
Ao se comparar esta solu¸c˜ao com a solu¸c˜ao apresentada anteriormente na Se¸c˜ao 4.1,
p´agina 56, notam-se as seguintes melhorias:
74 CAP
´
ITULO 4. SEM
ˆ
ANTICA INCREMENTAL
• as equa¸c˜oes que apresentam as constru¸c˜oes relacionadas a chamadas de m´etodos est˜ao
completamente independentes da existˆencia de tratamento de exce¸c˜oes;
• est´a expl´ıcito nas equa¸c˜oes o efeito da inclus˜ao de tratamento de exce¸c˜oes sobre as
constru¸c˜oes existentes, no caso, as relacionadas a m´etodos.
As equa¸c˜oes que definem as constru¸c˜oes relativas ao mecanismo de tratamento de exce¸c˜oes
permanecem como anteriormente definidas.
4.5.2 Defini¸c˜ao de Procedimentos e Adendos
Adendos e pontos de jun¸c˜ao dinˆamicos da programa¸c˜ao orientada por aspectos (Kiczales
et al. 1997) s˜ao formalmente definidos por Wand et al. (2004), que apresentam uma espe-
cifica¸c˜ao da semˆantica denotacional mon´adica para uma linguagem simples semelhante a
Scheme, composta por procedimentos, adendos e descritores de conjuntos de jun¸c˜ao. As
equa¸c˜oes semˆanticas apresentadas naquela especifica¸c˜ao contˆe m elementos entrela¸cados, o
que dificulta a compreens˜ao dos conceitos chaves da defini¸c˜ao.
Este e studo de caso ´e uma simplifica¸c˜ao daquela formaliza¸c˜ao, por meio da aplica¸c˜ao dos
mecanismos apresentados para especifica¸c˜oes incrementais. Esta vers˜ao n˜ao considera as
cl´ausulas within e proceed, que podem se r incorporadas por meio de decoradores.
A Figura 4.2 apresenta os principais elementos da especifica¸c˜ao semˆantica, a saber seus
dom´ınios e a mˆonada para execu¸c˜ao, que foram tomadas ipsis litteris do artigo original
(Wand et al. 2004). Aquele trabalho apresenta ainda detalhes a respeito da ´algebra de
pontos de jun¸c˜ao, fun¸c˜oes auxiliares e opera¸c˜oes mon´adicas, recomendado para leitores
que se interessarem em entender a formaliza¸c˜ao com maior profundidade.
Defini¸c˜ao de Procedimentos. Procedimentos s˜ao o ponto de partida da defini¸c˜ao. A
denota¸c˜ao da declara¸c˜ao de procedimentos ´e resultado da fun¸c˜ao P, que tem por obje-
tivo criar um ambiente de procedimentos que associe nome de procedimento `a semˆantica
correspondente:
P : Procedure → PE → PE
P[[(procedure pname (x
1
, · · · , x
n
) e)]] φ = [proc/pname]
where proc = λ(v
1
, · · · , v
n
). let l
1
⇐ alloc v
1
; · · · ; l
n
⇐ alloc v
n
in E[[e]] [l
1
/x
1
, · · · , l
n
/x
n
] φ
4.5. ESTUDOS DE CASO 75
Sets:
v ∈ Val Expressed values
l ∈ Loc Locations
s ∈ Sto Stores
id ∈ Id Identifiers
pname,
wname ∈ Pname Procedure names
v ∈ Val Expressed values
Join points, pointcut designators:
jp ∈ JP
jp →  | k, pname, wname, v
∗
, jp
k → pcall | pexecution | aexecution
pcd → · · ·
Execution monad:
T (A) = JP × Sto → (A × Sto)
⊥
Semantic Domains:
π ∈ Proc = Val
∗
→ T (Val) Procedures
α ∈ Adv = JP → Proc → Proc Advices
φ ∈ PE = Pn ame → Proc Procedure environments
γ ∈ AE = Adv
∗
Advice environments
ρ ∈ Env = [Id → Loc] Environments
Figura 4.2: Defini¸c˜oes B ´asicas para a Semˆantica de Adendos e Pontos de Jun¸c˜ao da Pro-
grama¸c˜ao Orientada por Aspectos – Extra´ıda de Wand et al. (2004).
Chamadas de procedimento s˜ao definidas por meio da fun¸c˜ao E, que avalia os argumentos
e aplica a denota¸c˜ao de procedimento amarrada no environment corrente:
E : Exp → Env → PE → T (Val)
E[[(pname e
1
· · · e
n
)]] ρ φ = let v
1
⇐ E[[e
1
]] ρ φ; · · · ; v
n
⇐ E[[e
n
]] ρ φ
in φ pname (v
1
, · · · , v
n
)
Defini¸c˜ao de Adendos. O primeiro passo para a inclus˜ao dos recursos da orienta¸c˜ao por
aspectos consiste em adaptar as equa¸c˜oes apresentadas para mostrar como procedimentos
dependem de ambientes de adendos; esta adapta¸c˜ao ´e feita por meio da transforma¸c˜ao
76 CAP
´
ITULO 4. SEM
ˆ
ANTICA INCREMENTAL
include-advices:
transformation include-advices
signature E : Exp → Env → PE → γ : AE → T (Val),
P : Procedure → PE → PE to Procedure → PE → (γ : AE) → PE
default γ = []
replace P[[(procedure pname (x
1
, · · · , x
n
) e)]] φ γ
by [(enter-jp γ (new-pexecution pname) proc)/pname]
where proc = P[[(procedure pname (x
1
, · · · , x
n
) e)]] φ γ,
E[[(pname e
1
· · · e
n
)]] ρ φ γ
by E[[(pname e
1
· · · e
n
)]] ρ (φ[proc/pname]) γ
where proc = λv
∗
.enter-jp γ (new-pcall pname v
∗
) (φ pname)
Esta transforma¸c˜ao: (a) inclui o ambiente de adendos como argumento das fun¸c˜oes E e P
por meio de uma cl´ausula de altera¸c˜ao de assinatura; este ambiente ´e propagado por meio
das chamadas recursivas da fun¸c˜ao P, e, na falta de um ambiente para ser propagado, um
ambiente vazio ´e utilizado como valor default; (b) decora o ambiente de procedimentos
para costurar a execu¸c˜ao de adendos, por meio da primeira cl´ausula replace, que decora
o resultado da fun¸c˜ao P com marcas de pontos de jun¸c˜ao; e (c) decora a execu¸c˜ao de
express˜oes de chamada de procedimentos para costurar adendos de execu¸c˜ao, por meio
da segunda cl´ausula r eplace, que decora o argumento da fun¸c˜ao E correspondente ao
ambiente de procedimento com marcas espec´ıficas de pontos de jun¸c˜ao.
A semˆantica de adendos ´e resultado da fun¸c˜ao A, que executa o adendo e o corpo do
procedimento na ordem correta, caso o ponto de jun¸c˜ao correspondente seja aplic´avel ao
procedimento; caso contr´ario, apenas o corpo do procedimento ´e executado.
A : Advice → PE → AE → JP → Proc → Proc
A[[(before pcd e)]] φ γ jp π =
λv
∗
.PCD[[pcd]] jp (λρ.let v
1
⇐ E[[e]] ρ φ γ; v
2
⇐ π v
∗
in v
2
) (π v
∗
)
A[[(after pcd e)]] φ γ jp π =
λv
∗
.PCD[[pcd]] jp (λρ.let v
1
⇐ π v
∗
; v
2
⇐ E[[e]] ρ φ γ in v
1
) (π v
∗
)
A aplica¸c˜ao das t´ecnicas de defini¸c˜ao incremental permite a defini¸c˜ao vaga de procedi-
mentos, que pode ser estendida, por meio de fun¸c˜oes de transforma¸c˜ao, para suportar
posteriormente adendos da orienta¸c˜ao por aspectos.
4.6. CONCLUS
˜
OES 77
4.6 Conclus˜oes
Este cap´ıtulo apresentou a t´ecnica de Semˆantica Incremental, que tem por objetivo permi-
tir a defini¸c˜ao incremental da semˆantica denotacional de uma linguagem. Nesta t´ecnica,
define-se uma vers˜ao inicial da linguagem, contendo seus elementos mais relevantes. A par-
tir desta defini¸c˜ao inicial, pode-se definir uma sequˆencia de especifica¸c˜oes, em que cada uma
estende a anterior. Para que a extens˜ao seja poss´ıvel, uma especifica¸c˜ao pode aplicar uma
fun¸c˜ao de transforma¸c˜ao, que define como adaptar as denota¸c˜oes existentes. Desta ma-
neira, a denota¸c˜ao das constru¸c˜oes pode evoluir ao longo das especifica¸c˜oes intermedi´arias,
at´e a sua vers˜ao final.
Esta t´ecnica se baseia no uso de vagueza de defini¸c˜oes iniciais, um conceito que ´e muito
comum nas descri¸c˜oes informais. Geralmente, manuais de linguagem e materiais did´aticos
tendem, nos cap´ıtulos iniciais, a explicar a estrutura geral da linguagem e suas constru¸c˜oes
mais b´asicas; conforme novas constru¸c˜oes s˜ao explicadas, novas interpreta¸c˜oes podem ser
dadas ao que j´a foi discutido. O uso de descri¸c˜oes vagas permite ao projetista apresentar
a linguagem em etapas, aumentando o grau de detalhamento ao longo do tempo.
Durante a escolha das poss´ıveis transforma¸c˜oes, foi dada ˆenfase a casos mais comuns de
transforma¸c˜oes de equa¸c˜oes semˆanticas em defini¸c˜oes denotacionais. Assim, n˜ao houve o
intuito neste trabalho em buscar um conjunto completo de transformadores que pudessem
lidar com todos os casos poss´ıveis. No entanto, as primitivas de transforma¸c˜ao dispon´ıveis
tratam os casos mais comuns, permitindo manipular equa¸c˜oes semˆanticas sem quebrar a
abstra¸c˜ao do modelo denotacional.
Com rela¸c˜ao aos recursos usuais da orienta¸c˜ao por aspectos, optou-se neste trabalho por de-
finir um ambiente controlado para os transformadores que n˜ao comprometesse o racioc´ınio
modular.
O pr´oximo cap´ıtulo apresenta a linguagem de especifica¸c˜ao Notus, que implementa as
t´ecnicas definidas neste cap´ıtulo. A linguagem Notus possui recursos para a defini¸c˜ao in-
cremental de linguagens de programa¸c˜ao, sendo poss´ıvel especificar sintaxe e semˆantica. O
compilador da linguagem Notus gera interpretadores execut´aveis para a linguagem definida,
permitindo acelerar o processo de prototipa¸c˜ao da linguagem.
78 CAP
´
ITULO 4. SEM
ˆ
ANTICA INCREMENTAL
Cap´ıtulo 5
Ambiente Para Semˆantica
Incremental
Este cap´ıtulo tem por objetivo apresentar os recursos mais importantes da linguagem
Notus, que ´e o elemento central de um ambiente de desenvolvimento para formula¸c˜ao de
semˆantica baseada na metodologia descrita no Cap´ıtulo 4.
A linguagem Notus ´e uma evolu¸c˜ao da linguagem SCRIPT (Costa 2000, Maia 1994,
Oliveira 1998) possui recursos para a defini¸c˜ao incremental completa de uma linguagem
de programa¸c˜ao, incluindo sintaxe e semˆantica. A sintaxe da linguagem Notus pode ser
encontrada no Apˆendice A. Uma apresenta¸c˜ao do uso da linguagem e de seu compilador ´e
feita por Crepalde et al. (2008b) no relat´orio t´ecnico do Manual do Usu´ario de Notus. Um
compilador completo para a linguagem foi desenvolvido inicialmente por Soares (2007) e
estendido por Loredo et al. (2008). O autor desta tese participou de toda a concep¸c˜ao e
projeto do compilador.
Optou-se neste trabalho por desenvolver uma nova linguagem, em vez de estender uma
linguagem funcional j´a existente, como Haskell. Esta decis˜ao deveu-se principalmente `a
necessidade de se definir um conjunto de constru¸c˜oes mais pr´oximo das equa¸c˜oes encon-
tradas na literatura da ´area, permitindo a escrita de c´odigo mais leg´ıvel.
Organiza¸c˜ao do Cap´ıtulo. A Se¸c˜ao 5.1 apresenta os mecanismos para divis˜ao de uma
defini¸c˜ao incremental em uma sequˆencia de especifica¸c˜oes, e cada uma destas em paco-
tes e m´odulos. A Se¸c˜ao 5.2 mostra os mecanismos de defini¸c˜ao de dom´ınios sint´aticos e
semˆanticos em defini¸c˜oes de semˆantica incremental. Na Se¸c˜ao 5.3, s˜ao discutidos os re-
79
80 CAP
´
ITULO 5. AMBIENTE PARA SEM
ˆ
ANTICA INCREMENTAL
cursos para defini¸c˜ao da sintaxe de linguagem de programa¸c˜ao, da qual ´e poss´ıvel derivar
sistema de pr´e-processamento de arquivo fonte, analisador l´exico e analisador sint´atico.
Na Se¸c˜ao 5.4, apresentam-se os principais recursos para defini¸c˜ao de fun¸c˜oes semˆanticas,
a partir das quais pode-se gerar um interpretador da linguagem especificada. A Se¸c˜ao 5.5
apresenta os recursos lingu´ısticos para defini¸c˜ao de transformadores de especifica¸c˜ao. A
Se¸cao 5.6 discute a cria¸c˜ao de componentes de linguagens em Notus. A Se¸c˜ao 5.7 apre-
senta a estrutura do compilador e discute as principais dificuldades da implementa¸c˜ao. E,
finalmente, a Se¸c˜ao 5.8 apresenta as conclus˜oes do cap´ıtulo.
5.1 Organiza¸c˜ao Modular
A defini¸c˜ao incremental de uma linguagem ´e organizada em um conjunto de pastas, cada
uma referente a uma especifica¸c˜ao, todas dentro de uma mesma pasta raiz. Considere
por exemplo que a defini¸c˜ao incremental de uma linguagem L seja feita por meio de trˆes
especifica¸c˜oes, L
0
, L
1
, L
2
. Os m´odulos que comp˜oem estas especifica¸c˜oes devem ent˜ao estar
presentes em subpastas L0, L1 e L2, dentro da pasta raiz. Cada especifica¸c˜ao L
i
pode ser
dividida em m´odulos organizados em uma estrutura recursiva de pacotes com controle de
visibilidade seme lhante `a utilizada nas linguagens Haskell e Java, conforme mostrado na
Figura 5.1.
5.1.1 Estrutura de Pacotes
Dentro de uma especifica¸c˜ao, m´odulos podem ser organizados em pacotes. Um m´odulo M
pertence a um pacote P se:
• o cabe¸calho do m´odulo M for: module P.M;
• o arquivo M.nts estiver na pasta P.
Pacotes podem ser estruturados de maneira recursiva, de modo que um pacote pode conter
sub-pacotes. Por exemplo, existe uma sequˆencia de pacotes P
1
, P
2
, ..., P
n
, tal que P
i
´e
sub-pacote de P
i−1
, para 2 ≤ i ≤ n, e o m´odulo M pertence ao pacote P
n
se:
• o cabe¸calho do m´odule M for: module P
1
.P
2
. · · · .P
n
.M;
5.1. ORGANIZAC¸
˜
AO MODULAR 81
root@A
ED
@A
ED
@A
ED
L0
@A
@A
@A
@A
L1
@A
@A
@A
@A
L2
@A
@A
@A
@A
Main T1 T2
P1
@A
@A
@A
Main Main
MP11
Q1
@A
@A
R1
@A
@A
@A
MP12
Q11
@A
@A
@A
MR11
MP13
MQ111
MR12
P2
@A
@A
MQ112
MR13
MP21
MQ113
R2
@A
@A
@A
MP22
Q12
@A
@A
MR21
P3
@A
@A
MQ121
MR22
MP31
MQ122
R21
@A
@A
@A
MP32
Q2
@A
@A
MR211
MQ21
MR212
MQ22
MR213
Figura 5.1: Exemplo de Organiza¸c˜ao Modular de Defini¸c˜ao Incremental de uma Linguagem
Hipot´etica L.
• existir uma sequˆencia de pastas aninhadas P
1
, P
2
, ..., P
n
, tal que a pasta P
i
pertence
`a pasta P
i−1
, para 2 ≤ i ≤ n;
• o arquivo
1
M.nts estiver na pasta P
n
.
5.1.2 M´odulos e Visibilidade
M´odulo ´e o principal mecanismo de encapsula¸c˜ao das descri¸c˜oes de recursos lingu´ısticos e
pode ser composto pelos seguintes constituintes:
1. se¸c˜ao de importa¸c˜oes: enumera os m´odulos dos quais o m´odulo depende;
2. defini¸c˜oes l´exicas: definem ou estendem elementos l´exicos da linguagem, que podem
ser tokens ou macros para defini¸c˜ao de tokens;
1
A extens˜ao de m´odulos em notus ´e nts.
82 CAP
´
ITULO 5. AMBIENTE PARA SEM
ˆ
ANTICA INCREMENTAL
1 module Pa.Pb.Pc.M
2 ...
3 public token x = ”x”
4 private token y = ”y”
5 token w = ”w”
6 ...
Listagem 5.1: Exemplo do Uso de Visibilidade em Notus
3. defini¸c˜oes sint´aticas: definem ou estendem dom´ınios sint´aticos e definem novas regras
de produ¸c˜ao das gram´aticas concreta e abstrata;
4. defini¸c˜oes de dom´ınios: definem ou estendem dom´ınios semˆanticos da especifica¸c˜ao;
5. declara¸c˜oes de fun¸c˜oes: introduzem novas fun¸c˜oes `a especifica¸c˜ao por meio de de-
fini¸c˜ao de assinatura;
6. defini¸c˜oes de fun¸c˜ao: definem corpo de fun¸c˜ao.
Os componentes de um m´odulo podem ser definidos em qualquer ordem, desde que a se¸c˜ao
de importa¸c˜oes anteceda todas as demais se¸c˜oes. Cada identificador ´e definido com sua
visibilidade, que pode ser: p´ublica, se for utilizada a palavra chave public; privada ao
m´odulo, se for utilizada a palavra chave private; ou p´ublica somente para o pacote a que
o m´odulo pertence, caso a visibilidade n˜ao seja explicitada pelo projetista.
Por exemplo, na Listagem 5.1: o token x ´e definido como p´ublico, podendo assim ser
acessado por todos os m´odulos da especifica¸c˜ao; por outro lado, o token y ´e privado podendo
ser utilizado somente dentro do m´odulo M; finalmente, o token w possui visibilidade de
pacote, podendo assim ser acessado somente por m´odulos pertencentes ao pacote Pa.Pb.Pc.
5.1.3 Regras de Importa¸c˜ao de Identificadores
A se¸c˜ao de importa¸c˜ao enumera m´odulos dos quais um m´odulo depende. Se um m´odulo
M
2
importar um m´odulo M
1
, ent˜ao todos os componentes p´ublicos de finidos em M
1
podem
ser utilizados em M
2
sem qualifica¸c˜ao. Componentes privados definidos em M
1
n˜ao s˜ao
acess´ıveis de maneira alguma a partir de M
2
. Al´em disso, se M
1
e M
2
pertencerem a um
mesmo pacote, ent˜ao todos os identificadores de M
1
com visibilidade de pacote tamb´em
s˜ao acess´ıveis a partir de M
2
sem a necessidade de qualifica¸c˜ao.
5.1. ORGANIZAC¸
˜
AO MODULAR 83
1 module M
2 import A
3 function g : Int −> Int
4 g x = f x + B.f x // Correct
5 ...
6 end
7 module N
8 import A, B
9 function h : Int −> Int
10 h x = f x // Incorrect . Should have used either A.f x or B.f x
11 ...
12 end
Listagem 5.2: Exemplo de Resolu¸c˜ao de Colis˜ao de Nomes
Um componente vis´ıvel a um m´odulo pode tamb´em ser referenciado por meio da quali-
fica¸c˜ao completa de seu identificador com o nome do m´odulo. Por exemplo, um compo-
nente de nome x definido no m´odulo M
1
pode ser referenciado por M
1
.x. Neste caso, n˜ao
´e necess´ario importar M
1
. Tal qualifica¸c˜ao ´e tamb´em utilizada para resolver colis˜oes de
identificadores importados em um m´odulo. Por exemplo, suponha que os m´odulos M
1
e M
2
definam componentes distintos, mas ambos com o nome x, e que um m´odulo M
3
importe
tanto M
1
quanto M
2
. Esta colis˜ao deve ser resolvida utilizando-se M
1
.x ou M
2
.x.
Considere os m´odulos M e N, definidos na Listagem 5.2. Suponha que os m´odulos A e B
definem fun¸c˜oes p´ublicas distintas, ambas com nome f , pertencentes ao dom´ınio Int → Int.
M´odulo M importa o m´odulo A, sendo poss´ıvel utilizar a fun¸c˜ao f de A sem qualifica¸c˜ao;
no entanto, para utilizar a fun¸c˜ao f de B ´e necess´ario fazer a qualifica¸c˜ao. No m´odulo N,
n˜ao ´e poss´ıvel distinguir qual fun¸c˜ao f ´e utilizada em cada aplica¸c˜ao, uma vez que ambos
os m´odulos A e B foram importados. Neste caso, a qualifica¸c˜ao ´e obrigat´oria para todas
as ocorrˆencias do nome f .
5.1.4 Extens˜ao de Componentes
Durante a escrita de uma especifica¸c˜ao incremental, pode ser necess´ario redefinir algum
elemento b´asico de defini¸c˜ao da linguagem. Por exemplo, a inclus˜ao de um novo comando
pode exigir a defini¸c˜ao de uma nova regra de produ¸c˜ao que tenha como lado esquerdo
84 CAP
´
ITULO 5. AMBIENTE PARA SEM
ˆ
ANTICA INCREMENTAL
o n˜ao-terminal correspondente a comandos. Tipicamente, as altera¸c˜oes necess´arias ao se
definir uma nova constru¸c˜ao podem ser:
• incluir uma nova express˜ao regular para defini¸c˜ao de um token j´a existente ou de
uma macro para defini¸c˜ao de tokens; tais extens˜oes s˜ao feitas por meio de cl´ausulas
extend associadas a tokens e macros (ver Se¸c˜ao 5.3.3.2);
• incluir uma nova regra de produ¸c˜ao na gram´atica concreta, tendo como lado esquerdo
algum n˜ao-terminal j´a definido; tais extens˜oes s˜ao feitas por meio de cl´ausulas extend
associadas a n˜ao terminais da gram´atica concreta (ver Se¸c˜ao 5.3.4.5);
• incluir uma nova regra de produ¸c˜ao na gram´atica abstrata, tendo como lado esquerdo
algum dom´ınio sint´atico j´a definido; tais extens˜oes s˜ao feitas automaticamente, ao se
incluir uma nova regra de produ¸c˜ao `a gram´atica concreta, ou por meio de cl´ausulas
extend associadas a dom´ınios sint´aticos (ver Se¸c˜ao 5.2.4);
• definir rela¸c˜ao de tipo e subtipo entre algum dom´ınio semˆantico j´a existente e um novo
dom´ınio; tais extens˜oes s˜ao feitas por meio do uso de cl´ausulas extend associadas a
dom´ınios semˆanticos (ver Se¸c˜ao 5.2.4);
• definir um novo caso para o corpo de uma fun¸c˜ao, particularmente para associar a
uma fun¸c˜ao semˆantica j´a existente a equa¸c˜ao semˆantica que define uma nova cons-
tru¸c˜ao; tais extens˜oes s˜ao feitas por meio da defini¸c˜ao de novos casos para fun¸c˜ao
existente (ver Se¸c˜ao 5.4.1.2).
5.1.5 Especifica¸c˜ao Inicial
A pasta da especifica¸c˜ao inicial, L0, possui um m´odulo principal de nome Main, que define
os seguintes elementos utilizados para gera¸c˜ao do interpretador da linguagem:
• s´ımbolo de partida da gram´atica concreta, a partir do qual se obt´em o tipo do n´o
raiz da ´arvore de sintaxe abstrata;
• fun¸c˜ao de denota¸c˜ao de programas para a linguagem, que deve ser uma fun¸c˜ao do
tipo do n´o raiz da ´arvore de sintaxe abstrata da linguagem;
• fun¸c˜ao de pr´e-processamento (opc ional), utilizada para processamento do arquivo de
programa para o analisador l´exico, caso necess´ario;
5.1. ORGANIZAC¸
˜
AO MODULAR 85
1 module Main
2 import p1.∗, p2.∗;
3 syntax prog;
4 semantics p;
5 input stdin, infile ;
6 output stdout, outfile ;
7 preproc prep;
8 end
Listagem 5.3: Exemplo de M´odulo Principal da Linguagem L
• abstra¸c˜oes dos fluxos de entrada e sa´ıda (opcionais) do programa interpretado.
Os elementos utilizados no m´odulo principal podem ser importados de quaisquer m´odulos
definidos nos pacotes da especifica¸c˜ao, de modo que todos os elementos p´ublicos possam ser
referenciados. Caso necess´ario, o m´odulo principal tamb´em pode definir fun¸c˜oes auxiliares
ao processamento.
Um exemplo t´ıpico de m´odulo principal ´e exibido na Listagem 5.3, que define prog como o
s´ımbolo de partida da gram´atica concreta (ver Se¸c˜ao 5.3), p como a fun¸c˜ao semˆantica de
programas (ver Se¸c˜ao 5.4.1.5), entradas feitas a partir da entrada padr˜ao (stdin) e de um
arquivo associado ao identificador infile, sa´ıdas feitas para a sa´ıda padr˜ao (stdout) e para
um arquivo associado ao identificador outfile (ver Se¸c˜ao 5.4.1.5), e prep como a fun¸c˜ao de
pr´e-processamento do programa fonte (ver Se¸c˜ao 5.4.1.4).
O compilador Notus gera, a partir da especifica¸c˜ao inicial, um programa execut´avel L,
ativado por meio da seguinte linha de comando:
L program.l infile=input.txt outfile=output.txt
cujo comportamento pode ser abstra´ıdo pela equa¸c˜ao:
(stdout, outfile) = (p ◦ parser ◦ scanner ◦ prep) source (stdin, infile).
Nesta equa¸c˜ao:
• stdin ´e uma cadeia de caracteres que representa os dados lidos a partir da entrada
padr˜ao, stdout ´e uma cadeia de caracteres que representa o texto a ser escrito na
sa´ıda padr˜ao;
86 CAP
´
ITULO 5. AMBIENTE PARA SEM
ˆ
ANTICA INCREMENTAL
• infile ´e a cadeia de caracteres lida do arquivo de entrada input.txt, conforme es-
pecificado na linha de comando de ativa¸c˜ao do interpretador; outfile ´e a cadeia de
caracteres a ser escrita no arquivo de sa´ıda output.txt, conforme especificado na linha
de comando de ativa¸c˜ao do interpretador;
• source ´e a cadeia de caracteres lida do arquivo fonte program.l;
• prep ´e a fun¸c˜ao de pr´e-processamento, que, caso n˜ao tenha sido especificada pelo
programador, ´e a fun¸c˜ao identidade; esta fun¸c˜ao gera uma cadeia de caracteres re-
presentando o programa fonte pr´e-processado a partir de uma cadeia de caracteres
representando o programa fonte, originalmente lido do arquivo de entrada;
• scanner ´e o analisador l´exico do interpretador, que produz uma s equˆencia de tokens
para o analisador sint´atico a partir de uma cadeia de caracteres que represente o
programa fonte;
• parser ´e o analisador sint´atico
2
do interpretador, que produz a ´arvore de sintaxe
abstrata a partir da sequˆencia de tokens gerados pelo analisador l´exico; o s´ımb olo de
partida ´e o especificado no comando syntax no m´odulo principal;
• p ´e a fun¸c˜ao semˆantica, que produz as sequˆenc ias de sa´ıda a partir da ´arvore de
sintaxe abstrata e das sequˆencias de entrada do interpretador.
A sintaxe de cada um destes elementos do m´odulo principal pode ser econtrada na Se¸c˜ao
A.2.
5.1.6 Extens˜ao de Linguagem
A partir da especifica¸c˜ao inicial, L
0
, toda especifica¸c˜ao L
i
(i > 0) ´e definida a partir
de L
i−1
como L
i
= T
i
(L
i−1
) + ∆L
i
, onde T
i
´e o nome de um m´odulo de transforma¸c˜ao
(ver Se¸c˜ao 5.5) e ∆L
i
representa o conjunto de novas constru¸c˜oes a serem inclu´ıdas na
linguagem, por meio da defini¸c˜ao de novos m´odulos. Assim, a pasta correspondente a uma
especifica¸c˜ao da linguagem deve conter um m´odulo de extens˜ao e um m´odulo de defini¸c˜ao
de transformador.
O m´odulo de extens˜ao define qual transformador deve ser aplicado, a especifica¸c˜ao a ser
estendida e os m´odulos que formam a nova especifica¸c˜ao. O arquivo deve ter o nome
Main.nts e estar localizado na raiz pasta da especifica¸c˜ao, como no exemplo do arquivo
2
A vers˜ao atual do compilador de Notus produz parser LALR(1).
5.2. DOM
´
INIOS 87
1 extension T1(L0)
2 contains Q1.Q11.∗, Q1.Q12.∗, Q2.∗
Listagem 5.4: Exemplo de M´odulo de Extens˜ao Main.nts Para a Linguagem L
Main.nts na pasta L1 na Figura 5.1. O m´odulo de extens˜ao para a especifica¸c˜ao L
i
possui
a forma:
extension T (L
i−1
)
contains modules
onde T representa um nome de m´odulo de transforma¸c˜ao, L
i
representa o nome de uma
especifica¸c˜ao e modules representa a lista dos m´odulos pertencentes a pacotes da pasta
de L
i
utilizados na especifica¸c˜ao. Por exemplo, o m´odulo Main.nts da especifica¸c˜ao da
Figura 5.1 pode s er definido como na Listagem 5.4. Este m´odulo define que a especifica¸c˜ao
L
1
ser´a obtida por meio da transforma¸c˜ao da especifica¸c˜ao L
0
utilizando-se o transformador
T
1
e com a adi¸c˜ao das novas constru¸c˜oes definidas nos m´odulos pertencentes aos pacotes
Q
i
. O m´odulo de transforma¸c˜ao define uma fun¸c˜ao de transforma¸c˜ao e ser´a definido na
Se¸c˜ao 5.5.
5.2 Dom´ınios
5.2.1 Nota¸c˜ao B´asica
Tipos em Notus s˜ao dom´ınios de Scott (Scott 1976). Nestes dom´ınios, existe implicitamente
um elemento bottom (⊥), que ser´a omitido em todos os dom´ınios listados no Cap´ıtulo. O
s´ımbolo de conjunto vazio, ∅, denota o dom´ınio flat “vazio”, que por defini¸c˜ao ´e o conjunto
{⊥}. Al´em disso, as seguintes opera¸c˜oes em dom´ınios s˜ao bem definidas: uni˜ao, interse¸c˜ao,
complemento, uni˜ao disj unta, produto cartesiano, fun¸c˜ao.
O s´ımbolo
´e utilizado para denotar a uni˜ao disjunta de dom´ınios quando for poss´ıvel
associar um ´ındice a cada dom´ınio da uni˜ao. Por exemplo,
n
i=1
d
i
= d
1
+ d
2
+ · · · + d
n
, ao
passo que
s
i
∈S
d
i
= d
s
1
+ d
s
2
+ · · · + d
s
m
, onde S = {s
1
, s
2
, · · · , s
m
}. Cada d
i
, 1 ≤ i ≤ n,
´e uma parcela da uni˜ao.
88 CAP
´
ITULO 5. AMBIENTE PARA SEM
ˆ
ANTICA INCREMENTAL
1 token fun = ...
2 token var = ...
3 token num : Exp = ...
4 exp ::= ...
5 primary : Exp ::= ...
Listagem 5.5: Exemplos de Defini¸c˜ao de Dom´ınio Sint´atico
5.2.2 Dom´ınios Sint´aticos
Dom´ınios sint´aticos s˜ao formados pelos dom´ınios dos terminais e n˜ao-terminais da gram´atica
concreta (ver tokens na Se¸c˜oes 5.3.3 e vari´aveis na Se¸c˜ao 5.3.4). Em Notus, identificadores
de dom´ınios sint´aticos iniciam com letras mai´usculas e podem ser deduzidos automatica-
mente a partir de nomes de tokens e vari´aveis da gram´atica. Assim, se uma defini¸c˜ao de
token ou vari´avel n˜ao definir o seu dom´ınio, ele p ode ser obtido automaticamente capita-
lizando a primeira letra de seu identificador.
Por exemplo, considere o trecho de m´odulo da Listagem 5.5, que define os tokens fun,
var e num, e as vari´aveis exp e primary. Neste exemplo, os dom´ınios Fun, Var e Exp
s˜ao automaticamente detectados da defini¸c˜ao dos tokens fun e var e da vari´avel exp; al´em
disso, o dom´ınio de num e primary ´e Exp conforme especificado pelas suas cl´ausulas de
declara¸c˜ao.
Elementos de dom´ınios e suas express˜oes de defini¸c˜ao s˜ao automaticamente coletadas a
partir das defini¸c˜oes l´exica e sint´atica da linguagem por meio das cl´ausulas de defini¸c˜ao de
tokens (ver Se¸c˜ao 5.3.3.3), extens˜ao de tokens (ver Se¸c˜ao 5.3.3.2), defini¸c˜ao de vari´aveis de
gram´atica concreta (ver Se¸c˜ao 5.3.4.4) e extens˜ao de vari´aveis de gram´atica concreta (ver
Se¸c˜ao 5.3.4.5).
Dom´ınios sint´aticos s˜ao vis´ıveis a todos os m´odulos do pacote onde foram definidos. Para
definir dom´ınios sint´aticos como p´ublicos ou privados, ´e necess´ario utilizar a cl´ausula de
defini¸c˜ao de dom´ınio sint´atico, que possui a forma:
visibility syntactic domain-name ;
O universo de dom´ınios sint´aticos ´e definido recursivamente pelas seguintes regras:
• ∅ ´e o dom´ınio flat vazio;
• se D ´e um dom´ınio padr˜ao, ent˜ao D ´e um dom´ınio sint´atico (ver Se¸c˜ao 5.2.3.2);
5.2. DOM
´
INIOS 89
1 public Value = Int | Bool;
2 public Loc = Int;
3 public State = Loc −> (Value | {unused});
Listagem 5.6: Exemplos de Defini¸c˜ao de Dom´ınio Semˆantico
• se D ´e um dom´ınio de token ou vari´avel, ent˜ao D ´e um dom´ınio sint´atico;
• se D
1
e D
2
s˜ao dom´ınios sint´aticos, ent˜ao D
1
+ D
2
´e um dom´ınio sint´atico que
representa a uni˜ao disjunta de D
1
e D
2
;
• se D
1
e D
2
s˜ao dom´ınios sint´aticos, ent˜ao D
1
× D
2
´e um dom´ınio sint´atico que
representa o produto cartesiano de D
1
e D
2
;
• se D ´e um dom´ınio sint´atico, ent˜ao D* ´e o dom´ınio das listas (possivelmente vazias)
cujos elementos pertencem ao dom´ınio D;
• se D ´e um dom´ınio sint´atico, ent˜ao D+ ´e o dom´ınio das listas n˜ao-vazias cujos ele -
mentos pertencem ao dom´ınio D.
A defini¸c˜ao da sintaxe de dom´ınios sint´aticos pode ser encontrada na Se¸c˜ao A.3.
5.2.3 Dom´ınios Semˆanticos
Dom´ınios semˆanticos em Notus s˜ao utilizados na defini¸c˜ao do universo dos valores presentes
nas defini¸c˜oes semˆanticas e s˜ao definidos por meio da cl´ausula de dom´ınio semˆantico, cuja
forma ´e:
visibility domain-name = domain-expression ;
Por exemplo, o trecho de c´odigo da Listagem 5.6 define dom´ınios semˆanticos Value, Loc e
State.
A defini¸c˜ao da sintaxe de dom´ınios semˆanticos pode ser encontrada na Se¸c˜ao A.3.
5.2.3.1 Express˜oes de Dom´ınio
Dom´ınios semˆanticos podem ser compostos a partir de dom´ınios b´asicos por meio de
opera¸c˜oes de dom´ınio. Os dom´ınios semˆanticos b´asicos s˜ao os dom´ınios pr´e -definidos (ver
Se¸c˜ao 5.2.3.2, p´agina 90) e enumera¸c˜oes (ver Se¸c˜ao 5.2.3.3, p´agina 91).
90 CAP
´
ITULO 5. AMBIENTE PARA SEM
ˆ
ANTICA INCREMENTAL
precedˆencia mais alta tuple, built-in, identifier, enumeration
list
instantiation
functional
precedˆencia mais baixa union
Tabela 5.1: Precedˆencia de Opera¸c˜oes de Dom´ınio
Dom´ınios s˜ao compostos em Notus por meio das seguintes opera¸c˜oes, com precedˆencia
especificada na Tabela 5.1:
• defini¸c˜ao de dom´ınio de uni˜ao disjunta (ver Se¸c˜ao 5.2.3.4, p´agina 92);
• defini¸c˜ao de dom´ınios de tuplas (ver Se¸c˜ao 5.2.3.5, p´agina 92);
• defini¸c˜ao de dom´ınios de lista (ver Se¸c˜ao 5.2.3.6, p´agina 93);
• defini¸c˜ao de dom´ınios funcionais (ver Se¸c˜ao 5.2.3.7, p´agina 94);
• defini¸c˜ao de dom´ınios de sintaxe abstrata (ver Se¸c˜ao 5.2.3.8).
5.2.3.2 Dom´ınios Pr´e-definidos
Os seguintes dom´ınios s˜ao pr´e-definidos em Notus:
• Bool: valores booleanos true e false;
• Byte, Short, Int, Long: n´umeros inteiros com sinal contendo respectivamente 8, 16,
32 e 64 bits;
• Float: n´umeros de ponto flutuante com 32 bits;
• Double: n´umeros de ponto flutuante com 64 bits;
• Character: caracteres delimitados por aspas simples;
• String: cadeias de caracteres delimitadas por aspas, que s˜ao semanticamente equi-
valentes a listas de caracteres.
5.2. DOM
´
INIOS 91
1 public LocationStatus = publi c {unused, occupied, deleted};
2 public Month = {jan, feb, mar, apr, may, jun,
3 jul , aug, sep, oct, nov, dec};
4 public Color = private {red, green, blue};
5 Language = {java, haskell, notus};
6 FileExtension = private {java, hs, nts, exe, txt};
7 private Fruit = {apple, orange, strawberry, lemon};
Listagem 5.7: Exemplos de Defini¸c˜ao de Enumera¸c˜oes
5.2.3.3 Dom´ınios de Enumera¸c˜ao
Enumera¸c˜oes definem conjuntos de constantes simb´olicas e possuem a forma:
{id
1
, id
2
, · · · , id
n
},
onde cada id
i
´e um identificador denominado enumerando. A Listagem 5.7 cont´em exem-
plos de defini¸c˜ao de enumera¸c˜oes.
Os elementos de uma enumera¸c˜ao podem ser p´ublicos, privados, ou vis´ıveis somente para
os m´odulos do mesmo pacote. Enumerandos podem ser definidos como p´ublicos ou pri-
vados por meio do uso da palavra chave correspondente antes das chaves que delimitam
os elementos. A visibilidade de uma enumera¸c˜ao nunca ´e mais restrita que a de seus enu-
merandos. Se um dom´ınio enumera¸c˜ao for privado, ent˜ao seus enumerandos tamb´em s˜ao
privados e o uso da palavra chave private ´e opcional. Nos demais casos, se nenhuma
palavra chave for utilizada, ent˜ao os enumerandos p ossuem visibilidade de pacote. S´o ´e
poss´ıvel definir enumerandos p´ublicos para enumera¸c ˜oes p´ublicas.
Por exemplo, considere as enumera¸c˜oes definidas na Listagem 5.7: LocationStatus ´e uma
enumera¸c˜ao p ´ublica, assim como seus enumerandos; a enume ra¸c˜ao Month ´e p´ublica, mas
seus enumerandos possuem visibilidade de pacote; a enumera¸c˜ao Color ´e p´ublica, mas
seus enumerandos s˜ao privados; a enumera¸c˜ao Language e seus enumerandos possuem
visibilidade de pacote; a enumera¸c˜ao FileExtension possui visibilidade de pacote, e seus
enumerandos s˜ao privados; a enumera¸c˜ao Fruit e seus enumerandos s˜ao privados.
Se um mesmo identificador for utilizado como enumerando em duas enumera¸c˜oes distintas,
ent˜ao a disambigua¸c˜ao pode ser feita por meio da qualifica¸c˜ao com o nome da enumera¸c˜ao.
Por exemplo, o identificador java definido na Listagem 5.7 deve aparecer nas express˜oes do
m´odulo como Language.java e FileExtension.java.
92 CAP
´
ITULO 5. AMBIENTE PARA SEM
ˆ
ANTICA INCREMENTAL
1 Value = Int | Bool | {error};
Listagem 5.8: Exemplo de Dom´ınio Uni˜ao Disjunta
5.2.3.4 Defini¸c˜ao de Dom´ınios Uni˜ao Disjunta
Um dom´ınio uni˜ao disjunta represe nta uma soma separada de dom´ınios e possui a forma:
d
1
| d
2
| · · · | d
n
,
onde cada d
i
´e um dom´ınio; o dom´ınio correspondente ´e d
1
+ d
2
+ · · · + d
n
.
Por exemplo, o dom´ınio Value definido na Listagem 5.8 ´e a uni˜ao disj unta dos dom´ınios
Int, Bool e {error}.
5.2.3.5 Defini¸c˜ao de Dom´ınios Tupla
Um dom´ınio tupla representa o produto cartesiano de dom´ınios e possui a forma:
constructor-name (d
1
, d
2
, · · · , d
n
),
onde cada d
i
´e um dom´ınio; o dom´ınio correspondente ´e d
1
× d
2
× · · · × d
n
. O nome
de construtor ´e utilizado em express˜oes de agregados de tupla (ver Se¸c˜ao 5.4.3.2). Se um
dom´ınio ´e definido por meio de apenas uma express˜ao tupla, ent˜ao o nome de construtor n˜ao
´e obrigat´orio. Dom´ınios de tupla podem ser definidos recursivamente, tais como datatypes
da linguagem Haskell.
Por exemplo, considere dom´ınios Pair, AtMostThree e Tree, definidos por meio de tuplas
na Listagem 5.9. Neste exemplo,
• Pair representa o dom´ınio Int × Bool; o nome de construtor ´e Pair;
• AtMostThree representa o dom´ınio () +Int +(Int ×Int)+(Int×Int×Int) (ver uni˜oes
disjuntas na Se¸c˜ao 5.2.3.4);
• Tree ´e definido recursivamente e representa o dom´ınio das ´arvores bin´arias n˜ao vazias
de elementos do tipo Int.
A estrutura de um dom´ınio tupla possui visibilidade de pacote. Visibilidade p ´ublica ou
privada pode ser obtida inserindo a palavra chave correspondente antes do nome do cons-
trutor. A visibilidade da estrutura de uma tupla nunca ´e menos restrita que o identificador
5.2. DOM
´
INIOS 93
1 Pair = (Int,Bool);
2 AtMostThree = Nil () | One (Int) | Two (Int,Int) | Three (Int,Int,Int );
3 Tree = Leaf Int | Branch (Int,Tree,Tree);
Listagem 5.9: Exemplos de Defini¸c˜oes de Dom´ınios de Tuplas
1 public Complex = public (Real,Real)
2 public LinkedList = List(Node,Node) // first and last elements
3 public Queue = private Queue(Int,LinkedList) // size an d list
4 Node = {nil} | Node(Int,Node) // nil or pair of value and next node
5 Loc = private({location},Int}
Listagem 5.10: Exemplos de Controle de Visibilidade em Dom´ınios de Tupla
da tupla em si. A estrutura de um dom´ınio tupla privado ´e sempre privada, de modo que
o uso da palavra chave private ´e opcional.
O exemplo da Listagem 5.10 define: um dom´ınio p´ublico Complex cuja estrutura ´e tamb´e m
p´ublica; um dom´ınio p´ublico LinkedList cuja estrutura ´e vis´ıvel somente no pacote; um
dom´ınio p´ublico Queue cuja estrutura ´e privada; dom´ınio Node, que ´e completamente
vis´ıvel somente no pacote; e um dom´ınio Location, que ´e vis´ıvel no pacote, mas possui
estrutura privada ao m´odulo. Note que n˜ao existe rela¸c˜ao entre a defini¸c˜ao de visibilidade
e a defini¸c˜ao do nome do construtor.
5.2.3.6 Defini¸c˜ao de Dom´ınios de Lista
Um dom´ınio de lista representa listas de elementos em um dado dom´ınio e possui a forma:
d∗
onde d ´e um dom´ınio; neste caso, o dom´ınio representado cont´em todas as listas cujos ele-
mentos pertencem ao dom´ınio d. Por exemplo, o dom´ınio Input definido na Listagem 5.11
´e uma lista de cadeias de caracteres.
1 Input = String∗;
Listagem 5.11: Exemplo de Defini¸c˜ao de Dom´ınios de Lista
94 CAP
´
ITULO 5. AMBIENTE PARA SEM
ˆ
ANTICA INCREMENTAL
1 Store = Loc −> Value;
2 Econt = Value −> Store −> Store;
Listagem 5.12: Exemplos de Defini¸c˜ao de Dom´ınios Funcionais
1 PrefixExp = Int | [Operator PrefixExp PrefixExp]
2 Operator = ”+” | ”−” | ”∗” | ”/”
Listagem 5.13: Exemplo de Defini¸c˜ao de Dom´ınios de Lista
5.2.3.7 Defini¸c˜ao de Dom´ınios Funcionais
Um dom´ınio funcional represe nta as fun¸c˜oes cont´ınuas (Scott 1976) de um dom´ınio e m
outro, e possui a forma:
d
1
→ d
2
onde d
1
e d
2
s˜ao dom´ınios; neste exemplo, o dom´ınio representado cont´em todas as fun¸c˜oes
cont´ınuas de d
1
em d
2
.
Por exemplo, considere os dom´ınios funcionais Store e Econt definidos na Listagem 5.12. O
operador → ´e associativo `a direita, fazendo com que Econt represente o dom´ınio Value →
(Store → Store).
5.2.3.8 Defini¸c˜ao de Dom´ınios de Sintaxe Abstrata
Algumas fun¸c˜oes, tais como transforma¸c˜oes de sintaxe abstrata, podem exigir a defini¸c˜ao
de novas estruturas de n´os de ´arvore de sintaxe abstrata. Uma defini¸c˜ao de dom´ınio de
sintaxe abstrata possui a forma:
[ d
1
d
2
· · · d
n
],
onde cada d
i
representa uma cadeia de caracteres ou um dom´ınio sint´atico v´alido.
Por exemplo, o dom´ınio PrefixExp definido na Listagem 5.13 representa um dom´ınio de
sintaxe abstrata.
5.3. DEFINIC¸
˜
AO SINT
´
ATICA 95
1 Value = Bool;
2 extend Value with Int;
Listagem 5.14: Exemplo de Extens˜ao de Dom´ınios
5.2.4 Extens˜oes de Dom´ınios
Dom´ınios sint´aticos e semˆanticos podem ser es tendidos por meio de cl´ausulas de extens˜ao
de dom´ınios, que possuem a seguinte forma:
extend domain-name with domain-expression;
Se um dom´ınio D ´e definido por d
1
, ent˜ao a e xtens˜ao inclui d
2
na defini¸c˜ao de D, de
modo que este passe a representar a uni˜ao disjunta d
1
+ d
2
. Se o dom´ınio estendido
for um dom´ınio sint´atico, ent˜ao a express˜ao de dom´ınio deve neces sariamente ser uma
especifica¸c˜ao de dom´ınio sint´atico, isto ´e, uma especifica¸c˜ao de dom´ınio de n´o de ´arvore de
sintaxe abstrata (ver Se¸c˜ao 5.3.4.3).
Por exemplo, no fragmento de c´odigo na Listagem 5.14, o identificador Value representa,
ap´os a extens˜ao, o dom´ınio Bool + Int.
5.3 Defini¸c˜ao Sint´atica
5.3.1 Nota¸c˜ao B´asica
Express˜oes Regulares. Express˜oes regulares s˜ao utilizadas nas defini¸c˜oes de analisador
l´exico e sua nota¸c˜ao ´e similar `a nota¸c˜ao usual de express˜oes regulares encontrada em livros
de Teoria de Linguagens. Ao longo do cap´ıtulo, dada uma express˜ao regular R, L(R) ´e a
linguagem denotada por R.
Gram´aticas Livres Contexto. Gram´aticas livres de contexto s˜ao escritas de maneira
semelhante `a Forma de Backus-Naur (BNF) com nota¸c˜ao especial para repeti¸c˜ao de s´ımbo-
los. Assim como definido para express˜oes regulares, dada uma gram´atica G, L(G) denota
a linguagem gerada por G.
96 CAP
´
ITULO 5. AMBIENTE PARA SEM
ˆ
ANTICA INCREMENTAL
1 module Main
2 ... // module constituents
3 preproc f;
4 ... // other module constituents
5 end
Listagem 5.15: Exemplo de Defini¸c˜ao de Fun¸c˜ao de Pr´e-processamento do Arquivo Fonte
5.3.2 Pr´e-processamento de Arquivo Fonte
Algumas linguagens, tais como Haskell, definem regras de simplifica¸c˜ao da sintaxe, que
auxiliam o programador a n˜ao poluir o seu c´odigo com delimitadores dedut´ıveis a partir do
contexto. Tais simplifica¸c˜oes podem ser implementadas em Notus por meio de fun¸c˜oes de
pre-processamento de arquivo fonte, que mapeia o fluxo de entrada fornecido no arquivo
fonte em um novo fluxo de entrada para o analisador l´exico.
A fun¸c˜ao de pr´e-processamento para uma linguagem ´e definida por meio de cl´ausula de
pr´e-processamento no m´odulo principal da especifica¸c˜ao inicial, e possui a forma:
preproc function-name
onde function-name ´e um nome de fun¸c˜ao vis´ıvel no m´odulo principal. O dom´ınio desta
fun¸c˜ao deve ser String → String. Fun¸c˜oes s˜ao apresentadas na Se¸c˜ao 5.4.1 (p´agina 113), e
fun¸c˜oes de pr´e-processamento, na Se¸c˜ao 5.4.1.4 (p´agina 114).
Por exemplo, seja Main o m´odulo principal da especifica¸c˜ao de uma linguagem L e seja
f a fun¸c˜ao de pr´e-processamento de L. Ent˜ao, o m´odulo Main deve ser definido como na
Listagem 5.15.
5.3.3 Defini¸c˜ao do Analisador L´exico
O analisador l´exico ´e gerado automaticamente a partir da defini¸c˜ao dos tokens da lingua-
gem. Cada m´odulo pode introduzir novos identificadores representando:
• tokens da linguagem, i.e., identificadores que s˜ao s´ımbolos terminais na defini¸c˜ao
sint´atica (ver Se¸c˜ao 5.3.4);
• macros, que podem representar partes da defini¸c˜ao de tokens complexas.
5.3. DEFINIC¸
˜
AO SINT
´
ATICA 97
1 public token id : Id = seqld ;
2 public token num : Num = digit+ is asInteger ;
3 element seqld = letter ( letter | digit ) ∗ ;
4 public element letter = [A−Za−z];
5 public element digit = [0−9] ;
Listagem 5.16: Exemplos de Defini¸c˜ao de Tokens e Macros
Tanto tokens quanto macros s˜ao definidos por meio de nota¸c˜ao de express˜oes regulares (ver
Se¸c˜ao 5.3.3.1) e podem ser definidos com visibilidade p´ublica, privada ou de pacote. Tokens
podem ainda pertencer a dom´ınios sint´aticos (ver Se¸c˜ao 5.2.2). Por exemplo, considere
uma linguagem cujos tokens s˜ao sequˆencias de d´ıgitos de zero a nove e identificadores,
representados por sequˆe ncias de letras mai´usculas e min´usculas e d´ıgitos, e que iniciem
com uma letra. O trecho de c´odigo mostrado na Listagem 5.16 define o token num, que
representa n´umeros inteiros, o token id, que representa identifiers, a macro letter, que
representa letras, a macro digit, que representa d´ıgitos, e a macro seqld, que representa
sequˆencias de letras e d´ıgitos iniciando com letra. Os tokens num e id, e as macros letter
e digit s˜ao p´ublicas, ao passo que a macro seqld possui visibilidade de pacote.
A especifica¸c˜ao de um token pode definir seu dom´ınio sint´atico e como o lexema correspon-
dente ´e interpretado. No exemplo da Listagem 5.16, o token num ´e definido com elemento
do dom´ınio Num, e o lexema associado ´e interpretado como um n´umero inteiro. Defini¸c˜oes
de lexemas s˜ao poss´ıveis somente para tokens que possu´ırem um dom´ınio esp ecificado.
´
E
poss´ıvel tamb´em associar a de fini¸c˜ao de um lexema a uma fun¸c˜ao de interpreta¸c˜ao (ver
Se¸c˜ao 5.4.1) que recebe uma cadeia de caracteres como argumento e retorna um valor
pertencente ao dom´ınio sint´atico do token correspondente. As seguintes fun¸c˜oes padr˜ao
podem ser utilizadas para a constru¸c˜ao de tokens:
• asBoolean: String → Bool;
• asByte: String → Byte;
• asShort: String → Short;
• asInteger: String → Int;
• asLong: String → Long;
• asFloat: String → Float;
98 CAP
´
ITULO 5. AMBIENTE PARA SEM
ˆ
ANTICA INCREMENTAL
1 ignore layoutchar | comment ;
2 element layoutchar = ” ” | ”\n” | ”\t” | ”\r” | ”\f” ;
3 element comment = ”//” .∗ ;
Listagem 5.17: Exemplos do Uso de Cl´ausulas Ignore
• asDouble: String → Double;
• asCharacter: String → Char;
Por outro lado, quando uma defini¸c˜ao de token n˜ao cont´em a cl´ausula is, o lexema cor-
respondente ´e tratado como uma cadeia de caracteres e a fun¸c˜ao de interpreta¸c˜ao ´e a
identidade, λs.s. Se o dom´ınio de um token n˜ao for definido, ent˜ao o dom´ınio pode ainda
ser obtido tornando a primeira letra de seu identificador mai´uscula. Se n˜ao existir dom´ınio
com o nome obtido, ent˜ao tem-se um token anˆonimo. No exemplo da Listagem 5.16, o
token id pertence ao dom´ınio Id, e o lexema correspondente ´e uma cadeia de caracteres
correspondente ao texto casado na an´alise l´exica.
Especifica¸c˜oes l´exicas podem ainda definir s´ımbolos, tais como espa¸cos em branco, que
devem ser ignorados pelo analisador l´exico. Essa defini¸c˜ao ´e feita por meio do uso de
cl´ausula ignore. Por exemplo, o trecho de c´odigo na Listagem 5.17 define que alguns
caracteres especiais e coment´arios de linha devem ser ignorados.
5.3.3.1 Express˜oes Regulares
Express˜oes regulares em Notus s˜ao formadas por caracteres, cadeias de caracteres, identifi-
cadores e as opera¸c˜oes: concatena¸c˜ao, representada por justaposi¸c˜ao de express˜oes; uni˜ao,
por meio do operador "|"; fecho de Kleene, por meio dos operadores "*" e "+"; op¸c˜ao, por
meio do "?".
Al´em disso, express˜oes regulares que representem conjuntos de caracteres podem ser defi-
nidos pela enumera¸c˜ao dos caracteres entre colchetes, como em [abc].
´
E tamb´em poss´ıvel
definir charsets por meio de intervalos, designando-se o primeiro e o ´ultimo elementos, como
em [a-z]. Se necess´ario, intervalos e caracteres individuais podem ser utilizados para defi-
nir conjuntos mais complexos, como em [a-zA-Z
], que representa o conjunto de caracteres
formado por letras min´usculas, letras ma´ısculas e o s´ımbolo .
Al´em disso, charsets podem ainda ser definidos por meio do complemento de um conjunto,
como em [ˆabc], que representa qualquer caractere diferente de a, b e c, ou [ˆa-zA-Z] que
5.3. DEFINIC¸
˜
AO SINT
´
ATICA 99
precedˆencia mais alta “*”, “+”, “?”
concatena¸c˜ao
precedˆencia mais baixa “|”
Tabela 5.2: Precedˆencia das Opera¸c˜oes de Express˜oes Regulares
Express˜ao Descri¸c˜ao
"//".* Coment´ario de linha
[0-9]+("."[0-9]+)?([eE]"-"?[0-9]+)? N´umero de ponto flutuante
[a-zA-Z ][a-zA-Z 0-9]* Identificador
[+\-*/%] Operadores aritm´eticos
[\n\f\r\t\a\b"\’] Caracteres de escape
Tabela 5.3: Exemplos de Express˜oes Regulares
casa com qualquer caractere que n˜ao seja uma letra. Em defini¸c˜oes de charsets, barra
invertida (\) pode ser utilizada como escape para os seguintes s´ımbolos:
\n, \r, \f, \t, \a, \b, \" , \’, \-, \^, \[, \], \\
O s´ımb olo “.”representa qualquer caractere diferente de fim de linha ("\n").
Concatena¸c˜ao e uni˜ao s˜ao associativos `a esquerda, ao passo que as demais opera¸c ˜oes n˜ao
s˜ao associativas. A ordem de precedˆencia ´e mostrada na Tabela 5.2. A Tabela 5.3 cont´em
exemplos de express˜oes regulares v´alidas em Notus.
5.3.3.2 Extens˜ao de Tokens e Macros
Se necess´ario, ´e poss´ıvel estender defini¸c˜oes de tokens e macros por meio da uni˜ao da
express˜ao corrente com uma nova express˜ao regular. Defini¸c˜oes de tokens e macros podem
ser estendidas por meio de cl´ausulas de extens˜ao, que possuem a forma:
extend id with expression;
Por exemplo, considere os tokens number e id definidos nas linhas 1 e 2 da Listagem 5.18,
respectivamente. A inclus˜ao de n´umeros inteiros em hexa-decimal com formato semelhante
ao utilizado na linguagem C pode ser feita por meio da cl´ausula de extens˜ao da linha 4 na
mesma listagem. A defini¸c˜ao de identificadores iniciados com o caractere pode ser feita
por meio da cl´ausula de extens˜ao da linha 5 do mesmo exemplo.
100 CAP
´
ITULO 5. AMBIENTE PARA SEM
ˆ
ANTICA INCREMENTAL
1 token number : Num = [0−9]+ is getNumber
2 token id : Id = [a−z]+[0−9]∗ is getId
3 ...
4 extend token number with ”0x”[0−9A−Fa−f]+ is getNumberInHexa
5 extend token id with ” ”[a−z]+[0−9]∗
Listagem 5.18: Exemplos de Extens˜ao de Tokens
1 element letter = [a−z] ;
2 extend letter with [A−Z] ;
Listagem 5.19: Exemplo de Equivalˆencia da Extens˜ao de Macros – Parte I
Uma extens˜ao de token pode ainda redefinir o seu dom´ınio sint´atico. No entanto, s´o ´e
poss´ıvel definir uma nova fun¸c˜ao a ser aplicada ao lexema quando a nova express˜ao regular
for casada. No exemplo da Listagem 5.18, quando uma cadeia de caracteres s casar com
a express˜ao regular [0-9]+, a fun¸c˜ao getNumber ´e aplicada a s; por outro lado, se s casar
com “0x”[0-9A-Fa-f]+, ent˜ao a fun¸c˜ao getNumberInHexa ´e aplicada a s.
Se um token t, designado pela express˜ao regular R
1
, for estendido para designar tamb´em
a express˜ao R
2
, ent˜ao a linguagem denotada pelo token t ´e L(R
1
) ∪ L(R
2
).
Extens˜ao de macros ´e feita de maneira similar `a extens˜ao de tokens. Considere a macro e
definida pela express˜ao regular R
1
; se e for estendida pela express˜ao regular R
2
, ent˜ao e
passa a denotar a linguagem L(R
1
) ∪ L(R
2
). Por exemplo, a defini¸c˜ao na Listagem 5.19 ´e
equivalente `a defini¸c ˜ao na Listagem 5.20.
5.3.3.3 Dom´ınios Sint´aticos de Tokens
O dom´ınio de um token t ´e a uni˜ao disjunta dos tipos correspondentes aos lexemas repre-
sentados por t. Por exemplo, considere o trecho de c´odigo da Listagem 5.21, que define os
dom´ınios Id e Value, e os tokens id, num e bool.
O token id pertence ao dom´ınio Id, e os tokens num e bool pertencem ao dom´ınio Value.
Os lexemas correspondentes ao token id s˜ao as cadeias de caracteres casadas pelo analisa-
1 element letter = [a−z] | [A−Z] ; // or [a−zA−Z]
Listagem 5.20: Exemplo de Equivalˆencia da Extens˜ao de Macros – Parte II
5.3. DEFINIC¸
˜
AO SINT
´
ATICA 101
1 token id = [a−zA−Z]+;
2 token num : Value = [0−9]+ is asInteger ;
3 token bool : Value = ”true” | ”false” is asBoolean ;
Listagem 5.21: Exemplo de Defini¸c˜ao de Dom´ınio Sint´atico de Tokens
dor l´exico, uma vez que n˜ao h´a especifica¸c˜ao da fun¸c˜ao de lexema. Al´em disso, os lexemas
correspondentes ao token num s˜ao n´umeros inteiros n˜ao-negativos, e os lexemas correspon-
dentes ao token bool s˜ao os valores true e false. Com isso, os dom´ınios Value e Id s˜ao
definidos como:
Value = N + {true, false}
Id = L ([a-zA-Z]+)
Formalmente, seja d um dom´ınio sint´atico, e t
1
, t
2
, · · · , t
m
os tokens da especifica¸c˜ao de-
finidos no dom´ınio d. Suponha que cada token t
i
seja definido por meio das express˜oes
regulares R
i1
, R
i2
, · · · , R
in
i
, e cada R
ij
seja associado a uma fun¸c˜ao de lexema f
ij
. O
dom´ınio d ´e definido como:
d =
m
i=1
n
i
j=1
{f
ij
(u) | u ∈ L (R
ij
)}
A partir desta defini¸c˜ao, o dom´ınio Value no exemplo anterior ´e definido por:
Value = {asInteger u | u ∈ L ([0-9]+)}
+ {asBoolean u | u ∈ L ( "true" | "false" )}
= N + {true, false}
5.3.3.4 Ambiguidades na Defini¸c˜ao de Tokens
Ambiguidades na defini¸c˜ao de tokens ocorrem quando existe uma cadeia de caracteres s e
dois tokens t
1
e t
2
, representando express˜oes regulares R
1
e R
2
, tal que s ∈ L(R
1
) ∩ L(R
2
).
Geradores de analisadores l´exicos t´ıpicos resolvem tais ambiguidades utilizando a ordem
em que t
1
e t
2
s˜ao definidos no arquivo fonte. No entanto, essa regra n˜ao pode ser aplicada
em Notus, uma vez que a linguagem n˜ao imp˜oe ordem para a defini¸c˜ao de tokens em um
arquivo, e, al´em disso, defini¸c˜oes de tokens n˜ao precisam necessariamente estar confinadas
em um ´unico m´odulo.
102 CAP
´
ITULO 5. AMBIENTE PARA SEM
ˆ
ANTICA INCREMENTAL
1 token decNumber = [0−9]+
2 token octNumber = ”0”[0−7]+
3 token hexNumber = ”0 x”[0−9a−f]+
4 token score = [0−9]+”x”[0−9]+
Listagem 5.22: Exemplos de Ambiguidades nas Defini¸c˜oes de Tokens
Para resolver tais ambiguidades, a linguagem Notus aplica as seguintes regras de desam-
bigua¸c˜ao de uma cadeia de caracteres s que case com as express˜oes regulares R
1
e R
2
dos
tokens t
1
e t
2
:
• se L(R
1
) ⊂ L(R
2
), L(R
1
) = L(R
2
) e s ∈ L(R
1
), ent˜ao considera-se que s case com o
token t
1
;
• se L(R
1
) ⊂ L(R
2
), L(R
2
) ⊂ L(R
1
) e L(R
1
)∩L(R
2
) = ∅, ent˜ao um erro de compila¸c˜ao
deve ser indicado, pois n˜ao ´e poss´ıvel decidir se s ∈ L(R
1
)∩L(R
2
) deve ser considerado
como token t
1
ou t
2
.
No exemplo da Listagem 5.22, seja L
1
a linguagem representada pelo token decNumber, L
2
a linguagem representada pelo token octNumber, L
3
a linguagem representada pelo token
hexNumber, e L
4
a linguagem representada pelo token score.
´
E f´acil verificar que L
2
⊂ L
1
;
assim, qualquer cadeia de caracteres que casar com a express˜ao regular “0”[0-7]+ pertence
`a linguagem L
2
. Por outro lado, h´a cadeias que casam tanto com “0x”[0-9a-f]+ quanto com
[0-9]+“x”[0-9]+, como por exemplo 0x0; por´em nem L
3
⊂ L
4
3
e nem L
4
⊂ L
3
4
. Assim,
n˜ao ´e poss´ıvel decidir quais tokens representam algumas strings, e por esta raz˜ao, um erro
de compila¸c˜ao ´e gerado.
5.3.4 Defini¸c˜ao do Analisador Sint´atico
O analisador sint´atico da linguagem ´e gerado automaticamente a partir das defini¸c˜oes de
dom´ınios sint´aticos, das regras de produ¸c˜ao e do s´ımbolo de partida da gram´atica concreta.
O analisador sint´atico gerado processa a sequˆencia de tokens fornecida pelo analisador
l´exico e produz como resultado a ´arvore de sintaxe abstrata correspondente ao programa.
Esta ´arvore se r´a um dos argumentos da fun¸c˜ao semˆantica de programas da especifica¸c˜ao.
3
Um contra-exemplo ´e a cadeia s = 0x8a, pois s ∈ L
3
e s /∈ L
4
.
4
Um contra-exemplo ´e a cadeia s = 5x3, pois s ∈ L
4
e s /∈ L
3
.
5.3. DEFINIC¸
˜
AO SINT
´
ATICA 103
1 public comm : Comm ;
2 private cond : Comm ;
3 assign : Comm ;
Listagem 5.23: Exemplos de Visibilidade das Vari´aveis de uma Gram´atica
1 public exp : Exp ::= exp ”+” term | exp ”−” term | term ;
2 term : Exp ::= term ”∗” primary | term ”/” primary | primary ;
3 primary : Exp ::= id | ”(” exp ”)” | num ;
Listagem 5.24: Exemplos de Defini¸c˜ao de Regras de Produ¸c˜ao
Uma defini¸c˜ao sint´atica em Notus consiste nas defini¸c˜oes de sintaxes concreta e abstrata
da linguagem, ambas definidas por meio de gram´aticas livres de contexto. Geralmente,
o projetista define os nomes dos dom´ınios sint´aticos (veja Section 5.2.2) e a gram´atica
concreta, e o compilador Notus gera automaticamente a estrutura dos dom´ınios sint´aticos
e a gram´atica abstrata.
Os terminais da gram´atica concreta s˜ao os tokens, definidos por meio das cl´ausulas de
elementos l´exicos. Os n˜ao-terminais s˜ao definidos por meio de declara¸c˜oes de vari´aveis,
que listam identificadores das vari´aveis e os dom´ınios que elas representam. Assim como
na defini¸c˜ao de tokens, vari´aveis pode m possuir visibilidade p´ublica, privada ou de pacote.
Por exemplo, na Listagem 5.23 a vari´avel comm ´e p´ublica, a vari´avel assign ´e vis´ıvel somente
no pacote, e a vari´avel cond ´e privada. Neste exemplo, todas as vari´aveis pertencem ao
dom´ınio sint´atico Comm.
Regras de produ¸c˜ao da gram´atica concreta podem ser definidas na declara¸c˜ao de suas
vari´aveis do lado esquerdo ou p or meio de cl´ausulas de extens˜ao (ver Se¸c˜ao 5.3.4.5). Por
exemplo, o trecho de c´odigo na Listagem 5.24 define regras de produ¸c˜ao para uma lingua-
gem de express˜oes simples. Consideram-se nesta defini¸c˜ao os tokens num e id, definidos na
Se¸c˜ao 5.3.3.
Nomes que aparecem em uma regra de produ¸c˜ao devem identificar tokens ou vari´aveis da
gram´atica. S´ımbolos entre aspas duplas s˜ao tokens literais da linguagem e s˜ao automa-
ticamente inclu´ıdas no l´e xico. No exemplo da Listagem 5.24, os s´ımbolos "+", "-", "*",
"/", "(" e ")" s˜ao automaticamente inseridos no l´exico da linguagem, de modo que n˜ao
´e necess´ario definir tokens que os representem. Tais tokens n˜ao possuem, desta maneira,
especifica¸c˜ao de dom´ınio e, portanto, s˜ao associados a dom´ınios anˆonimos unit´arios que
contˆem os valores literais correspondentes.
104 CAP
´
ITULO 5. AMBIENTE PARA SEM
ˆ
ANTICA INCREMENTAL
5.3.4.1 Gram´aticas Livres de Contexto
A sintaxe de uma linguagem em Notus deve ser definida por meio de uma gram´atica livre
de contexto LALR(1)
5
. Se G = (V, T, R, S) for uma gram´atica livre de contexto para
alguma linguagem arbitr´aria L, ent˜ao G deve ser definida em Notus da seguinte maneira:
• o conjunto de n˜ao-terminais V ´e composto por todas as vari´aveis declaradas nos
m´odulos da especifica¸c˜ao de L;
• o conjunto de terminais T ´e composto por todos os tokens declarados e por todos os
s´ımbolos entre aspas que aparecem em regras de produ¸c˜ao definidas nos m´odulos da
especifica¸c˜ao de L;
• o conjunto de regras de produ¸c˜ao R ´e composto pelas regras definidas nos m´odulos
da especifica¸c˜ao de L;
• o s´ımbolo inicial S ∈ V ´e designado pela cl´ausula de s´ımbolo de partida no m´odulo
principal da especifica¸c˜ao de L (ver Se¸c˜ao 5.1.5).
Regras de produ¸c˜ao s˜ao definidas em nota¸c˜ao semelhante a BNF, com atalhos para re-
peti¸c˜ao de s´ımbolos. Uma regra em R possui a forma: A ::= α
1
α
2
· · · α
n
, onde A ´e um
elemento de V , cada α
i
, 1 ≤ i ≤ n, ´e um constituinte de regra, e n ≥ 0. Cada constituinte
pode ser:
• um elemento de V ;
• um elemento de T ;
• uma repeti¸c˜ao de constituintes, de uma das seguintes formas:
– α*, que representa qualquer quantidade de ocorrˆencias de α;
– α+, que representa pelo menos uma ocorrˆencia de α;
– α*-t, que representa qualquer n´umero de ocorrˆencias de α, separadas pelo token
t, em que t ´e um token anˆonimo
6
;
5
Esta restri¸c˜ao se deve `a implementa¸c˜ao atual do compilador da linguagem Notus. Vers˜oes futuras da
linguagem poder˜ao eventualmente utilizar outro formalismo.
6
Tokens anˆonimos s˜ao cadeias de caracteres que aparecem do lado direito em regras de produ¸c˜ao e,
geralmente, indicam separadores e palavras chaves.
5.3. DEFINIC¸
˜
AO SINT
´
ATICA 105
1 prog ::= decls comms
2 decls ::= decl∗−”;”
3 decl ::= ”var” id+−”,”
4 comms ::= comm+
5 comm ::= id ”<−” exp
6 | ” if” exp ”then” comm ”else” comm
7 | block
8 block ::= ”{” comm∗ ” }”
Listagem 5.25: Exemplos de Repeti¸c˜ao em Regras de Produ¸c˜ao
– α+-t, que representa pelo menos uma ocorrˆencia de α, separadas pelo token t,
em que t ´e um token anˆonimo;
No e xemplo da Listagem 5.25: o n˜ao-terminal decls produz uma sequˆencia possivelmente
vazia de decl separadas por ponto-e-v´ırgula; o n˜ao-terminal decl produz uma sequˆencia n˜ao-
vazia de id separados por v´ırgula e precedida pela palavra “var”; o n˜ao-terminal comms
produz uma sequˆencia n˜ao-vazia de comm; o n˜ao-terminal block produz uma sequˆencia
possivelmente vazia de comm entre chaves.
A escrita de regras de produ¸c˜ao da forma A → λ pode ser feita de uma das seguintes
maneiras:
A ::=
A ::= empty
Nesta defini¸c˜ao, empty ´e um terminal especial que representa a sequˆencia de s´ımbolos
vazia.
Para permitir que as gram´aticas definidas em Notus sejam processadas por geradores de
parser LALR(1) tradicionais, define-se a fun¸c˜ao ζ : G → G, onde G ´e o conjunto das
gram´aticas livres de contexto. Dada uma gram´atica em Notus G, G
= ζ(G) ´e uma
nova gram´atica cujas regras de produ¸c˜ao est˜ao em conformidade com a nota¸c˜ao BNF e
L(G) = L(G
), i.e. G e G
geram a mesma linguagem. A fun¸c˜ao ζ ´e definida na Se¸c˜ao C.1.
106 CAP
´
ITULO 5. AMBIENTE PARA SEM
ˆ
ANTICA INCREMENTAL
1 module Main
2 ... // module constituents
3 syntax program;
4 ... // other module constituents
Listagem 5.26: Exemplo de Defini¸c˜ao do S´ımbolo de Partida de uma Linguagem
5.3.4.2 Defini¸c˜ao de S´ımbolo de Partida
O s´ımbolo de partida da gram´atica ´e definido por meio da cl´ausula de defini¸c˜ao de s´ımb olo
de partida no m´odulo principal da especifica¸c˜ao. Esta cl´ausula possui a forma:
syntax start−symbol−name;
onde start-symbol-name ´e um n˜ao-terminal da gram´atica vis´ıvel a partir do m´odulo prin-
cipal. O s´ımbolo de partida deve ser definido unicamente no m´odulo principal da especi-
fica¸c˜ao inicial e n˜ao pode ser alterado nas demais extens˜oes da linguagem.
Por exemplo, o m´odulo principal da especifica¸c˜ao de uma linguagem hipot´etica L, mostrado
na Listagem 5.26, define o n˜ao-terminal program como o s´ımbolo de partida da gram´atica
de L.
5.3.4.3 Defini¸c˜ao da Sintaxe Abstrata
A sintaxe abstrata da linguagem ´e obtida automaticamente a partir da especifica¸c˜ao da
sintaxe concreta, por meio de uma fun¸c˜ao χ : G → G, tal que dada uma gram´atica Notus
G = (V, T, R, S), G
= χ(G) ´e a gram´atica abstrata correspondente a G. A fun¸c˜ao χ
est´a definida na Se¸c˜ao C.3. A vers˜ao final da gram´atica abstrata ´e obtida a partir de G
,
eliminando-se s´ımbolos e regras de produ¸c˜ao in´uteis, conforme os algoritmos descritos na
Se¸c˜ao C.2.
Por exemplo, considere o m´odulo Main da Listagem 5.27, em que se define uma linguagem
simples de express˜oes.
A gram´atica abstrata da linguagem ´e G
= (V
, T
, R
, Exp), onde:
• V
= {Id, Num, Exp};
• T
= {"+" , -, "*" , "/" , "(" , ")" , id, num}
5.3. DEFINIC¸
˜
AO SINT
´
ATICA 107
1 module Main
2
3 // Lexis
4 public token id = seqld ;
5 public token num = digit+ is asInteger ;
6
7 element seqld = letter ( letter | digit ) ∗ ;
8 public element letter = [A−Za−z] ;
9 public element digit = [0−9] ;
10
11 // Syntax
12 syntax exp
13
14 public exp ::= exp ”+” term | exp ”−” term | term ;
15 public term : Exp ::= term ”∗” factor | term ”/ ” factor | factor ;
16 public factor : Exp ::= ”(” exp ”)” | id | num ;
17
18 // Semantics
19 ...
Listagem 5.27: Exemplo de Defini¸c˜ao de Gram´atica Concreta Para Express˜oes
108 CAP
´
ITULO 5. AMBIENTE PARA SEM
ˆ
ANTICA INCREMENTAL
1 public exp : Exp ::=
2 exp ”+” term : [ ”add” exp term ] // rule 1
3 | exp ” −” term : [ ”sub” exp term ] // rule 2
4 | term ; // rule 3
5 term : Exp ::=
6 term ”∗” primary : [ ”mul” term primary ] // rule 4
7 | term ”/” primary : [ ”div” term primary ] // rule 5
8 | primary ; // rule 6
9 primary : Exp ::=
10 id : id // rule 7
11 | num : num // rule 8
12 | ”(” exp ”)” : exp ; // rule 9
Listagem 5.28: Exemplo de Defini¸c˜ao Alternativa de Sintaxe Abstrata
• R
: Exp → Exp "+" Exp
| Exp - Exp
| Exp "*" Exp
| Exp "/" Exp
| "(" Exp ")"
| Id
| Num
Id → id
Num → num
Al´em disso, caso uma especifica¸c˜ao de sintaxe abstrata seja desej´avel, ent˜ao ´e poss´ıvel
definir a tradu¸c˜ao anexando-se regras de defini¸c˜ao alternativas `as regras de produ¸c˜ao da
gram´atica concreta. Por exemplo, considere a defini¸c˜ao de express˜oes na Listagem 5.28,
que ilustra os mecanismos de defini¸c˜ao alternativa de sintaxe abstrata de Notus.
O primeiro mecanismo ´e a defini¸c˜ao de regra de gram´atica abstrata que consiste em anexar
`a regra de produ¸c˜ao um novo lado direito; esta constru¸c˜ao possui a forma:
a → a
1
a
2
· · · a
n
: [ b
1
b
2
· · · b
m
]
em que cada b
i
´e um dos a
j
ou uma cadeia de caracteres entre aspas. Se a pertencer ao
dom´ınio d e cada b
i
ao dom´ınio d
i
, ent˜ao a regra de gram´atica abstrata ´e d → d
1
d
2
· · · d
m
.
O segundo mecanismo ´e a defini¸c˜ao de regras para ignorar indire¸c˜ao, que consiste em anexar
`a regra de produ¸c˜ao uma das vari´aveis presentes no lado direito da regra de produ¸c˜ao
5.3. DEFINIC¸
˜
AO SINT
´
ATICA 109
concreta, e possui a forma:
a → a
1
a
2
· · · a
n
: a
i
onde a
i
´e um n˜ao-terminal ou um terminal pertencente ao conjunto {a
1
, a
2
, · · · , a
n
}. Neste
caso, considerando-se que a perten¸ca ao dom´ınio d e que a
i
perten¸ca ao dom´ınio d
i
, ent˜ao a
gram´atica abstrata possui uma regra d → b
1
b
2
· · · b
m
para cada d
i
→ b
1
b
2
· · · b
m
pertencente
`a gram´atica abstrata. O efeito desta transforma¸c˜ao, em vez de criar um novo n´o quando
esta regra de produ¸c˜ao for reduzida, reutilizar o n´o correspondente ao n˜ao-terminal a
i
.
No exemplo da Listagem 5.28, as regras de produ¸c˜ao 3 e 6 n˜ao possuem defini¸c˜oes alter-
nativas e, por esta raz˜ao, uma nova regra Exp → Exp ´e inclu´ıda na gram´atica abstrata
7
.
Por outro lado, as regras 1, 2, 4 e 5 definem regras alternativas. Em cada caso, define-se
uma nova regra de produ¸c˜ao na gram´atica abstrata tendo como lado esquerdo o dom´ınio
sint´atico Exp. Al´em disso, as regras 7, 8 e 9 definem indire¸c˜oes a ser ignoradas. Para a
regra 7, uma nova regra Exp → id ´e inclu´ıda na gram´atica abstrata, uma vez que existe
a regra Id → id
8
. Da mesma forma, para a regra 8, uma nova regra Exp → num ´e
inclu´ıda na gram´atica abstrata. Para a regra 9, uma nova regra Exp → Exp ´e adicionada
`a gram´atica abstrata
9
.
A gram´atica abstrata correspondente ao exemplo, ap´os simplificada pelos algoritmos apre-
sentados na Se¸c˜ao C.2 ´e G
A
Exp
= (V
, T
, R
, Exp), onde:
• V
= {Id, Num, Exp};
• T
= {"add" , "sub" , "mul" , "div" , id, num}
• R
: Exp → "add" Exp Exp
| "sub" Exp Exp
| "mul" Exp Exp
| "div" Exp Exp
| id
| num
Na defini¸c˜ao alternativa de regras de produ¸c˜ao, se algum s´ımbolo aparecer mais de uma
vez do lado direito de uma regra, ent˜ao ´e poss´ıvel distinguir cada ocorrˆencia pelo uso de
sufixos num´ericos nos identificadores. Por exemplo, considere a defini¸c˜ao de comandos no
7
Esta regra ser´a sujeita a simplifica¸c˜ao da gram´atica discutida na Se¸c˜ao C.2
8
Ver fun¸c˜ao χ
na Se¸c˜ao C.3
9
Esta regra ser´a sujeita a simplifica¸c˜ao da gram´atica discutida na Se¸c˜ao C.2
110 CAP
´
ITULO 5. AMBIENTE PARA SEM
ˆ
ANTICA INCREMENTAL
1 public comm : Comm ::=
2 id ”=” exp ”;” : [ id ”:=” exp ]
3 | ”if ” ”(” exp ”)” comm1 ”else” comm2
4 : [ ”if” exp ”then” comm1 ”else” comm2 ] ;
Listagem 5.29: Exemplo do Uso de Decora¸c˜ao na Defini¸c˜ao de Gram´atica Concreta
1 module Main
2
3 // Lexis
4 token fun = [fgh][0−9]∗ ;
5 token var = [xyz][0−9]∗ ;
6 token num = [0−9]+ is asInteger ;
7
8 // Syntax
9 syntax exp
10
11 exp ::= fun ”(” exp+−”,” ”)” : fun exp+
12 | var : var
13 | num : num ;
14
15 // Semantics
16 ...
Listagem 5.30: Exemplo de Linguagem de Fun¸c˜oes com M´ultiplos Argumentos
trecho de c´odigo da Listagem 5.29. Neste exemplo, a vari´avel comm aparece duas vezes
no lado direito da regra que define o comando if-then-else, e portanto cada ocorrˆencia
´e diferenciada por meio de uma decora¸c˜ao num´erica.
Outro exemplo de gera¸c˜ao de gram´atica abstrata ´e dado no trecho de c´odigo da Lista-
gem 5.30, que define uma linguagem de fun¸c˜oes com m´ultiplos argumentos.
Neste exemplo, a sintaxe abstrata ´e definida pela gram´atica G
A
MF
= (V, T, R, Exp), onde:
• V = {Exp, Fun};
• T = {fun, var, num};
5.3. DEFINIC¸
˜
AO SINT
´
ATICA 111
• R : Exp → Fun Exp+
| var
| num
Fun → fun
5.3.4.4 Defini¸c˜ao de Dom´ınios Sint´aticos
Cada regra de produ¸c˜ao definida na gram´atica abstrata estende o dom´ınio de sua vari´avel
do lado esquerdo por meio da inclus˜ao de sua defini¸c˜ao como uma nova parcela derivada
do lado direito da regra.
Sejam G = (V, T, R, S) a gram´atica abstrata de uma linguagem e uma regra de produ¸c˜ao
d → α pertencente a R, onde d ´e um nome de dom´ınio sint´atico pertencente a V , α =
a
1
a
2
· · · a
n
e cada a
i
´e um constituinte de gram´atica abstrata (ver Se¸c˜ao 5.3.4.3), ent˜ao a
nova parcela no dom´ınio ´e definida dada por δ(α), onde a fun¸c˜ao δ ´e definida em casos da
seguinte maneira:
• δ(α) = {α }, se α for um n˜ao-terminal que n˜ao possui defini¸c˜ao de dom´ınio;
• δ(α) = d
, se α for um n˜ao-terminal cujo dom´ınio ´e d
;
• δ(α) = d
, se α for um terminal cujo dom´ınio ´e d
;
• δ(α*) = δ(α)
∗
;
• δ(α+) = δ(α)
∗
;
10
• δ(a
1
a
2
· · · a
n
) = δ(a
1
) × δ(a
2
· · · a
n
);
Com isso, o dom´ınio sint´atico d pode ser definido como:
d =
d→α∈R
δ(α)
10
N˜ao h´a representa¸c˜ao especial para o dom´ınio de listas n˜ao-vazias; por isso, os dom´ınios correspon-
dentes `as opera¸c˜oes de fecho de Kleene e fecho de Kleene positivo s˜ao iguais.
112 CAP
´
ITULO 5. AMBIENTE PARA SEM
ˆ
ANTICA INCREMENTAL
Por exemplo, na gram´atica G
A
Exp
da Se¸c˜ao 5.3.4.3 (p´agina 109), o dom´ınio Exp ´e definido
por:
Exp = Id + Num
+ ({“add”} × Exp × Exp)
+ ({“sub”} × Exp × Exp)
+ ({“mul”} × Exp × Exp)
+ ({“div”} × Exp × Exp)
Considere ainda o m´odulo da Listagem 5.30 e sua gram´atica abstrata, G
A
MF
, definida na
p´agina 110. Os dom´ınios sint´aticos desta especifica¸c˜ao s˜ao definidos a partir da gram´atica
abstrata, de modo que:
• Exp = Num + Var + (Fun × Exp
∗
);
• Num = {asInteger u | u ∈ L ([0-9]+)};
• Var = {(λs.s) u | u ∈ L ([xyz][0-9]*)};
• Fun = {(λs.s) u | u ∈ L ([fgh][0-9]*)}.
5.3.4.5 Extens˜ao de Gram´atica
Para possibilitar a defini¸c˜ao separada, Notus permite adicionar `a gram´atica novas regras de
produ¸c˜ao tendo como lados esquerdos n˜ao-terminais que j´a tenham sido definidos. O ob-
jetivo ´e permitir organizar gram´aticas longas em m´odulos e definir extens˜oes da linguagem
sem a necessidade de alterar m´odulos existentes.
Extens˜oes da gram´atica s˜ao definidas por meio da cl´ausula de extens˜ao de vari´aveis, que
possui a forma:
extend id with grammar-constituent-list ;
Por exemplo, o trecho de c´odigo da Listagem 5.31 define separadamente regras para ex-
press˜oes aritm´eticas. N˜ao h´a distin¸c˜ao entre regras definidas diretamente na de clara¸c˜ao de
uma vari´avel e regras definidas em cl´ausulas de extens˜ao. Portanto, nenhuma modifica¸c˜ao
´e necess´aria na defini¸c˜ao de gram´aticas abstratas e dom´ınios sint´aticos.
5.4. DEFINIC¸
˜
AO SEM
ˆ
ANTICA 113
1 public exp ::= term ;
2 public term : Exp ::= primary ;
3 public primary : Exp ;
4 ...
5 extend exp with exp ”+” term | exp ”−” term ;
6 extend term with term ”∗” primary | term ”/” primary ;
7 extend term with ”(” exp ”)” | num | id ;
Listagem 5.31: Exemplo de Extens˜ao de Gram´atica
1 public function denexp : Exp −> Value
Listagem 5.32: Exemplo de Declara¸c˜ao de Fun¸c˜ao
5.4 Defini¸c˜ao Semˆantica
5.4.1 Fun¸c˜oes Semˆanticas
Para definir uma fun¸c˜ao semˆantica em Notus, ´e necess´ario e m primeiro lugar definir a sua
assinatura por meio de uma declara¸c˜ao de fun¸c˜ao, e ent˜ao definir seu corpo, possivelmente
em casos, por meio de pelo menos uma defini¸c˜ao de fun¸c˜ao. Defini¸c˜oes de fun¸c˜ao podem
aparecer em qualquer ordem e em m´odulos distintos e definir o resultado de aplica¸c˜oes de
fun¸c˜ao para padr˜oes distintos.
5.4.1.1 Declara¸c˜ao de Fun¸c˜ao
Uma declara¸c˜ao de fun¸c˜ao define a assinatura de uma fun¸c˜ao e possui a forma:
visibility function function-name : domain-expression;
A Listagem 5.32 cont´em um exemplo de defini¸c˜ao de fun¸c˜ao denexp cuja assinatura ´e
denexp : Exp → Value.
5.4.1.2 Defini¸c˜ao de Fun¸c˜ao
Fun¸c˜oes podem ser definidas por casos, baseados em casamento de padr˜oes, sendo cada
caso uma defini¸c˜ao de fun¸c˜ao da forma:
function-name parameter-patterns = expression;
114 CAP
´
ITULO 5. AMBIENTE PARA SEM
ˆ
ANTICA INCREMENTAL
1 public function fact : Int −> Int;
2 fact 0 = 1;
3 fact n = n ∗ fact (n − 1);
4
5 public function pow : Int −> Int −> Int;
6 pow a 0 = 1;
7 pow a n = a ∗ pow a (n − 1);
Listagem 5.33: Exemplos de Defini¸c˜ao de Fun¸c˜ao
Parˆametros de fun¸c˜ao s˜ao padr˜oes (ver Se¸c˜ao 5.4.2, p´agina 120) que devem ser casados
com os argumentos em aplica¸c˜oes de fun¸c˜ao (ver Se¸c˜ao 5.4.3.6, p´agina 132).
Por exemplo, considere as fun¸c˜oes fact e pow definidas na Listagem 5.33. A defini¸c˜ao da
fun¸c˜ao fact utiliza padr˜oes 0 e n. Com isso, o resultado da aplica¸c˜ao da fun¸c˜ao fact ao valor
0 ´e 1; caso contr´ario, o valor do argumento ´e associado ao identificador n e o resultado
´e o valor da express˜ao correspondente ao seu corpo neste novo ambiente. Identificadores
utilizados nos padr˜oes de uma defini¸c˜ao de fun¸c˜ao devem ser distintos.
5.4.1.3 Fun¸c˜oes Pr´e-Definidas
A Tabela 5.4 apresenta as fun¸c˜oes pr´e-definidas de Notus. Nesta tabela, a primeira coluna
cont´em os nomes das fun¸c˜oes, a segunda coluna, seus dom´ınios, e a terceira coluna, as
descri¸c˜oes.
5.4.1.4 Fun¸c˜oes de Pr´e-Processamento de Arquivo Fonte
Fun¸c˜oes de pr´e-processamento de arquivo fonte pe rtencem ao dom´ınio String → String e
s˜ao utilizadas para produzir uma vers˜ao pr´e-processada do arquivo fonte para o analisador
l´exico.
Considere, por exemplo, uma linguagem L composta por vari´aveis, express˜oes aritm´eticas,
fun¸c˜oes, comandos para entrada e sa´ıda e atribui¸c˜oes. Cada linha representa uma atribui¸c˜ao
e h´a um ponto e v´ırgula opcional no fim de cada linha, indicando que o valor atribu´ıdo
deve ser impresso na sa´ıda padr˜ao. Al´em disso, linhas com muitos caracteres podem ser
quebradas e ambiguidades s˜ao resolvidas por indenta¸c˜ao. A Listagem 5.34 mostra um
exemplo de programa que lˆe trˆes n´umeros, a, b e c, e computa os valores de d, e e f. As
5.4. DEFINIC¸
˜
AO SEM
ˆ
ANTICA 115
Name Domains Description
acos Real → Real inverse cosine of a number in [−1, 1]
asin Real → Real inverse sine of a number in [−1, 1]
atan Real → Real inverse tangent of a number
ceil Real → Real round toward infinity
cos Real → Real cosine of an angle in radians
cosh Real → Real hyperbolic cosine of a number
empty a∗ → Bool checks if a list is empty
exp Real → Real exponential of a number
fix (a → a) → a least fix point of a function
floor Real → Real round toward minus infinity
hd a∗ → a first element of a non-empty list
log Real → Real natural logarithm of a positive number
max Real∗ → Real the largest element of a non-empty list
Int∗ → Int
min Real∗ → Real the smallest element of a non-empty list
Int∗ → Int
pow Real × Real → Real power function
round Real → Real round to the nearest integer
sqr Real → Real square power of a number
sqrt Real → Real square root of a number
sin Real → Real sine of an angle in radians
sinh Real → Real hyperbolic sine of a number
tan Real → Real tangent of an angle in radians
tanh Real → Real hyperbolic tangent of a number
tl a∗ → a∗ tail of a non-empty list
trunc Real → Real round toward zero
Tabela 5.4: Fun¸c˜oes Pr´e-Definidas em Notus
116 CAP
´
ITULO 5. AMBIENTE PARA SEM
ˆ
ANTICA INCREMENTAL
1 a = read
2 b = read
3 c = read;
4 d = a + b + c
5 e = pow a b ∗ pow c d / sin c ∗ cos b +
6 pow a c
7 f = pow a b ∗ pow b d + sin c ∗ cos b + pow a
8 c;
Listagem 5.34: Exemplo de Programa na Linguagem L
linhas 5 e 6 representam um ´unico comando; o mesmo ocorre com as linhas 7 e 8. Al´em
disso, os valores de c e f ser˜ao impressos na tela, uma vez que os comandos das linhas
correspondentes terminam com um ponto e v´ırgula.
Considere que a Listagem 5.35 contenha o m´odulo principal da especifica¸c˜ao inicial de L,
que define a fun¸c˜ao de pr´e-processamento como preprocessing do m´odulo Preprocessing,
definida na Listagem 5.36. A fun¸c˜ao recebe como argumento uma cadeia de caracteres
representando o c´odigo fonte e produz uma nova cadeia representando o c´odigo fonte a ser
lido pelo analisador l´exico. Esta fun¸c˜ao conta o n´umero de espa¸cos em branco antes do
primeiro caractere n˜ao vazio em uma linha para decidir se um novo comando foi iniciado ou
se a linha ´e uma continua¸c˜ao da anterior. Al´em disso, para simplificar o analisador sint´atico,
toda vez que o fim de um comando for encontrado, um ponto-e-v´ırgula ´e adicionado como
delimitador do comando. Se um ponto-e-v´ırgula for encontrado pelo pr´e-processador no
fim de uma linha, ent˜ao adiciona-se `a entrada o texto "print x;", onde x ´e o identificador
do lado esquerdo da ´ultima atribui¸c˜ao.
Portanto, a especifica¸c˜ao correspondente a ser lida pelo analisador l´exico quando a en-
trada for o programa da Listagem 5.34 ´e semˆanticamente equivalente ao programa da
Listagem 5.37.
5.4.1.5 Fun¸c˜ao Semˆantica da Especifica¸c˜ao
A denota¸c˜ao de um programa ´e a aplica¸c˜ao da fun¸c˜ao semˆantica da especifica¸c˜ao `a ´arvore
de sintaxe abstrata do programa f onte gerado pelo analisador sint´atico. A fun¸c˜ao semˆantica
da linguagem deve ser definida no m´odulo principal da e specifica¸c˜ao inicial da linguagem
5.4. DEFINIC¸
˜
AO SEM
ˆ
ANTICA 117
1 module Main
2
3 preproc Preprocessing.preprocessing
4
5 // lexis
6 token id = [a−z]+
7 token num = [0−9]+ is asInteger
8 ignore [ \n\r\t]
9
10 // syntax
11 syntax program
12
13 program ::= command+
14 command ::= assignment | printing
15 assigment : Command ::= id ”=” expression ”;”
16 printing : Command ::= ”print” id ”;”
17 ...
18
19 ... // semantics
Listagem 5.35: Exemplo de Fun¸c˜ao de Pr´e-Proce ssamento
118 CAP
´
ITULO 5. AMBIENTE PARA SEM
ˆ
ANTICA INCREMENTAL
1 module Preprocessing
2 public function preprocessing: String −> String
3 preprocessing s = lhs s 0 ””
4
5 function lhs: String −> Int −> String −> String
6 lhs () = ()
7 lhs ’\n’:s1 s2 = ’\n’ : lhs s1 0 s2
8 lhs ’=’:s1 i s2 = ’=’ : rhs s1 (i + 1) (i + 1) s2
9 lhs c:s1 i s2 = c : lhs s1 (i + 1) (s2 ++ c)
10
11 function rhs: String −> Int −> Int −> String −> String
12 rhs () = ()
13 rhs ’ ’ :s1 i1 i2 s2 = ’ ’ : rhs s1 i1 (i2 + 1) s2
14 rhs ’\n’:s1 i1 i2 s2 = ’\n’ : rhs s1 i1 0 s2
15 rhs c:s1 i1 i2 s2 =
16 if ge i1 i2 then c : rsh f s i1 i2 s2 else ”?”
17
18 function rsh f: String −> Int −> Int −> String −> String
19 rsh f () = ”;”
20 rsh f ’ ’ :s1 i1 i2 s2 = ’ ’ : rsh f s1 i1 (i2 + 1) s2
21 rsh f ’\n’:s1 i1 i2 s2 = ’\n’ : rsh f s1 i1 (i2 + 1) s2
22 rsh f c:s1 i1 i2 s2 =
23 if ge i1 i2 then
24 if eq c ’ ; ’ then
25 c : ” print” ++ s2 ++ ”;” ++ rsh f s1 i1 (i2 + 1)
26 else
27 c : rsh f s ind st (i2 + 1)
28 else ’ ; ’ : c : lhs s indent
Listagem 5.36: Defini¸c˜ao da Fun¸c˜ao de Pr´e-P rocessamento
5.4. DEFINIC¸
˜
AO SEM
ˆ
ANTICA 119
1 a = read
2 ;b = read
3 ;c = read; print c ;
4 d = a + b + c
5 ;e = pow a b ∗ pow c d / sin c ∗ cos b +
6 pow a c
7 ; f = pow a b ∗ pow b d + sin c ∗ cos b + pow a
8 c; print f ;
Listagem 5.37: Programa correspondente ao programa da Listagem 5.34 (p´agina 116) a
ser lido pelo analisador l´exico
e possui a forma:
semantics semantic-function
onde semantic-function ´e uma fun¸c˜ao cujo primeiro argumento pertence ao dom´ınio sin-
t´atico do s´ımbolo de partida da gram´atica da linguagem. Entradas do interpretador para
a linguagem s˜ao argumentos da fun¸c˜ao semˆantica da especifica¸c˜ao; h´a duas possibilidades
de defini¸c˜ao:
• se o segundo argumento for uma cadeia de caracteres, ent˜ao o interpretador possui
uma ´unica entrada, que ´e lida da entrada padr˜ao;
• se o segundo argumento f or uma lista de cadeias de caracteres, ent˜ao o interpretador
possui mais de uma entrada, definidas conforme regras da Se¸c˜ao 5.1.5.
O resultado da fun¸c˜ao semˆantica corresponde `a sa´ıda do interpretador. Tamb´em h´a duas
possibilidades de defini¸c˜ao:
• se o tipo de retorno for uma cadeia de caracteres, ent˜ao o interpretador possui uma
´unica sa´ıda, que ´e escrita na sa´ıda padr˜ao;
• se o tipo de retorno for uma lista de cadeias de caracteres, ent˜ao o interpretador
possui mais de uma sa´ıda, definidas conforme regras da Se¸c˜ao 5.1.5.
Os tamanhos das lis tas devem estar de acordo com o n´umero de fluxos de entradas e sa´ıdas
especificados. Caso contr´ario, uma mensagem de erro ´e gerada durante a execu¸c˜ao.
Por exemplo, na Listagem 5.38, o s´ımbolo de partida da gram´atica ´e prog, que possui
dom´ınio sint´atico Prog (ver linhas 2 e 8). A fun¸c˜ao semˆantica ´e p (ver linhas 3, 11 e 12),
120 CAP
´
ITULO 5. AMBIENTE PARA SEM
ˆ
ANTICA INCREMENTAL
1 module Main
2 syntax prog
3 semantics p
4 input stdin, infile
5 output stdout, outfile
6
7 // grammar
8 prog ::= ...
9
10 // semantics
11 function p : Prog −> String∗ −> String∗
12 p prog (i1 , i2) = (o1,o2) where o1 = ...; o2 = ...
Listagem 5.38: Exemplo de Fun¸c˜ao Semˆantica
cujo primeiro argumento pertence ao dom´ınio Prog. O segundo argumento ´e uma lista de
cadeias de caracteres, que corresponde `as entradas do interpretador, definidas na linha 4;
o primeiro elemento ´e lido da entrada padr˜ao, e o segundo, de um arquivo a ser definido
na linha de comando de execu¸c˜ao do interpretador, conforme regras da Se¸c˜ao 5.1.5. O
resultado da fun¸c˜ao ´e uma lista de cadeias de caracteres, que corresponde `as sa´ıdas do
interpretador, definidas na linha 5; o primeiro elemento ´e escrito na sa´ıda padr˜ao, e o
segundo, em um arquivo a ser definido na linha de comando de execu¸c˜ao do interpretador,
conforme regras da Se¸c˜ao 5.1.5.
5.4.2 Padr˜oes
A linguagem Notus possui os seguintes padr˜oes: valores literais; idenficadores; padr˜ao
anˆonimo; agregados para tuplas; listas; n´os de ´arvore de sintaxe abstrata.
5.4.2.1 Valores Literais
Um padr˜ao pode ser um valor literal (ver Se¸c˜ao 5.4.3.1), conforme mostrado na defini¸c˜ao
da fun¸c˜ao fact na Listagem 5.33, linha 2, da Se¸c˜ao 5.4.1.2. Este padr˜ao casa apenas com
o valor correspondente.
5.4. DEFINIC¸
˜
AO SEM
ˆ
ANTICA 121
1 Value = Int | Bool | {error};
2
3 function sum : Value −> Value −> Value;
4 sum int1 int2 = add int1 int2;
5 sum = error;
Listagem 5.39: Exemplo de Padr˜oes Identificadores
5.4.2.2 Identificadores e Padr˜oes Anˆonimos
Um padr˜ao pode ser designado por um identificador, que casa com qualquer valor. Os
casos especiais de padr˜ao identificador s˜ao:
• elementos de enumera¸c˜ao, que, assim como valores literais, casam apenas com o
pr´oprio elemento;
• identificadores decorados de nomes de dom´ınio, que casam apenas com valores do
dom´ınio dado; o dom´ınio correspondente ´e obtido ignorando-se a decora¸c˜ao do iden-
tificador e transformando a primeira letra em mai´uscula.
O padr˜ao anˆonimo ´e representado pelo caractere e casa com qualquer valor; o valor
associado n˜ao ´e amarrado a identificador algum. Em geral, seu uso ´e feito em casos default
em defini¸c˜oes de fun¸c˜ao.
Por exemplo, considere a fun¸c˜ao sum da Listagem 5.39. Quando a fun¸c˜ao sum ´e aplicada
a dois n´umeros inteiros, ent˜ao o resultado ´e a soma destes valores; caso contr´ario, a soma
´e igual a error.
5.4.2.3 Tuplas
Um padr˜ao de tupla casa com valores em um dom´ınio de tupla e s˜ao representados pelo
nome de construtor e uma sequˆencia de padr˜oes separados por v´ırgulas e delimitados por
parˆenteses. Por exemplo, considere o trecho de c´odigo da Listagem 5.40
11
. A fun¸c˜ao m
calcula o m´odulo de um n´umero complexo. A fun¸c˜ao t calcula o argumento de um n´umero
complexo e ´e definido por casos: o primeiro casa apenas com a tupla C(0,0); o segundo casa
com qualquer n´umero complexo cujo primeiro elemento seja igual a 0; a terceira cl´ausula
define o comportamento geral da fun¸c˜ao.
11
Nesta defini¸c˜ao, se c = ae
iθ
ent˜ao m c = a e t c = θ.
122 CAP
´
ITULO 5. AMBIENTE PARA SEM
ˆ
ANTICA INCREMENTAL
1 C = (Double,Double); // complex numbers
2
3 function m : C −> Double;
4 m C(r1,r2) = sqrt ((sqr r1) + (s qr r2 ));
5
6 function t : C −> Double;
7 t C(0,0) = 0;
8 t C(0,r) = if r > 0 then pi / 2 else −pi / 2;
9 t C(r1,r2) = atan (r2 / r1)
Listagem 5.40: Exemplos de Padr˜ao Tupla em Defini¸c˜oes de Fun¸c˜ao
5.4.2.4 Listas
Padr˜oes de lista casam com listas de elementos e podem ser especificados por meio de
padr˜oes de agregados para listas, padr˜oes de identificadores decorados para listas, ou pares
cabe¸ca e cauda.
Em um padr˜ao agregado para lista, padr˜oes s˜ao listados entre parˆenteses e separados por
v´ırgula. Tais padr˜oes podem ser quaisquer padr˜oes definidos nesta se¸c˜ao. Por exemplo,
considere o trecho de c´odigo da Listagem 5.41. A fun¸c˜ao f mapeia listas de inteiros em
listas de inteiros; se o argumento recebido for uma lista vazia, ent˜ao o resultado ´e a lista
vazia; caso contr´ario, se o argumento recebido for a lista (1, 2, 3), ent˜ao o resultado ´e a lista
(1, 2, 5); por outro lado, se a lista contiver trˆes elementos, onde o primeiro ´e igual a 1, e
o ´ultimo, a 3, ent˜ao o resultado ´e (1, x, 4), onde x ´e o segundo elemento da lista recebida;
finalmente, se o argumento for uma lista com quatro elementos, ent˜ao o resultado ´e a lista
formada pela remo¸c˜ao do terceiro elemento. Do mesmo modo, a fun¸c˜ao g mapeia listas de
listas de inteiros da forma ((1), (), (x, y)) na lista (1, x + y).
Listas podem tamb´em ser definidas por pares cabe¸ca e cauda; a cabe¸ca e a cauda da lista
s˜ao separadas por um s´ımbolo de dois pontos, que ´e associativo `a direita. A Listagem 5.42
apresenta exemplos de uso deste padr˜ao.
Identificadores decorados como listas servem para associar listas cujos elementos s˜ao de
um dom´ınio espec´ıfico. Por exemplo, considere o trecho de c´odigo da Listagem 5.43. A
fun¸c˜ao f map eia lis tas de elementos do dom´ınio V em listas de valores l´ogicos, tal que:
quando aplicada a listas cujo primeiro elemento ´e um n´umero inteiro, o resultado ´e a
lista (true, true); quando aplicada a uma lista contendo pelo menos dois valores em que o
5.4. DEFINIC¸
˜
AO SEM
ˆ
ANTICA 123
1 function f : Int∗ −> Int∗
2 f () = ()
3 f (1,2,3) = (1,2,5)
4 f (1,x,3) = (1,x,4)
5 f (a,b, ,c) = (a,b,c)
6
7 function g : Int∗∗ −> Int∗
8 g ((1), (), (x,y)) = (1,x+y)
Listagem 5.41: Exemplos de Padr˜oes de Listas
1 function f : Int∗ −> Int∗
2 f () = ()
3 f 3:s = 4 : f s
4 f 1:2: s = 1 : 2 : f s
5 f int :s = int ∗ int : f s
Listagem 5.42: Exemplos de Uso de Pares Cabe¸ca e Cauda
primeiro ´e um valor l´ogico, ent˜ao o resultado ´e a aplica¸c˜ao da fun¸c˜ao `a cauda da lista; caso
contr´ario, o res ultado ´e a lista (false).
O padr˜ao (p
1
, p
2
, · · · , p
n
) ´e equivalente a p
1
: p
2
: · · · : p
n
: (), e esta nota¸c˜ao ser´a utilizada
preferencialmente ao longo deste texto.
5.4.2.5 N´os de
´
Arvores de Sintaxe Abstrata
Padr˜oes para n´os de ´arvore de sintaxe abstrata correspondem ao lado direito de regras
de produ¸c˜ao da gram´atica abstrata. Por exemplo, considere o trecho de c´odigo da Lista-
1 V = Bool | Int | {nothing}
2
3 function f : V∗ −> Bool∗
4 f int :v∗ = (true,true)
5 f bool:v+ = f v+
6 f v∗ = (false)
Listagem 5.43: Exemplos de Padr˜oes de Listas
124 CAP
´
ITULO 5. AMBIENTE PARA SEM
ˆ
ANTICA INCREMENTAL
1 syntax Exp;
2 semantics e;
3
4 token num : Exp = [0−9]+ is asInteger;
5
6 exp ::= exp ”+” term | term : term;
7 term : Exp ::= term ”∗” factor | factor : factor ;
8 factor : Exp ::= num | ”(” exp ”)” : e xp;
9
10 function e : Exp −> Int;
11 e int = int;
12 e [exp1 ”+” exp2] = (e exp1) + (e exp2);
13 e [exp1 ”∗” exp2] = (e exp1) ∗ (e exp2);
Listagem 5.44: Exemplo de Padr˜ao Para N´o de
´
Arvore de Sintaxe Abstrata
gem 5.44, cujas regras da gram´atica abstrata s˜ao:
Exp → Exp ”+”Exp
| Exp ”*”Exp
| Int
A primeira cl´ausula define o resultado da fun¸c˜ao e aplicada a um valor inteiro; a segunda
cl´ausula define o resultado da fun¸c˜ao aplicada a uma express˜ao de soma; a terceira cl´ausula
define o resultado da fun¸c˜ao aplicada a uma express˜ao de multiplica¸c˜ao.
Os elementos de um padr˜ao para n´o de ´arvore de sintaxe abstrata deve concordar com o
dom´ınio sint´atico correspondente, e nenhuma convers˜ao autom´atica ´e realizada.
5.4.2.6 Dominˆancia de Padr˜oes
Os conceitos de dominˆancia de padr˜oes e de padr˜oes mais restritos para um valor, de-
finidos nesta se¸c˜ao, s˜ao necess´arios `a defini¸c˜ao das regras de aplica¸c˜ao de fun¸c˜oes (ver
Se¸c˜ao 5.4.3.6).
Seja P o conjunto de todos os padr˜oes e m uma especifica¸c˜ao em Notus. P ´e um conjunto
parcialmente ordenado com rela¸c˜ao , tal que para padr˜oes p
1
, p
2
∈ P, p
1
p
2
se pelo
menos uma das condi¸c˜oes a seguir for verdadeira:
5.4. DEFINIC¸
˜
AO SEM
ˆ
ANTICA 125
1. (fecho reflexivo) p
1
= p
2
;
2. (fecho transitivo) existe um padr˜ao p
3
, tal que p
1
p
3
e p
3
p
2
; por exemplo, pelas
condi¸c˜oes 5 e 4, 2 int e int x, caso n˜ao exista dom´ınio X na especifica¸c˜ao, logo
2 x;
3. p
2
´e o padr˜ao anˆonimo;
4. p
2
´e um identificador que n˜ao est´a associado a qualquer dom´ınio;
5. p
1
´e um valor literal, e p
2
´e um identificador decorado do dom´ınio correspondente a
p
1
; por exemplo, 21 int1;
6. p
1
´e um elemento de enumera¸c˜ao, e p
2
´e um identificador decorado do dom´ınio de p
1
;
por exemplo, se a enumera¸c˜ao E for definida como E = {a, b, c}, e nt˜ao a e;
7. p
1
´e um padr˜ao tupla, e p
2
´e um identificador decorado do nome do dom´ınio de p
1
; por
exemplo, se o dom´ınio T for definido como T = Ta(Int, String), ent˜ao Ta(1, ”abc”)
t;
8. p
1
´e um padr˜ao de lista, e p
2
´e um identificador decorado como lista de eleme ntos do
dom´ınio dos elementos de p
1
; por exemplo, (5, 6, 4) int*;
9. existe um padr˜ao p, tal que p
1
= p+ e p
2
= p∗;
10. p
1
´e um padr˜ao de n´o de ´arvore de sintaxe abstrata, e p
2
´e um identificador de-
corado do dom´ınio sint´atico correspondente a p
1
; por exemplo, se a especifica¸c˜ao
definir a regra sint´atica exp → exp “+” exp, e exp denotar o dom´ınio Exp, ent˜ao
[exp1 “+” exp2] exp;
11. p
1
´e um identificador decorado para o dom´ınio d
1
, p
2
´e um identificador decorado
para o dom´ınio d
2
, e d
1
´e um subdom´ınio de d
2
; por exemplo, se o dom´ınio V for
definido como V = Int | Bool, ent˜ao int v;
12. p
1
´e o padr˜ao tupla T (p
11
, p
12
, · · · , p
1k
), p
2
´e o padr˜ao tupla T (p
21
, p
22
, · · · , p
2k
), para
algum k e algum construtor de tupla T, e p
1i
p
2i
, para 1 ≤ i ≤ k; por exemplo, se o
dom´ınio T for definido por T = Ta(Int , String), ent˜ao Ta(5, ”abc” ) Ta(5, string);
13. p
1
´e um par cabe¸ca e cauda p
11
: p
12
, p
2
´e um par cabe¸ca e cauda p
21
: p
22
, p
11
p
21
,
e p
12
p
22
; por exemplo, 5 : int* : x.
126 CAP
´
ITULO 5. AMBIENTE PARA SEM
ˆ
ANTICA INCREMENTAL
Uma sequˆencia de valores V = v
1
, v
2
, · · · , v
n
casa com um sequˆencia de padr˜oes P =
p
1
, p
2
, · · · , p
n
se p
i
casar com o valor v
i
, para cada i. A rela¸c˜ao de ordem parcial
´e definida para sequˆencias de padr˜oes P
1
= p
11
, p
12
, · · · , p
1k
e P
2
= p
21
, p
22
, · · · , p
2k
,
ambas do mesmo tamanho, tal que p
1i
p
2i
para cada i.
Dado um conjunto de padr˜oes S = {p
1
, p
2
, · · · , p
m
} e um valor v, o padr˜ao mais restrito
de v em S ´e o padr˜ao p
i
∈ S tal que:
• p
i
casa com v;
• p
i
p
j
, para todo p
j
∈ S que case com v.
Se o padr˜ao mais restrito de v em S n˜ao puder ser determinado, ent˜ao S ´e n˜ao-aplic´avel a
v.
Seja V = v
1
, v
2
, · · · , v
k
uma sequˆencia de valores, e S = {P
1
, P
2
, · · · , P
n
}, um conjunto
de sequˆencias de padr˜oes, onde cada P
i
= p
i1
, p
i2
, · · · , p
ik
´e uma sequˆencia contendo k
padr˜oes. O padr˜ao mais restrito de V em S ´e a sequˆencia P
i
∈ S tal que:
• P
i
casa com V ;
• P
i
P
j
, para todo P
j
∈ S que case com V .
Se o padr˜ao mais restrito de V em S n˜ao puder ser determinado, ent˜ao S ´e n˜ao-aplic´avel
a V .
5.4.3 Express˜oes
As express˜oes de Notus s˜ao:
1. valores literais (Se¸c˜ao 5.4.3.1, p´agina 127);
2. agregados (Se¸c˜ao 5.4.3.2, p´agina 127);
3. identificadores (Se¸c˜ao 5.4.3.3, p´agina 128);
4. opera¸c˜oes (Se¸c˜ao 5.4.3.4, p´agina 128);
5. n´os de ´arvore de sintaxe abstrata (Se¸c˜ao 5.4.3.5, p´agina 131);
6. aplica¸c˜oes de fun¸c˜ao (Se¸c˜ao 5.4.3.6, p´agina 132);
5.4. DEFINIC¸
˜
AO SEM
ˆ
ANTICA 127
7. padr˜oes (Se¸c˜ao 5.4.3.7, p´agina 133);
8. abstra¸c˜oes lambda (Se¸c˜ao 5.4.3.8, p´agina 134);
9. express˜oes let e where (Se¸c˜ao 5.4.3.9, p´agina 134);
10. atualiza¸c˜ao de fun¸c˜ao (Se¸c˜ao 5.4.3.10, p´agina 135);
11. condicionais (Se¸c˜ao 5.4.3.11, p´agina 135).
A sintaxe de express˜oes pode ser encontrada na Se¸c˜ao A.8.
5.4.3.1 Valores Literais
Valores literais em Notus s˜ao definidos para cada dom´ınio padr˜ao apresentado na Se¸c˜ao 5.2.3.2:
• valores booleanos s˜ao true e false;
• n´umeros inteiros podem ser escritos nas seguintes bases:
– decimal: o n´umero ´e uma sequˆencia de um ou mais d´ıgitos de 0 a 9;
– octal: o n´umero ´e uma sequˆencia de um ou mais d´ıgitos de 0 a 7, precedida pelo
d´ıgito 0;
– hexadecimal: o n´umero ´e uma sequˆencia de um ou mais d´ıgitos hexadecimais,
i.e. d´ıgitos de 0 a 9 e letras de a a f, precedida de 0x;
• n´umeros reais s˜ao n´umeros de ponto flutuante em 64-bits seguindo o padr˜ao IEEE
754;
• caracteres s˜ao delimitados por aspas simples, com as seguintes sequˆencias de escape:
\n, \r, \f, \t, \a, \b, \\, \’, and \”
• cadeias de caracteres s˜ao sequˆe ncias de caracteres delimitadas por aspas duplas, com
as mesmas sequˆencias de escapes utilizadas em caracteres.
5.4.3.2 Agregados
Em Notus, existem agregados para tuplas e listas.
128 CAP
´
ITULO 5. AMBIENTE PARA SEM
ˆ
ANTICA INCREMENTAL
Agregados Para Tuplas. Um agregado para tupla ´e composto por um nome de cons-
trutor e uma sequˆencia de express˜oes, separadas por v´ırgula e delimitada por parˆenteses.
Considerando A, B, C, D e E nomes de construtores, s˜ao exemplos de agregados para
tuplas:
12
A() B(true) C(1,true,3 + 7)
D(false,3.141592,E(a,if b then 10 else 9))
Uma express˜ao C(e
1
, e
2
, · · · , e
n
) pertence ao dom´ınio no qual o construtor C foi definido.
Agregados Para Listas. Um agregado para lista ´e uma sequˆencia de express˜oes sepa-
radas por v´ırgulas e delimitadas por parˆenteses. S˜ao exemplos de agregados para listas:
13
() (true) (1,4,3 + 7)
((4,3),(a,if b then 10 else 9))
Uma express˜ao (e
1
, e
2
, · · · , e
n
) pertence ao dom´ınio d
∗
, onde d ´e o dom´ınio de cada e
i
. A
express˜ao () pertence ao dom´ınio x
∗
, para algum dom´ınio x, que deve ser dedut´ıvel a partir
do contexto.
5.4.3.3 Identificadores
Identificadores em Notus s˜ao sequˆencias de letras, d´ıgitos e caracteres , que iniciam com
letra min´uscula. Um identificador pode ser qualificado com o nome do m´odulo onde foi
definido e decorado com n´umeros ou como uma lista. O dom´ınio de um identificador pode
ser automaticamente deduzido alterando sua primeira letra para mai´usculo e removendo
suas decora¸c˜oes; se o nome obtido for um identificador de dom´ınio v´alido, ent˜ao n˜ao ´e
necess´ario definir o tipo do identificador; caso contr´ario, o seu tipo deve ser deduzido pelo
contexto da express˜ao.
5.4.3.4 Opera¸c˜oes
Notus possui os operadores definidos nas Tabelas 5.5–5.11, que representam as opera¸c˜oes
aritm´eticas, bit-a-bit, relacionais, l´ogicas, de lista, composi¸c˜ao e casamento de padr˜oes. Em
12
A express˜ao condicional ´e definida na Se¸c˜ao 5.4.3.11.
13
A express˜ao condicional ´e definida na Se¸c˜ao 5.4.3.11.
5.4. DEFINIC¸
˜
AO SEM
ˆ
ANTICA 129
Operador Objetivo Preced. Assoc. Assinaturas
unary - arithmetic negation 2 – I → I
R → R
* multiplication 3 left I × I → I
R × R → R
/ division result 3 left I × I → I
R × R → R
mod division remainder 3 left I × I → I
+ addition 4 left I × I → I
R × R → R
- subtraction 4 left I × I → I
R × R → R
Tabela 5.5: Operadores Aritm´eticos de Notus
cada tabela, a primeira coluna lista os operadores, a segunda, seus obje tivos, a terceira,
suas ordens de precedˆencia, a quarta, suas associatividades, e a quinta, seus dom´ınios. A
precedˆencia m´axima ´e igual a 1 e ´e dada somente a express˜oes que n˜ao envolvam o uso de
operadores.
Tabela 5.5 lista os operadores aritm´eticos b´asicos para nega¸c˜ao, adi¸c˜ao, subtra¸c˜ao, multi-
plica¸c˜ao, divis˜ao real, quociente de divis˜ao inteira e resto de divis˜ao inteira. Todos os ope-
radores, com exce¸c˜ao do resto de divis˜ao inteira, s˜ao definidos para os dom´ınios de n´umeros
inteiros (Byte, Short, Int e Long), condensados na tabela por I, e para os dom´ınios de
n´umeros reais (Float e Double), condensados na tabela por R.
Tabela 5.6 lista os operadores que representam a manipula¸c˜ao de n´umeros em bin´ario:
nega¸c˜ao, deslocamentos, conjun¸c˜ao, disjun¸c˜ao e ou-exclusivo. Estes operadores podem ser
aplicados somente aos dom´ınios de n´umeros inteiros (Byte, Short , Int e Long), condensados
na tabela por I.
Tabela 5.7 lista os operadores relacionais que s˜ao definidos para os dom´ınios de n´umeros
inteiros (Byte, Short, Int e Long), condensados na tabela por I, e para os dom´ınios de
n´umeros reais (Float e Double), condensados na tabela por R.
Tabela 5.8 lista os operadores l´ogicos para nega¸c˜ao, conjun¸c˜ao e disjun¸c˜ao.
Tabela 5.9 lista os operadores para constru¸c˜ao e concatena¸c˜ao de listas. Estas opera¸c˜oes
s˜ao definidas para todos os dom´ınios, representados na tabela por a.
130 CAP
´
ITULO 5. AMBIENTE PARA SEM
ˆ
ANTICA INCREMENTAL
Operador Objetivo Preced. Assoc. Assinaturas
~ bitwise negation 2 – I → I
>> arithmetic shift right 3 left I × I → I
>>> logical shift right 3 left I × I → I
<< shift left 3 left I × I → I
& bitwise conjunction 3 left I × I → I
| bitwise disjunction 4 left I × I → I
^ bitwise exclusive-or 4 left I × I → I
Tabela 5.6: Operadores Bit-a-bit de Notus
Operador Objetivo Preced. Assoc. Assinatura
< less than 5 – R × R → Bool
I × I → Bool
> greater than 5 – R × R → Bool
I × I → Bool
<= less than or equal to 5 – R × R → Bool
I × I → Bool
>= greater than or equal to 5 – R × R → Bool
I × I → Bool
= equal to 5 – R × R → Bool
I × I → Bool
!= not equal to 5 – R × R → Bool
I × I → Bool
Tabela 5.7: Operadores Relacionais de Notus
Operador Objetivo Prec. Assoc. Assinaturas
not boolean negation 2 – Bool → Bool
and boolean conjunction 6 left Bool × Bool → Bool
or boolean disjunction 7 left Bool × Bool → Bool
Tabela 5.8: Operadores L´ogicos de Notus
5.4. DEFINIC¸
˜
AO SEM
ˆ
ANTICA 131
Operador Objetivo Preced. Assoc. Assinaturas
: list construction 8 right a × a∗ → a∗
++ list appending 9 left a∗ × a∗ → a∗
Tabela 5.9: Operadores de Lista de Notus
Operador Objetivo Preced. Assoc. Assinatura
. function composition 10 right (b → c) → (a → b) → (a → c)
Tabela 5.10: Operador de Composi¸c˜ao de Fun¸c˜oes de Notus
Tabela 5.10 define o operador de composi¸c˜ao de fun¸c˜ao.
Tabela 5.11 define o operador de casamento de padr˜oes.
5.4.3.5 N´os de
´
Arvore de Sintaxe Abstrata
Uma express˜ao para n´o de ´arvore de sintaxe abstrata corresponde ao lado direito de uma re-
gra de produ¸c˜ao da gram´atica abstrata e ´e utilizada para defini¸c˜ao das fun¸c˜oes semˆanticas.
A express˜ao ´e delimitada por colchetes e ´e formada por uma sequˆencia de identificadores,
cadeias de caracteres, identificadores de lista e outros n´os de ´arvore de sintaxe abstrata.
Por exemplo, considere o trecho de c´odigo na Listagem 5.45, que mostra como remover
a¸c´ucar sint´atico de uma gram´atica de comandos de repeti¸c˜ao while e do-while, definidos
como na linguagem C, o que possibilita que somente o comando while seja apresentado nas
equa¸c˜oes semˆanticas. A gram´atica original ´e:
Com → ”while” ”(” Exp ”)” Com
| ”do” Com ”while” ”(” Exp ”)”
| ”{” Com ”;” Com ”}”
A fun¸c˜ao desugar recebe como argumento um n´o que representa um comando e retorna uma
nova express˜ao correspondente sem o a¸c´ucar sint´atico. Os elementos de uma express˜ao de
Operador Objetivo Preced. Assoc. Assinatura
is pattern matching 11 – a → b → Bool
Tabela 5.11: Operador de Casamento de Padr˜oes de Notus
132 CAP
´
ITULO 5. AMBIENTE PARA SEM
ˆ
ANTICA INCREMENTAL
1 com ::= ”while” ”(” exp ”)” com
2 | ”do” com ”while” ”(” exp ”)”
3 | com ”;” com
4 | ... // other clauses
5
6 function desugar : Com −> Com;
7 desugar [ ”do” com ”while” ”(” exp ”)” ] =
8 let com1 = desugar com
9 in [ com1 ”;” [ ”while” ”(” exp ”)” com1 ] ]
10 ... // other clauses
Listagem 5.45: Exemplos de N´os de
´
Arvore de Sintaxe Abstrata
n´o deve concordar com os dom´ınios sint´aticos declarados, e nenhuma convers˜ao autom´atica
´e realizada.
5.4.3.6 Aplica¸c˜oes de Fun¸c˜ao
Aplica¸c˜oes de fun¸c˜ao possuem a forma
e
0
e
1
e
2
· · · e
n
onde cada e
i
´e uma express˜ao. Se para cada i ≥ 1, o valor de e
i
pertencer ao dom´ınio d
i
,
ent˜ao e
0
deve pertencer a algum dom´ınio d
1
→ d
2
→ · · · → d
n
→ d, tal que d
i
= d
i
ou d
i
´e subdom´ınio de d
i
; neste caso, a express˜ao e
0
e
1
e
2
· · · e
n
pertence ao dom´ınio d; caso
contr´ario, o c ompilador gera um erro.
Para uma fun¸c˜ao definida em casos, a defini¸c˜ao utilizada em uma aplica¸c˜ao depende dos
valores dos argumentos fornecidos. Sejam: f uma fun¸c˜ao no dom´ınio d
1
→ d
2
→ · · · →
d
n
→ d, definida por meio de m cl´ausulas, cada uma com sequˆencia de padr˜oes P
k
=
p
k1
, p
k2
, · · · , p
kn
, para 1 ≤ k ≤ m; e
1
, e
2
, · · · , e
n
express˜oes; f e
1
e
2
· · · e
n
uma aplica¸c˜ao
de fun¸c˜ao. Se o valor de avalia¸c˜ao de cada e
i
for v
i
, ent˜ao a aplica¸c˜ao de fun¸c˜ao ´e avaliada
com o corpo de fun¸c˜ao definido para o padr˜ao mais restrito (ver Se¸c˜ao 5.4.2.6) de V =
v
1
, v
2
, · · · , v
n
em S = {P
1
, P
2
, · · · , P
m
}. Se S n˜ao for aplic´avel a V , ent˜ao o compilador
deve gerar um erro para a aplica¸c˜ao de fun¸c˜ao.
Parˆenteses em aplica¸c˜oes de fun¸c˜ao, quando exigidos para o ´ultimo argumento da aplica¸c˜ao,
podem ser omitidos pelo uso de express˜oes de evaluate, que possuem a forma:
evaluate { function; arg
1
; arg
2
; · · · ; arg
n−1
; arg
n
}
5.4. DEFINIC¸
˜
AO SEM
ˆ
ANTICA 133
1 Value = Int | Bool | {error};
2
3 function f : Value −> Int
4 f value = if value is int then 1
5 else if value is bool then 2
6 else 3
Listagem 5.46: Exemplo de Express˜ao de Casamento de Padr˜ao
e ´e equivalente a: function ( arg
1
( arg
2
( · · · ( arg
n−1
( arg
n
) ) ) ) ). Por exemplo, a
express˜ao evaluate { fun a b; c d; e f } ´e equivalente a fun a b (c d (e f)).
Chaves e pontos-e-v´ırgulas em express˜oes evaluate podem ser omitidos por meio das regras
de leiaute definidas na Se¸c˜ao A.1. Por exemplo, pelo uso destas regras, a express˜ao anterior
pode ser escrita como evaluate fun a b; c d; e f .
Nota: A express˜ao evaluate ´e tamb´em equivalente a (function◦arg
1
◦arg
2
◦· · ·◦arg
n−1
) arg
n
,
e, desta forma, o exemplo pode ser ainda escrito como ((fun a b) ◦ (c d)) (e f).
5.4.3.7 Padr˜oes e Express˜oes de Casamento de Padr˜ao
Em Notus, as seguintes express˜oes podem ser compostas pelos padr˜oes da Se¸c˜ao 5.4.2:
express˜oes let e where; express˜ao case; express˜ao de casamento de padr˜oes. Uma express˜ao
de casamento de padr˜ao ´e utilizada para verificar se o valor de uma express˜ao casa com
um dado padr˜ao e possui a forma:
expression is pattern
Express˜oes de casamento de padr˜ao n˜ao definem amarra¸c˜oes de identificadores. Portanto,
os identificadores definidos em pattern n˜ao est˜ao dispon´ıveis fora da express˜ao de casamento
de padr˜ao. O operador is n˜ao ´e associativo e sua precedˆencia ´e definida de acordo com as
regras da Se¸c˜ao 5.4.3.4.
A fun¸c˜ao f definida na Listagem 5.46 utiliza uma express˜ao de casamento de padr˜ao para
verificar se um dado valor ´e inteiro, l´ogico ou se representa um erro.
134 CAP
´
ITULO 5. AMBIENTE PARA SEM
ˆ
ANTICA INCREMENTAL
5.4.3.8 Abstra¸c˜oes Lambda
Abstra¸c˜oes lambda em Notus possuem a forma \ p
1
p
2
· · · p
n
→ e, onde cada p
i
´e um
padr˜ao e e ´e uma express˜ao. O dom´ınio de uma abstra¸c˜ao ´e obtido a partir do contexto
no qual se encontra. Por exemplo a express˜ao
\int1 int2 -> (int1 + int2, int1 - int2, int1 mod int2)
pertence ao dom´ınio Int → Int → Int*.
5.4.3.9 Express˜oes Let e Where
Express˜oes let e where s˜ao utilizadas para definir sub-express˜oes auxiliares em express˜oes
mais complexas. Uma express˜ao let possui a forma:
let { p
1
= e
1
; p
2
= e
2
; ...; p
n
= e
n
} in e
onde cada p
i
´e um padr˜ao, e cada e
i
e e s˜ao express˜oes. O valor desta express˜ao ´e o valor de
e avaliado em um ambiente onde o valor de cada e
i
casa com p
i
. As sub-express˜oes podem
ser mutuamente recursivas e, por isso, cada e
i
pode utilizar identificadores definidos em
qualquer p
j
.
Chaves e pontos-e-v´ırgulas em express˜oes let podem ser omitidos por meio das regras de
leiaute definidas na Se¸c˜ao A.1.
O exemplo na Listagem 5.47 define fun¸c˜oes f e g por meio de express˜oes let. A fun¸c˜ao f
recebe como argumento um n´umero x e retorna o cosseno hiperb´olico de x; a express˜ao let
´e utilizada para simplificar a express˜ao, amarrando o valor de e
x
a e1 e o valor de e
−x
a
e2. A fun¸c˜ao g recebe como argumento dois n´umeros inteiros, a e b, e tem como resultado
uma lista infinita que intercala os valores recebidos na forma a, b, a, b, a, b, · · ·.
Uma express˜ao where da forma:
e where { p
1
= e
1
; p
2
= e
2
; ...; p
n
= e
n
}
´e equivalente `a seguinte express˜ao let:
let { p
1
= e
1
; p
2
= e
2
; ...; p
n
= e
n
} in e
O exemplo da Listagem 5.48 define as mesmas fun¸c˜oes da Listagem 5.47, utilizando ex-
press˜oes where em vez de express˜oes let.
5.4. DEFINIC¸
˜
AO SEM
ˆ
ANTICA 135
1 function f : Real −> Real
2 f x = let e1 = exp(x); e2 = 1.0 / e1 in (e1 + e2) / 2
3
4 function g : Int −> Int −> Int∗
5 g a b = let list1 = a: list2
6 list2 = b: list1
7 in list1
Listagem 5.47: Exemplos de Express˜oes Let
1 function f : Real −> Real
2 f x = (e1 + e2) / 2 where e1 = exp(x); e2 = exp(−x)
3
4 function g : Int −> Int −> Int∗
5 g a b = list1 where list1 = a:list2
6 list2 = b: list1
Listagem 5.48: Exemplos de Express˜oes Where
5.4.3.10 Atualiza¸c˜ao de Fun¸c˜oes
Express˜oes de atualiza¸c˜ao de fun¸c˜ao s˜ao utilizadas para alterar o valor de uma fun¸c˜ao em
pontos espec´ıficos e possuem a forma:
function[argument ← new-result]
O resultado desta express˜ao ´e uma nova fun¸c˜ao que, quando aplicada ao valor argument
produz como resultado o valor new-result, e, quando aplicada a qualquer outro valor produz
o mesmo valor que function.
Considere as fun¸c˜oes fac e g definida na Listagem 5.49; a fun¸c˜ao fac ´e a fun¸c˜ao fatorial, e
a fun¸c˜ao g ´e definida por:
g x =
5, if x = 1
fac x, otherwise
5.4.3.11 Express˜oes Condicionais
Express˜oes condicionais em Notus podem ser definidas na forma de express˜oes if e ex-
press˜oes case.
136 CAP
´
ITULO 5. AMBIENTE PARA SEM
ˆ
ANTICA INCREMENTAL
1 function fac : Int −> Int
2 fac 0 = 1
3 fac x = x ∗ fac(x − 1)
4
5 function g : Int −> Int
6 g = fac[1 <− 5]
Listagem 5.49: Exemplo de Atualiza¸c˜ao de Fun¸c˜ao
Express˜oes If. A express˜ao if possui a forma:
if e
1
then e
2
else e
3
onde e
1
´e uma express˜ao cujo valor pertence ao dom´ınio Bool, e e
2
e e
3
s˜ao express˜oes
pertencentes a um mesmo dom´ınio. O valor da express˜ao if ´e e
2
se e
1
avaliar em true, ou
e
3
, caso contr´ario.
Express˜ao Case. A express˜ao case possui a forma:
case e of {
p
1
⇒ e
1
;
p
2
⇒ e
2
;
.
.
.
p
n
⇒ e
n
}
onde e ´e uma express˜ao, cada p
i
´e um padr˜ao, e cada e
i
´e uma express˜ao. O valor desta
express˜ao case ´e e
i
se p
i
for o padr˜ao mais restrito do valor de e em S = {p
1
, p
2
, · · · , p
n
}
(ver Se¸c˜ao 5.4.2.6). Se S n˜ao for aplic´avel ao valor de e, ent˜ao o compilador lan¸ca um erro.
Casos default s˜ao obtidos por meio do padr˜ao anˆonimo. Chaves e pontos-e-v´ırgulas em
express˜oes case podem ser omitidos por meio das regras de leiaute definidas na Se¸c˜ao A.1.
A Listagem 5.50 define uma fun¸c˜ao f como o inverso multiplicativo de seu argumento, x, se
x = 0; se x = 0 ent˜ao f resulta em um erro. A fun¸c˜ao g ´e equivalente `a fun¸c ˜ao f utilizando
express˜ao case em vez de express˜ao if.
5.5. FUNC¸
˜
OES DE TRANSFORMAC¸
˜
AO 137
1 function f : Real −> ({error} | Real)
2 f x = if x = 0 then error else 1 / x
3
4 function g : Real −> ({error} | Real)
5 f x = case x of 0 => error
6 => 1 / x
Listagem 5.50: Exemplos de Express˜oes Condicionais
5.5 Fun¸c˜oes de Transforma¸c˜ao
Uma fun¸c˜ao de transforma¸c˜ao, ou simplesmente transformador, ´e definido em um m´odulo
de transforma¸c˜ao, que possui o formato a seguir:
transformation transform-name
import imported-modules
signature signature-clauses
default default-clauses
replace replace-clauses
redefine redefine-clauses
As cl´ausulas do m´odulo tem estrutura e funcionamento conforme especificado na Se¸c˜ao 4.3.
A sintaxe do m´odulo pode ser encontrada nas Se¸c˜oes A.2 e A.9. A importa¸c˜ao de m´odulos
deve ser utilizada para tornar vis´ıveis identificadores e dom´ınios envolvidos nas cl´ausulas de
transforma¸c˜ao e fun¸c˜oes auxiliares utilizadas nas express˜oes das cl´ausulas de transforma¸c˜ao.
Detalhes das fun¸c˜oes de transforma¸c˜ao foram apresentados na Se¸c˜ao 4.3.
5.6 Especifica¸c˜ao Baseada em Componentes
Notus permite, ainda, a especifica¸c˜ao de linguagens baseadas em componentes, conforme
proposto por Mosses (2005). Nesta proposta, define-se um n´ucleo de constru¸c˜oes b´asicas
abstratas de linguagens de programa¸c˜ao em geral, de modo que qualquer elemento lingu´ıs-
tico se torna uma combina¸c˜ao de elementos mais simples. A especifica¸c˜ao da semˆantica de
uma linguagem consiste, desta maneira, na tradu¸c˜ao de suas constru¸c˜oes nas constru¸c˜oes
138 CAP
´
ITULO 5. AMBIENTE PARA SEM
ˆ
ANTICA INCREMENTAL
da linguagem base, cuja semˆantica formal foi previamente definida. Por exemplo, os co-
mandos de repeti¸c˜ao while, do-while e for da linguagem C podem ser definidos por meio
da combina¸c˜ao de sequˆencias de comandos e de um comando de repeti¸c˜ao b´asico.
Em Notus, o processo para componentiza¸c˜ao consiste, inicialmente, na defini¸c˜ao de m´odulos
para as constru¸c˜oes da linguagem base, contendo a defini¸c˜ao de seus dom´ınios semˆanticos
e das equa¸c˜oes semˆanticas correspondentes. A defini¸c˜ao da nova linguagem ´e feita por
meio da especifica¸c˜ao de seus elementos l´exicos e sint´aticos, como qualquer outra defini¸c˜ao
em Notus. As equa¸c˜oes semˆanticas, no entanto, s˜ao fun¸c˜oes de tradu¸c˜ao dos elementos
no dom´ınio sint´atico da nova linguagem em n´os de ´arvore sint´atica da linguagem b´asica.
A fun¸c˜ao de interpreta¸c˜ao consiste, assim, na composi¸c˜ao da fun¸c˜ao de tradu¸c˜ao com a
fun¸c˜ao de interpreta¸c˜ao da linguagem base.
´
E importante notar que n˜ao ´e necess´ario definir
sintaxe concreta para a linguagem base.
5.7 Compilador de Notus
O compilador para a linguagem Notus foi concebido e projetado pelo autor e implementado
como dois trabalhos do Laborat´orio de Linguagens de Programa¸c˜ao do Departamento de
Ciˆencia da Computa¸c˜ao da Universidade Federal de Minas Gerais:
• Soares (2007) implementou a toda a estrutura geral do compilador, incluindo gera¸c˜ao
de analisador l´exico, gera¸c˜ao de analisador sint´atico, e gera¸c˜ao das rotinas semˆanticas;
• Loredo et al. (2008) estendeu o compilador, incluindo as fun¸c˜oes de transforma¸c˜ao e
a compila¸c˜ao de sequˆencias de transformadores.
Al´em disso, o autor contribuiu na co-orienta¸c˜ao destes projetos durante o seu desenvol-
vimento. A estrutura geral do compilador ´e apresentada na Figura 5.2. O programa foi
implementado em AspectJ e possui aproximadamente 30.000 linhas de c´odigo.
A compila¸c˜ao de uma especifica¸c˜ao S ´e definida em trˆes etapas. A primeira, de gera¸c˜ao da
´arvore de sintaxe abstrata e povoamento da tabela de s´ımbolos, ´e executada recursivamente
da seguinte maneira:
• se S for uma especifica¸c˜ao inicial, ent˜ao a compila¸c˜ao:
1. inicia as estruturas de dados da ´arvore de sintaxe abstrata da especifica¸c˜ao e a
tabela de s´ımbolos;
5.7. COMPILADOR DE NOTUS 139
Figura 5.2: Estrutura Geral do Compilador de Notus.
140 CAP
´
ITULO 5. AMBIENTE PARA SEM
ˆ
ANTICA INCREMENTAL
2. lˆe todos os m´odulos importados pelo m´odulo principal, armazenando as in-
forma¸c˜oes coletadas nas estruturas de dados;
3. resolve pendˆencias devidas a identificadores definidos em ordem diferente `a de
leitura do compilador.
• se S for uma extens˜ao da forma ∆S + t(S
), ent˜ao a compila¸c˜ao:
1. compila recursivamente a especifica¸c˜ao S
;
2. compila o transformador t e aplica-o `a ´arvore de sintaxe abstrata de S
;
3. compila os m´odulos correspondentes a ∆S, incluindo novos n´os `a ´arvore de
sintaxe abstrata transformada e novas informa¸c˜oes na tabela de s´ımbolos;
4. resolve pendˆencias devidas a identificadores definidos em ordem diferente `a de
leitura do compilador.
A segunda etapa realiza as seguintes tarefas:
1. resolu¸c˜ao das ambiguidades da defini¸c˜ao l´exica, de acordo com as regras da Se¸c˜ao 5.3.3;
2. defini¸c˜ao da estrutura da gram´atica abstrata e dos dom´ınios sint´aticos da especi-
fica¸c˜ao, segundo as regras da Se¸c˜ao 5.3.4.3 e o algoritmo da Se¸c˜ao C.3;
3. simplifica¸c˜ao das gram´aticas concreta e abstrata, de acordo com os algoritmos das
Se¸c˜oes C.1 e C.2;
4. defini¸c˜ao da ordem de gera¸c˜ao dos casos das fun¸c˜oes semˆanticas, por meio do algo-
ritmo de ordena¸c˜ao topol´ogica.
Por fim, a terceira etapa faz a gera¸c˜ao de c´odigo da seguinte maneira:
1. o analisador l´exico gerado ´e um arquivo de entrada para o sistema Alex
14
;
2. o analisador sint´atico gerado ´e um arquivo de entrada para o sistema Happy
15
;
3. as demais fun¸c˜oes s˜ao compiladas para a linguagem Haskell.
14
Ver http://www.haskell.org/alex/
15
Ver http://www.haskell.org/happy/
5.8. CONCLUS
˜
OES 141
Para obten¸c˜ao do interpretador execut´avel, deve-se gerar c´odigo Haskell para os analisado-
res l´exico e sint´atico, utilizando software disponibilizado pelos fabricantes, e, finalmente,
utilizar o compilador de Haskell para gera¸c˜ao do c´odigo execut´avel. M´odulos com imple-
menta¸c˜ao em Haskell dom´ınios e fun¸c˜oes padr˜ao s˜ao inclu´ıdos durante a gera¸c˜ao do c´odigo
execut´avel.
Extens˜oes na linguagem Notus podem ser feitas por meio da cria¸c˜ao de bibliotecas de
dom´ınios e fun¸c˜oes. Para inclu´ı-las no compilador, basta editar arquivos de configura¸c˜ao
que indiquem o que ser´a adicionado a Notus e a implementa¸c˜ao correspondente em Haskell.
Detalhes podem ser encontrados em Soares (2007).
5.8 Conclus˜oes
A linguagem Notus, apresentada neste cap´ıtulo, tem por objetivo permitir a defini¸c˜ao
incremental completa de uma linguagem de programa¸c˜ao. A linguagem permite a divis˜ao de
uma defini¸c˜ao em especifica¸c˜oes, que podem por sua vez ser divididas em pacotes e m´odulos.
Para permitir alto grau de modularidade, foram incorporados recursos para controle de
visibilidade. Exemplos do uso dos recursos de Notus para defini¸c˜oes de linguagens podem
ser encontradas no Apˆendice B.
A implementa¸c˜ao corrente de Notus permite a gera¸c˜ao de interpretadores execut´aveis para
a linguagem projetada. A partir da defini¸c˜ao incremental, geram-se o analisador l´exico,
o analisador sint´atico e as fun¸c˜oes semˆanticas. Assim, o interpretador gerado lˆe um ar-
quivo fonte na linguagem, faz an´alises l´exica e sint´atica, gerando uma ´arvore de sintaxe
abstrata para o programa; esta ´arvore de sintaxe abstrata ´e, ent˜ao, argumento das fun¸c˜oes
semˆanticas que, ao serem executadas, geram a sa´ıda do programa a partir da entrada
fornecida.
O analisador l´exico ´e gerado automaticamente a partir das declara¸c˜oes de tokens e de
n˜ao-terminais anˆonimos presentes na gram´atica concreta. A ordem de defini¸c˜ao dos ele-
mentos ´e irrelevante, o que torna poss´ıvel que elementos l´exicos sejam definidos em m´odulos
separados. Ambiguidades podem ser resolvidas por meio de regras definidas na linguagem.
O analisador sint´atico ´e gerado automaticamente a partir das declara¸c˜oes de regras de
produ¸c˜ao da gram´atica concreta da linguagem. As regras de sintaxe concreta e abs-
trata s˜ao ainda utilizadas para a defini¸c˜ao da estrutura da ´arvore de sintaxe abstrata,
que tamb´em ´e totalmente gerada pelo compilador da linguagem. As regras semˆanticas do
142 CAP
´
ITULO 5. AMBIENTE PARA SEM
ˆ
ANTICA INCREMENTAL
analisador sint´atico gerado constro e m a ´arvore de sintaxe abstrata a partir do programa
fonte. Na vers˜ao atual, o parser gerado ´e LALR(1), mas vers˜oes futuras poder˜ao adotar
outras t´ecnicas mais poderosas, tais como Generalized LR (Bravenboer and Visser 2009).
As fun¸c˜oes semˆanticas s˜ao geradas a partir das equa¸c˜oes semˆanticas e operam sobre a
´arvore de sintaxe abstrata do programa fonte para computar, a partir da sequˆencia de
entrada, a sequˆencia de sa´ıda do programa. A linguagem para escrita das equa¸c˜oes baseia-
se nos recursos mais comuns de linguagens funcionais t´ıpicas, com recursos adicionais para
tratamento de ´arvore de sintaxe, dentre os quais se destacam uma nota¸c˜ao para os n´os da
´arvore e c asamento de padr˜oes sint´atico.
Em uma especifica¸c˜ao, podem-se adicionar novas constru¸c˜oes por meio da extens˜ao de
elementos l´exicos, de gram´aticas concreta e abstrata, e da adi¸c˜ao de novas equa¸c˜oes
semˆanticas. Com isso, pode-se obter incrementabilidade tanto de defini¸c˜oes sint´aticas
quanto semˆanticas.
A defini¸c˜ao incremental baseada em componentes pode ser feita por meio da cria¸c˜ao, em
m´odulos separados, de dom´ınios sint´aticos espec´ıficos com estrutura definida de acordo
com a nota¸c˜ao para n´os de ´arvore de sintaxe abstrata existente. A transforma¸c˜ao de um
programa em um conjunto simplificado de constru¸c˜oes pode, ent˜ao, ser feita por meio de
fun¸c˜oes que mapeiem o universo sint´atico do programa no universo sint´atico das constru¸c˜oes
b´asicas.
Optou-se neste trabalho por desenvolver uma nova linguagem, em vez de estender uma
linguagem funcional j´a existente, como Haskell. O principal motivo desta decis˜ao foi a ne-
cessidade em se definir um conjunto de constru¸c˜oes mais pr´oximo das equa¸c˜oes encontradas
na literatura da ´area, permitindo a escrita de c´odigo mais leg´ıvel. Tamb´em, o uso de uma
linguagem de prop´osito geral traria dificuldades por obrigar o programador a implementar
a parte sint´atica nesta linguagem.
Al´em disso, a existˆencia de um compilador completamente desenvolvido dentro do grupo
de pesquisa deu mais flexibilidade ao desenvolvimento deste projeto.
O compilador implementado gera c´odigo na linguagem Haskell, que pode ser compilador
para qualquer m´aquina alvo para a qual haja compilador Haskell dispon´ıvel. As simila-
ridades entre as constru¸c˜oes e estruturas de Notus e Haskell permitiram que o overhead
da tradu¸c˜ao fosse O(1), de modo que o c´odigo gerado a partir de uma especifica¸c˜ao Notus
tende a ter eficiˆencia similar `aquela obtida com o uso direto da linguagem Haskell.
5.8. CONCLUS
˜
OES 143
O pr´oximo cap´ıtulo apresenta uma avalia¸c˜ao deste trabalho de tese, por meio de an´alise
qualitativa da t´ecnica proposta e uma compara¸c˜ao com trabalhos relacionados.
144 CAP
´
ITULO 5. AMBIENTE PARA SEM
ˆ
ANTICA INCREMENTAL
Cap´ıtulo 6
Avalia¸c˜ao
Organiza¸c˜ao do Cap´ıtulo. A Se¸c˜ao 6.1 apresenta uma avalia¸c˜ao da metodologia e da
linguagem Notus em rela¸c˜ao aos crit´erios descritos na Se¸c˜ao 3.1. A Se¸c˜ao 6.2 apresenta uma
compara¸c˜ao deste trabalho com trabalhos relacionados. E , por fim, a Se¸c˜ao 6.3 apresenta
as conclus˜oes do cap´ıtulo.
6.1 Avalia¸c˜ao da Metodologia
Para an´alise da metodologia, ser˜ao utilizados os seguintes crit´erios, sugeridos por Gayo
(2002), Mosses (1988), Moura (1996) e descritos na Se¸c ˜ao 3.1: ausˆencia de ambiguidade,
possibilidade de demonstra¸c˜ao, prototipa¸c˜ao, modularidade, reusabilidade, legibilidade,
flexibilidade, escalabilidade, abstra¸c˜ao e compara¸c˜ao.
Ausˆencia de Ambiguidade. Cada uma das especifica¸c˜oes pertencentes `a defini¸c˜ao in-
cremental de uma linguagem podem ser vistas como defini¸c˜oes denotacionais completas
para um subconjunto da linguagem. A cada especifica¸c˜ao, a semˆantica de algumas cons-
tru¸c˜oes lingu´ısticas pode ser vaga em rela¸c˜ao a recursos ainda n˜ao especificados, o que
n˜ao implica em ambiguidade ou incompleteza, pois compreende-se que a linguagem esteja
totalmente definida para o s ubconjunto em quest˜ao.
Possibilidade de D emonstra¸c˜ao. A t´ecnica apresentada ´e baseada na transforma¸c˜ao
das denota¸c˜oes das constru¸c˜oes lingu´ısticas, de modo que a capacidade em se demons-
trar resultados depende diretamente da teoria subjacente utilizada para especifica¸c˜ao. Por
145
146 CAP
´
ITULO 6. AVALIAC¸
˜
AO
exemplo, para transforma¸c˜oes de especifica¸c˜oes utilizando semˆantica denotacional cl´assica,
a base de demonstra¸c˜ao ´e a Teoria de Dom´ınios de Scott (Scott 1976); para especifica¸c˜oes
utilizando semˆantica mon´adica, a base ´e a teoria de mˆonadas definida por Moggi (1989).
Demonstra¸c˜oes de propriedade podem ser feitas de modo semelhante ao sugerido por Gu-
revich (1994), interpretando a especifica¸c˜ao inicial com o ground model e cada passo de
transforma¸c˜ao como uma reifica¸c˜ao da especifica¸c˜ao anterior. Assim, demonstra¸c˜oes no
ground model s˜ao mais simples, em fun¸c˜ao do menor n´umero de detalhes a tratar, e, a cada
transforma¸c˜ao, deve-se verificar quais propriedades da especifica¸c˜ao anterior se mantˆem
v´alidas.
Prototipa¸c˜ao. Utilizando-se a linguagem Notus e o ambiente de e xecu¸c˜ao desenvolvido,
´e poss´ıvel realizar a prototipa¸c˜ao de uma linguagem, definindo-se tanto os seus elementos
sint´aticos quanto os semˆanticos. A partir de uma defini¸c˜ao semˆantica escrita em Notus, ´e
poss´ıvel obter um interpretador completo para a linguagem, que pode ser utilizado para
testes e provas de conceito.
Modularidade. A linguagem de especifica¸c˜ao possui o conceito de encapsulamento em
m´odulos com mecanismos de controle de visibilidade. As transforma¸c˜oes permitem o iso-
lamento de m´odulos das especifica¸c˜oes iniciais da linguagem, de modo que a denota¸c˜ao de
uma constru¸c˜ao pode ser vista de maneira atˆomica a partir de especifica¸c˜oes subsequen-
tes. Assim, cada m´odulo pode exportar somente os s´ımb olos terminais e n˜ao-terminais
da gram´atica concreta, a estrutura da sintaxe abstrata, as fun¸c˜oes semˆanticas e fun¸c˜oes
auxiliares.
Com exce¸c˜ao da estrutura da sintaxe abstrata, todos os demais elementos podem ser vistos
como ´atomos da especifica¸c˜ao, sendo que as equa¸c˜oes semˆanticas e as regras de produ¸c˜ao da
gram´atica concreta s˜ao inacess´ıveis a outros m´odulos. Regras de produ¸c˜ao da sintaxe abs-
trata da linguagem, no entanto, s˜ao p´ublicas, mas n˜ao podem s er manipuladas por outros
m´odulos; as ´unicas opera¸c˜oes permitidas a um m´odulo s˜ao incluir novas regras `a sintaxe
abstrata existente e a consulta `a sua estrutura. O grau de coes˜ao nas defini¸c˜oes pode ser
aumentado uma vez que, ao ser poss´ıvel remover o entrela¸camento de c´odigo, as equa¸c˜oes
de um m´odulo podem ser organizadas de modo a definirem uma ´unica funcionalidade –
n´ıvel de coes˜ao funcional. Quanto ao acoplamento entre m´odulos, a escrita de equa¸c˜oes
simples tende a tornar cada m´odulo mais independente, sendo assim poss´ıvel obter n´ıveis
mais baixos de acoplamento.
6.1. AVALIAC¸
˜
AO DA MET ODOLOGIA 147
A interface de um m´odulo pode ser no futuro gerada por meio de uma ferramenta de apoio
para ser apresentada ao leitor. Apesar de fun¸c˜oes de transforma¸c˜ao alterarem a interface de
um m´odulo, a leitura de m´odulos de especifica¸c˜oes iniciais pode ser feita na especifica¸c˜ao
original e n˜ao na alterada; com isso, a altera¸c˜ao da interface n˜ao traz dificuldades na
extra¸c˜ao da interface dos m´odulos.
Al´em disso, o racioc´ınio modular ´e garantido, uma vez que as transforma¸c˜oes poss´ıveis
foram definidas de tal forma que o entendimento de uma especifica¸c˜ao independe das
especifica¸c˜oes posteriores.
Reusabilidade. A defini¸c˜ao de m´odulos simples, em especial nas especifica¸c˜oes iniciais
da linguagem, permitem o isolamento da defini¸c˜ao de constru¸c˜oes, de modo que estas
podem ser reutilizadas na escrita de especifica¸c˜oes de linguagens correlatas. Al´em disso, a
organiza¸c˜ao modular da linguagem de defini¸c˜ao, com recursos de importa¸c˜ao de elementos
p´ublicos e oculta¸c˜ao de dados privados permitem a defini¸c ˜ao de m´odulos independentes,
que tendem a ser mais facilmente reaproveitados.
Legibilidade. A utiliza¸c˜ao da vagueza tende a tornar as especifica¸c˜oes mais simples, pois
permite que o leitor isole os elementos de maior relevˆancia no momento, n˜ao tendo que se
preocupar com itens intrusos nas equa¸c˜oes. A leitura de uma especifica¸c˜ao denotacional
tende a exigir conhecimentos pr´evios da nomenclatura utilizada. No entanto, o uso de uma
teoria subjacente mais arrojada, como a semˆantica mon´adica, pode permitir a simplifica¸c˜ao
das equa¸c˜oes, tornando-as mais simples de se compreender.
Flexibilidade. Como a teoria desenvolvida se baseia em semˆantica denotacional cl´assica,
fornecendo subs´ıdios para a escrita separada de defini¸c˜oes, n˜ao h´a restri¸c˜ao `a defini¸c˜ao de
recursos que podem ser definidos por meio da semˆantica denotacional. O uso de semˆantica
de mˆonadas como teoria subjacente pode permitir a inclus˜ao de recursos n˜ao bem tratados
pela semˆantica denotacional, tais como n˜ao-determinismo e concorrˆencia.
Escalabilidade. A metodologia pode ser utilizada para a defini¸c˜ao de linguagens de
grande porte, a exemplo do trabalho realizado por Crepalde et al. (2008a), em que a
defini¸c˜ao da parte sequencial de Java foi feita de maneira incremental.
148 CAP
´
ITULO 6. AVALIAC¸
˜
AO
Abstra¸c˜ao. Altos n´ıveis de abstra¸c˜ao podem ser obtidos pelo uso adequado de meca-
nismos de m´odulos e controle de visibilidade. No entanto, na presen¸ca do entrela¸camento
de constru¸c˜oes, torna-se muito complicado entender cada denota¸c˜ao de maneira indepen-
dente, de modo que o leitor pode se ver obrigado a tratar grandes sistemas de equa¸c˜oes
altamente relacionadas. Ao se prover melhor separa¸c˜ao das equa¸c˜oes, diminui-se o n´umero
de elementos a serem levados em considera¸c˜ao ao se entender um m´odulo. Al´em disso, a
vagueza das defini¸c˜oes iniciais ´e um importante fator para a melhoria do grau de abstra¸c˜ao,
por permitir a compreens˜ao de constru¸c˜oes sem a necessidade de se entender como ela se
relaciona a conceitos ainda n˜ao estudados.
No contexto de semˆantica denotacional, o termo abstra¸c˜ao tamb´em se refere ao fato de que
a denota¸c˜ao de uma constru¸c˜ao ´e uma fun¸c˜ao somente das denota¸c˜oes de seus constituintes.
As fun¸c˜oes de transforma¸c˜ao s˜ao meras substitui¸c˜oes textuais das equa¸c˜oes existentes, de
modo que a sua aplica¸c˜ao n˜ao viola a abstra¸c˜ao j´a existente na defini¸c˜ao.
Compara¸c˜ao. Este crit´erio n˜ao foi analisado neste trabalho, mas acredita-se que a va-
gueza pode auxiliar tamb´em na compara¸c˜ao entre recursos lingu´ısticos, uma vez que per-
mite a an´alise de equa¸c˜oes mais simples.
6.2 Compara¸c˜ao com Trabalhos Relacionados
V´arios trabalhos importantes abordam o problema de modularidade de defini¸c˜oes semˆan-
ticas, com destaque para os trabalhos citados no Cap´ıtulo 3.
O modelo de M´aquinas de Estado Abstratas (Gurevich 1994, 1995), descrito na Se¸c˜ao 3.1.2.2,
permite a defini¸c˜ao incremental de linguagens de programa¸c˜ao, como mostrado por B¨orger
and Schulte (1998) na defini¸c˜ao da linguagem Java. A principal distin¸c˜ao desse trabalho
com o trabalho aqui apresentado est´a no fato de que aquela t´ecnica permite que a defini¸c˜ao
seja constru´ıda de maneira incremental, mas o res ultado final, apresentado ao leitor, ´e um
conjunto de regras ainda entrela¸cadas.
A Semˆantica Operacional Estruturada Modular (Mosses 2004), descrita na Se¸c˜ao 3.1.2.3,
´e uma forma ele gante de se obter a semˆantica modular de uma linguagem de programa¸c˜ao.
No entanto, conforme j´a discutido no momento em que esta t´ecnica foi apresentada neste
texto, certos recursos lingu´ısticos exigem a defini¸c˜ao da semˆantica operacional em peque-
nos passos, o que pode levar `a necessidade de um n´umero elevado de regras de transi¸c˜ao.
6.2. COMPARAC¸
˜
AO COM TRABALHOS RELACIONADOS 149
Vale ressaltar que esta quest˜ao est´a intrinsicamente relacionada ao modelo de semˆantica
operacional estruturada subjacente, e o mesmo n˜ao ocorre no modelo de semˆantica denota-
cional. Com efeito, no modelo proposto, existe apenas uma equa¸c˜ao que define a semˆantica
de uma constru¸c˜ao, e esta equa¸c˜ao evolui com o intuito de acomodar novos recursos.
A Semˆantica de A¸c˜oes (Mosses 1977, 1993, Mosses and Watt 1987), descrita na Se¸c˜ao 3.2.1,
permite a escrita de equa¸c˜oes leg´ıveis, muito pr´oximas a descri¸c˜oes em linguagem natural.
O trabalho aqui apresentado aborda o problema de entrela¸camento de defini¸c˜oes, que n˜ao
´e tratado em semˆantica de a¸c˜oes. Al´em disso, a t´ecnica proposta pode ser adaptada para
utiliza¸c˜ao em semˆantica de a¸c˜oes.
A semˆantica de mˆonadas (Moggi 1989, Wadler 1990), apresentada na Se¸c˜ao 3.2.2, leva
a melhoria das equa¸c˜oes do modelo denotacional, ao permitir a abstra¸c˜ao de conceitos
comuns em defini¸c˜oes denotacionais, tais como stores, environments e continua¸c˜oes. O
aspecto incremental da t´ecnica ´e obtido por meio da evolu¸c˜ao da mˆonada subjacente a uma
defini¸c˜ao por meio de transformadores de mˆonadas (Liang et al. 1995). No entanto, o n´ıvel
de abstra¸c˜ao obtido n˜ao permite ainda a defini¸c˜ao separada de constru¸c˜oes relacionadas,
como pode ser percebido na defini¸c˜ao da semˆantica mon´adica de AspectJ, apresentada por
Wand et al. (2004). O trabalho aqui descrito ´e uma solu¸c˜ao vi´avel para o problema do
entrela¸camento, podendo inclusive ser utilizado em conjunto com a semˆantica mon´adica
para a obten¸c˜ao de defini¸c˜oes mais leg´ıveis.
A semˆantica de a¸c˜oes com mˆonadas (Wansbrough and Hamer 1997), descritas na Se¸c˜ao 3.2.3,
´e uma t´ecnica que modulariza a defini¸c˜ao da nota¸c˜ao de a¸c˜oes, n˜ao abordando a forma
como as constru¸c˜oes s˜ao definidas. Por isso, valem as mesmas conclus˜oes a que se chegou
ao comparar a metodologia proposta com a semˆantica de a¸c˜oes.
A t´ecnica proposta por de Moor et al. (2000), descrita na Se¸c˜ao 3.2.4, utiliza os conceitos
da orienta¸c˜ao por aspectos para melhorar a modularidade de gram´aticas de atributos, po-
dendo ser aplicada a defini¸c˜oes denotacionais. No entanto, as t´ecnicas propostas tˆem como
foco modularizar a comunica¸c˜ao entre constru¸c˜oes que se relacionem por meio da ´arvore
de sintaxe abstrata do programa. Este trabalho melhora as contribui¸c˜oes de de Moor et al.
(2000), uma vez que permite tratar rela¸c˜oes entre constru¸c˜oes que n˜ao estejam direta-
mente associadas na ´arvore de sintaxe abstrata, como ocorre com defini¸c˜ao e chamadas de
m´etodos.
Por fim, a abordagem construtiva (Mosses 2005), descrita na Se¸c˜ao 3.2.5, permite al-
can¸car altos n´ıveis de modularidade ao introduzir o conceito de componente no contexto
de defini¸c˜oes semˆanticas. No entanto, n˜ao h´a mecanismos para evitar entrela¸camento de
150 CAP
´
ITULO 6. AVALIAC¸
˜
AO
defini¸c˜oes para constru¸c˜oes relacionadas durante a tradu¸c˜ao das constru¸c˜oes de uma lin-
guagem em combina¸c˜oes de constru¸c˜oes de uma linguagem base. O trabalho proposto
pode ser combinado com as contribui¸c˜oes desta abordagem construtiva, permitindo que as
equa¸c˜oes de tradu¸c˜ao possam evoluir, evitando, assim, o entrela¸camento.
6.3 Conclus˜oes
A metodologia proposta tem impacto positivo direto nos crit´erios de prototipa¸c˜ao, mo-
dularidade, reusabilidade, legibilidade, escalabilidade, sem preju´ızo dos demais crit´erios
citados.
Este trabalho complementa as contribui¸c˜oes de trabalhos anteriores, sendo poss´ıvel, em
algumas situa¸c˜oes aliar uma metodologia j´a existente com a metodologia proposta. Com
isso, acredita-se que este trabalho contribui para a populariza¸c˜ao da semˆantica formal de
linguagens de programa¸c˜ao.
O pr´oximo cap´ıtulo apresenta as conclus˜oes deste trabalho de tese, as principais contri-
bui¸c˜oes e poss´ıveis trabalhos futuros.
Cap´ıtulo 7
Conclus˜oes
Esta tese apresentou uma nova abordagem para melhorar a modularidade de especifica¸c˜oes
de semˆantica denotacional. Esta t´ecnica, baseada nas propriedades de vagueza das de-
fini¸c˜oes iniciais, transforma¸c˜ao de especifica¸c˜ao e evolu¸c˜ao de denota¸c˜oes, pode melhorar
a legibilidade de equa¸c˜oes semˆanticas por meio da separa¸c˜ao de preocupa¸c˜oes em cons-
tru¸c˜oes lingu´ısticas que se entrecortam. Em uma defini¸c˜ao incremental, ´e poss´ıvel incluir
novas constru¸c˜oes sem a necessidade de reescrever equa¸c˜oes previamente definidas, mesmo
nos casos em que uma constru¸c˜ao deve preparar contexto para outras. Assim, o objetivo
do mo de lo proposto ´e permitir que as constru¸c˜oes de uma linguagem sejam apresentadas
de maneira mais intuitiva, o que ´e mais pr´oximo `as descri¸c˜oes em linguagem natural: cada
constru¸c˜ao pode ser isolada para melhor compreens˜ao.
A metodologia proposta para defini¸c˜ao incremental fornece mecanismos simples para a de-
fini¸c˜ao da semˆantica de linguagens de programa¸c˜ao. A defini¸c˜ao de uma constru¸c˜ao pode
ser vaga em rela¸c˜ao a outras, o que torna mais simples compreender sua semˆantica, visto
que as rela¸c˜oes entre constru¸c˜oes s˜ao definidas separadamente e, portanto, n˜ao tendem a
atrapalhar o entendimento. Apesar de a vagueza ser um recurso essencial em defini¸c˜oes
informais, ela n˜ao pode ser controlada neste contexto, de modo que defini¸c˜oes incomple-
tas podem parecer vagas. No entanto, quando aplicada a de fini¸c˜oes formais, a vagueza
ajuda a construir a ponte com defini¸c˜oes informais, levando a melhor legibilidade. Al´em
disso, esta t´ecnica pode ser utilizada juntamente com outras abordagens de modulari-
dade de semˆantica denotacional, como por exemplo os recursos da semˆantica mon´adica,
beneficiando-se de seus aspectos positivos.
151
152 CAP
´
ITULO 7. CONCLUS
˜
OES
Um problema muito complicado de se tratar na transforma¸c˜ao de semˆantica denotacio-
nal ´e a preserva¸c˜ao da abstra¸c˜ao da defini¸c˜ao semˆantica. Esta propriedade ´e preservada
pois todas as transforma¸c˜oes requerem somente substitui¸c˜oes textuais para se gerar a es-
pecifica¸c˜ao costurada. Assim as fun¸c˜oes de transforma¸c˜ao n˜ao violam a abstra¸c˜ao das
equa¸c˜oes existentes, de modo que a denota¸c˜ao de uma constru¸c˜ao depende exclusivamente
da denota¸c˜ao de seus constituintes.
Al´em disso, extensibilidade ´e melhorada por meio da separa¸c˜ao de preocupa¸c˜oes provida
pela vagueza da especifica¸c˜ao. Altos graus de extensibilidade s´o s˜ao obtidos em sistemas
de software quando m´odulos s˜ao simples e independentes, pois com isso torna-se mais f´acil
lidar com modifica¸c˜oes Meyer (1997). M´odulos de finidos por meio da abordagem proposta
tendem a manipular um conjunto m´ınimo de informa¸c˜oes, com impacto direto na qualidade
geral da modularidade.
Organiza¸c˜ao do Cap´ıtulo. A Se¸c˜ao 7.1 indica as contribui¸c˜oes deste trabalho, e a
Se¸c˜ao 7.2 discute poss´ıveis trabalhos futuros.
7.1 Contribui¸c˜oes do Trabalho
A principal contribui¸c˜ao deste trabalho de tese ´e a defini¸c˜ao da metodologia de semˆantica
incremental, que se baseia na vagueza aplicada a defini¸c˜oes formais e na evolu¸c˜ao da de-
nota¸c˜ao de constru¸c˜oes. O mecanismo proposto permite ao projetista apresentar de ma-
neira incremental a defini¸c˜ao de uma linguagem de forma semelhante `a presente em livros
did´aticos e manuais de linguagem.
Nesta t´ecnica, pode ser apresentada ao leitor uma sequˆencia de especifica¸c˜oes que descre-
vem como programas completos podem ser escritos na linguagem. Cada especifica¸c˜ao da
sequˆencia acrescenta novos recursos `a especifica¸c˜ao anterior e, se necess´ario, estabelece a
forma como as denota¸c˜oes das constru¸c˜oes j´a definidas devem evoluir para acomodar os
novos recursos.
A evolu¸c˜ao de denota¸c˜oes ´e definida por meio da utiliza¸c˜ao de transformadores de fun¸c˜ao,
que ´e uma das contribui¸c˜oes deste trabalho. Como principal ponto positivo da t´ecnica,
pode-se resolver diversos problemas de entrela¸camento de defini¸c˜oes de constru¸c˜oes rela-
cionadas, por meio da separa¸c˜ao de preocupa¸c˜oes, com impacto direto na escalabilidade de
7.2. TRABALHOS FUTUROS 153
semˆantica denotacional. Com efeito, com a solu¸c˜ao do entrela¸camento, remove-se um dos
itens que levam `a complexidade inerente do formalismo.
Outra importante contribui¸c˜ao do trabalho ´e a formaliza¸c˜ao da vagueza e a an´alise de sua
relevˆancia no contexto de m´etodos formais. Com efeito, a vagueza permite que, ao se ler
uma defini¸c˜ao, conceitos relacionados, mas n˜ao fundamentais `a compreens˜ao, possam ser
omitidos, com impacto direto na facilidade de leitura. Este recurso ´e particularmente ´util
nas vers˜oes iniciais de uma defini¸c˜ao formal.
Al´em disso, neste trabalho foi feita ainda a defini¸c˜ao da linguagem Notus que permite
a de fini¸c˜ao completa de linguagens de programa¸c˜ao utilizando a metodologia proposta.
A linguagem possui recursos para a defini¸c˜ao da sintaxe e da semˆantica denotacional da
linguagem e contempla recursos para modularidade, controle de visibilidade, defini¸c˜ao de
componentes, transforma¸c˜oes de fun¸c˜ao e agrupamento de especifica¸c˜oes.
A implementa¸c˜ao de um compilador para a linguagem Notus ´e descrita por Loredo et al.
(2008), Soares (2007). O compilador tem como entrada uma especifica¸c˜ao de linguagem
em Notus e gera, como resultado, um interpretador execut´avel que realiza a leitura do
programa fonte e dos dados de entrada, faz an´alises l´exica e sint´atica e executa as fun¸c˜oes
semˆanticas para produ¸c˜ao do resultado final.
Conforme mencionado anteriormente, ´e importante ressaltar que este trabalho comple-
menta as contribui¸c˜oes de trabalhos anteriores, sendo poss´ıvel, em algumas situa¸c˜oes aliar
uma metodologia j´a existente com a metodologia proposta. Com isso, acredita-se que este
trabalho contribui para a populariza¸c˜ao da semˆantica formal de linguagens de programa¸c˜ao.
7.2 Trabalhos Futuros
Algumas restri¸c˜oes deste trabalho podem ser tratadas como poss´ıveis trabalhos futuros.
Do ponto de vista da metodologia, um ponto interessante de pesquisa consiste em avaliar
a possibilidade de, em vez de se definir uma sequˆencia de especifica¸c˜oes, estas pudessem
ser organizadas na forma de um grafo ac´ıclico dirigido representando suas rela¸c˜oes de
dependˆencia. Neste trabalho, tal quest˜ao n˜ao foi tratada em virtude das dificuldades em
se tratar a possibilidade de uma mesma fun¸c˜ao ser alvo de transforma¸c˜oes distintas e
independentes realizadas por transformadores distintos
1
.
1
Este problema ´e semelhante ao problema do losango em heran¸ca m´ultipla de classes na programa¸c˜ao
orientada por objetos.
154 CAP
´
ITULO 7. CONCLUS
˜
OES
Outro ponto importante para investiga¸c˜ao diz respeito `a possibilidade de se inclu´ırem
novos tipos de transformadores, tais como transformadores de dom´ınios semˆanticos. No
entanto, a incorpora¸c˜ao deste recurso leva a dificuldades em compatibilizar as fun¸c˜oes j´a
existentes, uma vez que poss´ıveis opera¸c˜oes de inje¸c˜ao e proje¸c˜ao em dom´ınios podem levar
a perda de informa¸c˜oes anteriormente presentes. Uma poss´ıvel solu¸c˜ao consiste em limitar
as opera¸c˜oes dos dom´ınios para extens˜ao de tuplas, de maneira semelhante a extens˜ao de
classes na programa¸c˜ao orientada por objetos. Novas transforma¸c˜oes poderiam ainda ser
aplicadas em outros elementos da defini¸c˜ao, tais como a gram´atica concreta da linguagem.
Ainda do ponto de vista da teoria proposta, considera-se de grande importˆancia verificar
a existˆencia de um conjunto de transformadores completo, com o qual toda transforma¸c˜ao
comput´avel que preserve abstra¸c˜ao do modelo denotacional pudesse ser especificada.
´
E
ainda desej´avel que esta base de transformadores seja ao mesmo tempo m´ınima e com-
posta por transforma¸c˜oes simples, que exijam menos esfor¸co de aprendizado por parte do
projetista e do leitor das defini¸c˜oes.
Quanto `a linguagem Notus, alguns elementos interessantes poderiam ser incorporados tais
como o suporte a mˆonadas e a defini¸c ˜ao de uma biblioteca rica contendo dom´ınios e fun¸c˜oes
espec´ıficos para a defini¸c˜ao de linguagens de programa¸c˜ao. Outro recurso que poderia ser
inclu´ıdo diz respeito a mecanismos mais poderosos para a transforma¸c˜ao de gram´atica
concreta em gram´atica abstrata. Os recursos presentes nesta vers˜ao n˜ao permitem, por
exemplo, que a gram´atica abstrata seja unicamente definida como um n´ucleo simples cujas
constru¸c˜oes possam ser combinadas para defini¸c˜ao de constru¸c˜oes avan¸c adas. Tais recursos
seriam particularmente ´uteis para a defini¸c˜ao de componentes lingu´ısticos, que hoje deve
ser feita por meio de fun¸c˜oes de mapeamentos entre universos sint´aticos.
Finalmente, do ponto de vista da implementa¸c˜ao realizada, seria importante a incorpora¸c˜ao
dos novos recursos decorrentes destas novas pesquisas. Al´em disso, uma limita¸c˜ao `a ex-
tensibilidade ´e devida `a utiliza¸c˜ao de parser LALR(1); com efeito, a inclus˜ao de novas
regras de produ¸c˜ao pode gerar conflitos com regras j´a existentes, levando `a redefini¸c˜ao de
m´odulos j´a escritos. Uma poss´ıvel solu¸c˜ao consiste na utiliza¸c˜ao de t´ecnicas baseadas em
Generalized LR (Bravenboer and Visser 2009) e a inclus˜ao de constru¸c˜oes de remo¸c˜ao de
ambiguidades em gram´aticas.
Apˆendice A
The Syntax of Notus
This chapter pres ents the complete syntax of Notus, by means of its BNF Grammar.
A.1 Lexis Convention
This chapter pres ents basic elements of the language used throughout the text.
Names Notus defines names for:
• packages, modules, transformers, and domains, which start with a capital letter and
ends with a letter; these names are generally called capital names; examples of those
names are:
C String DomainA Domain a Domain A A2b Pir8 domain Sk8r
• tokens, elements, variables, functions, identifier patterns, enumerands, and labels,
which start with a non-capital letter or the underline character and may be decorated
with digits; these names are also generally called ordinary names; examples of those
names are:
f string elem1 elem a elem A1 pir8 domain test comm1
In the text, these names are denoted by package-name, module-name, domain-name, token-
name, element-name, variable-name, function-name, id-pattern-name, enumerand-name,
transformer-name, and label.
155
156 AP
ˆ
ENDICE A. THE SYNTAX OF NOTUS
Due to implementation is sues, it is erroneous to define names with two or more adjacent
underline symbols. A single underline symbol does not constitute an identifier, since it is
reserved to represent the anonymous pattern (see Section 5.4.2).
Sequences of digits finishing ordinary names are considered decorations, so that comm123
is considered to be name comm decorated with 123. If the component identified by an
ordinary name lacks a domain definition, the capital name of the latter may be implied
by the compiler by: (i) e liminating its decoration; (ii) capitalizing its first letter. If there
exists such domain name, the component is considered to be in such domain. For instance,
comm123 is considered to be in domain Comm if there exists such domain name. In the same
way, identifiers int1, int25, int2001 are considered to be in domain Int.
Capital names are defined by means of the regular expression L((l|L|d|u)
∗
(l |L|u))
?
, where
l represents any lowercase letter, L represents any uppercase letter, d represents any digit
from 0 to 9, and u represents the underline symbol. Ordinary names are defined by means
of the regular expression l(l|L|d|u)
∗
|u(l |L|d|u)
+
.
Literal Constants Notus defines the following Literal constants:
• boolean-value denotes the values true and false;
• int-number denotes 8-bits, 16-bits, or 32-bits integer numbers written in one of the
following bases:
– decimal: the number is a sequence of one or more digits from 0 to 9;
– octal: the number is a sequence of one or more digits from 0 to 7, preceeded by
the digit 0;
– hexadecimal: the number is a sequence of one or more hexadecimal digits, i.e.
digits from 0 to 9 and letters from a to f, preceeded by 0x;
This literal c onstant is defined by means of the regular expression: 0(x|X)(d|l)
+
|d
+
,
where d represents any digit from 0 to 9, and l represents any of the letters a, A, b,
B, c, C, d, D, e, E, f , or F.
• long-number denotes 64-bits integer numbers written in one of the following bases:
– decimal: the number is a sequence of one or more digits from 0 to 9, ended up
with the letter l or L;
A.1. LEXIS CONVENTION 157
– octal: the number is a sequence of one or more digits from 0 to 7, preceeded by
the digit 0, ended up with the letter l or L;
– hexadecimal: the number is a sequence of one or more hexadecimal digits, i.e.
digits from 0 to 9 and letters from a to f, prec eeded by 0x, ended up with the
letter l or L;
This literal constant is defined by means of the regular expression: (0(x|X)(d|l)
+
|d
+
)(l|L),
where d represents any digit from 0 to 9, and l represents any of the letters a, A, b,
B, c, C, d, D, e, E, f , or F.
• double-number denotes IEEE 754 64-bit floating point numbers, and are defined by
the regular expression d
+
(.d
+
)
?
((e|E)(+|-)
?
d
+
)
?
, where d represents any digit from 0
to 9.
• float-number denotes IEEE 754 32-bit floating point numbers, and are defined by
the regular expression d
+
(.d
+
)
?
((e|E)(+|-)
?
d
+
)
?
(f|F), where d represents any digit
from 0 to 9.
• character denotes single characters enclosed by single quotes, with the following
escape sequences:
\a alarm \t tabular
\b backspace \\ backslash
\f form-feed \’ single quote
\n line-feed \" double quote
Characters are defined by means of the regular expression
(c|e|o|h|u)
, where:
– c represents any printable ASCII character;
– e represents any escape sequence listed above;
– o represents ASCII characters denoted by their octal representation and are
defined by the regular expression \ddd, where d represents a digit from 0 to 7;
– h represents ASCII characters denoted by their hexadecimal representation and
are defined by the regular expression \x(d|l)(d|l), where d represents a digit
from 0 to 9, and l represents one of the letters a, A, b, B, c, C, d, D, e, E, f ,
or F.
158 AP
ˆ
ENDICE A. THE SYNTAX OF NOTUS
– u represents Unicode characters denoted by their hexadecimal representation
and are defined by the regular expression \u(d|l)(d|l)(d|l)(d|l), where d repre-
sents a digit from 0 to 9, and l represents one of the letters a, A, b, B, c, C, d,
D, e, E, f , or F.
• quotation denotes double quoted sequences of characters, with the same escape se-
quences as characters. Quotations are defined by the regular expression "(c|e|o|h|u)
∗
",
where c, e, o, h, and u are same as in the definition of characters.
Comments Comments in Notusare line comments and text comments. Line comments
start with "//" and the compiler ignores everything from the "//" to the end of the
line. Text comments start with "/*", end with "*/", and the compiler ignores everything
between these symbols.
Keywords The keywords of Notus are:
by case contains default element else
end evaluate extend extension function if
ignore import in input is let
module of otherwise output preproc private
public redefine replace semantics signature sintactic
syntax then token transformation where with
within
Layout Rules Inside a module the delimiters semicolon and braces may be omitted,
so that the Notus pre-processor inserts them when their presences may be implied from
indentation. The layout rules may be used for omitting the following delimiters:
• the semicolon e nding each declaration;
• the braces in function body definitions;
• the braces in the last argument of a function application;
• the braces and semicolons in let, where, and case expressions.
A.2. MODULAR ORGANIZATION 159
A.2 Modular Organization
module → module-header import-section declaration* module-end
| extension-header contains-section
| transf-header import-section t ransf-section* module-end
module-header → module module-full-name
module-full-name → module-qualification module-name
module-qualification → mo dule-qualification package-name “.”
| λ
import-section → import module-full-name+-“,”“;”
| λ
declaration → visibility exportable-declaration “;”
| non-exportable-declaration “;”
visibility → public | private | λ
module-end → end | λ
non-exportable-declaration → preproc expression
| semantics expression
extension-header → extension transformer-full-name “(” module-full-name “)”
contains-section → contains module-full-name+-“,”“;”
| λ
transformation-header → tran sformation transformer-name
transformer-full-name → module-qualification transformer-name
160 AP
ˆ
ENDICE A. THE SYNTAX OF NOTUS
A.3 Domains
exportable-declaration → syntactic-domain-declaration
| semantic-domain-declaration
syntactic-domain-declaration → syntactic domain-name
semantic-domain-declaration → domain-name “=”domain-exp
domain-exp → union-domain-exp
union-domain-exp → union-domain-exp “|” function-domain-exp
| function-domain-exp
function-domain-exp → list-domain-exp “->” function-domain-exp
| list-domain-exp
list-domain-exp → list-domain-exp “*”
| primary-domain-exp
primary-domain-exp → domain-full-name
| enum-domain-exp
| tuple-domain-exp
domain-full-name → module-full-name “.”domain-name
| domain-name
tuple-domain-exp → visibility constructor “(”domain-exp*-“,”“)”
constructor → constructor-name
| λ
enum-domain-exp → visibility “{”enumerand-name+-“,”“}”
A.4. LEXIS DEFINITIONS 161
A.4 Lexis Definitions
The following grammar summarizes the syntax for lexical specifications:
exportable-declaration → token-declaration
| tokelem- declaration
non-exportable-declaration → ignore-definition
| token-exte nsion
| tokenelem -ex tension
token-declaration → token token-name domain-definition
“=”regular-expression lexeme-function
domain-definition → “:”domain-full-name
| λ
lexeme-function → is expression
| λ
tokelem-declaration → element element-name “=”regular-expression
ignore-declaration → ignore regular-expression
token-extension → extend token qualified-id with regular-expression
tokenelem-extension → extend element qualified-id with regular-expression
The following grammar summarizes the syntax for regular expressions:
regular-expression → regular-expression “|”regexp-concatenation
| regexp-concatenation
regexp-concatenation → regexp-concatenation regexp-unary
| regexp-unary
regex-unary | regexp-primary “*”
| regexp-primary “+”
| regexp-primary “?”
| regexp-primary
regexp-primary → “(”regular-expression “)”
| quotation
| charset
| qualified-id
162 AP
ˆ
ENDICE A. THE SYNTAX OF NOTUS
A.5 Syntax Definition
The following grammar summarizes the syntax of syntax definition.
exportable-declaration → variable-declaration
non-exportable-declaration → startsymbol qualified-id
| variable-extension
variable-declaration → id domain-definition rhs-definition
rhs-definition → “::=”rule-rhs+-“|”
| λ
rule-rhs → grammar-constituent abs-rhs-definition
abs-rhs-definition → abstract-rule-definition
| ignore-indirection-definition
| λ
abstract-rule-definition → “:”“[”abs-grammar-constituent “]”
ignore-indirection-definition → “:”qualified-id
variable-extension → extend qualified-id with rule-rhs+-“|”
The following grammar summarizes the syntax of grammar constituents:
grammar-constituent → grammar-contituent-list
| empty
| λ
grammar-constituent-list → grammar-contituent-list grammar-term
| grammar-term
grammar-term → grammar-unit “*”
| grammar-unit “+”
| grammar-unit “*-”quotation
| grammar-unit “+-”quotation
| grammar-unit
grammar-unit → qualified-id
| quotation
A.6. FUNCTION DEFINITIONS 163
The following grammar summarizes the syntax of abstract grammar constituents:
abs-grammar-constituent → abs-grammar-contituent-list
| empty
abs-grammar-constituent-list → abs-grammar-contituent-list abs-grammar-term
| abs-grammar-term
abs-grammar-term → grammar-unit “*”
| grammar-unit “+”
| grammar-unit
A.6 Function Definitions
The syntax for function declaration and definition is given by the following grammar:
exportable-declaration → function-declaration
function-declaration → function id “:”domain-exp
non-exportable-declaration → function-definition
function-definition → qualified-id function-params “=”expression
function-params → pattern*
164 AP
ˆ
ENDICE A. THE SYNTAX OF NOTUS
A.7 Patterns
The syntax of patterns is defined by means of the following grammar.
pattern → head-tail-pattern
| primary-pattern
head-tail-pattern → primary-pattern “:”head-tail-pattern
| primary-pattern “ :”id-pattern
primary-pattern → literal-value
| signed-number-pattern
| id-pattern
| tuple-pattern
| list-pattern
| node-pattern
signed-number-pattern → “-” int-number
| “-” long-number
| “-” double-number
| “-” float-number
id-pattern → id-pattern “*”
| id-pattern “+”
| qualified-id
tuple-pattern → constructor-name “(”patterns-list “)”
list-pattern → “(”pattern*-“,”“)”
node-pattern → “[”node-pattern-element+ “]”
node-pattern-element → id-pattern
| quotation
| empty
A.8. EXPRESSIONS 165
A.8 Expressions
Syntax of Expressions The syntax of expressions is given by the following grammar.
All non-terminals are defined throughout this section.
expression → operation
compound-expression → if-expression
| case-expression
| let-expres sion
| where-expre ssion
| lambda-abstraction
primary-expression → literal-value
| aggregate
| identifier
| “(”expression “)”
| evaluate-expression
| fun-update-expression
Literal Values The grammar for literal values is:
literal-value → boolean-value
| int-number
| long-number
| double-number
| float-number
| character
| quotation
Aggregates The grammar for aggregates is:
aggregate → tuple-aggregate
| list-aggregate
tuple-aggregate → constructor-name “(”expression*“,”“)”
list-aggregate → “(”expression*“,”“)”
166 AP
ˆ
ENDICE A. THE SYNTAX OF NOTUS
Identifiers The syntax of identifiers is given by the following grammar.
identifier → list-decorated-id
list-decorated-id → list-decorated-id “+”
| list-decorated-id “*”
| qualified-id
qualified-id → id-qualification id
id-qualification → id-qualification domain-id “.”
| λ
Operations The syntax for operations is given by the following grammar:
operation → pattern-matching-operation
pattern-matching → fun-composition-op e ration is pattern
fun-composition-operation → list-append-operation “.”fun-composition-operation
| list-append-operation
list-append-operation → list-append-operation “++” list-cons-operation
| list-cons-operation
list-cons-operation → or-operation “:”list-cons-operation
| or-operation
or-operation → or-operation or and-operation
| and-operation
and-operation → and-operation and rel-operation
| rel-operation
rel-operation → additive-operation “=” additive-operation
| additive-operation “!=” additive-operation
| additive-operation “<” additive-operation
| additive-operation “<=” additive-operation
| additive-operation “>” additive-operation
| additive-operation “>=” additive-operation
| additive-operation
additive-operation → additive-operation “+” mult-operation
| additive-operation “-” mult-operation
| additive-operation “|” mult-operation
| additive-operation “^” mult-operation
| mult-operation
mult-operation → mult-operation “*” unary-operation
continues on next page...
A.8. EXPRESSIONS 167
...continued from previous page
| mult-operation “/” unary-operation
| mult-operation mod unary-operation
| mult-operation “&” unary-operation
| mult-operation “>>” unary-operation
| mult-operation “>>>” unary-operation
| mult-operation “<<” unary-operation
| unary-operation
unary-op eration → “-” compound-expression
| “~” compound-expression
| not compound-expression
| compound-expression
Function Application The grammar for function applications and evaluate expressions
is given by the following grammar:
function-application → function-application primary-expression
| primary-expression
evaluate-expression → evaluate “{”evaluate-part “}”
evaluate-part → evaluate-part “;”function-application
| function-application
Lamb da Abstraction The syntax for lambda abstractions is given by the following
grammar:
lambda-abstraction → “\”pattern+ “->”expression
Let and Where Expressions The syntax of let and where expressions is given by the
following grammar:
let-expression → let “{”let-clauses “}”in expression
where-expression → expression where “{”let-clauses “}”
let-clauses → let-clause+-“;”
let-clause → pattern “=”expression
168 AP
ˆ
ENDICE A. THE SYNTAX OF NOTUS
Function Update The syntax for function update is given by the following grammar:
fun-update-expression → primary-expression update-clause
update-clause → “[”expression “←” expression “ ]”
Syntax of Conditional Expressions
if-expression → if expression then expression else expression
case-expression → case expression of “{”case-clauses “}”
case-clauses → case-clause+-“;”
case-clause → pattern “=>”expression
A.9 Transformation Clauses
The syntax for transformation clauses is given by the following grammar:
transf-section → signature signature-clause+-“,”“;”
| default default-clause+-“,”“;”
| replace replace-clause+-“,”“;”
| redefine redefine-clause+-“,”“;”
signature-clause → function-name “:” labelled-domain
labelled-domain → l-d-constituent+-“->”
l-d-constituent → domain
| label “:”domain
default-clause → label within-cons* “=” expression
replace-clause → function-application-pattern by expression
redefine-clause → function-header-pattern within-cons* by expression
function-application-pattern → function-name pattern*
function-header-pattern → function-name pattern*
within-cons → within function-header-pattern
Apˆendice B
Examples of Language Definitions in
Notus
B.1 Example of Syntax Definition: Language Nano
This section presents an example defining the syntax of Nano, a simple language containing
expressions and commands. A program in Nano is a sequence of readings of values to
variables, followed by the execution of a command, and finalized with the writing of the
value of an expression. Commands in Nano are assignment, conditional, and repetition.
Expressions in Nano are numbers, boolean literals true and false, arithmetic, relational,
and logical operations.
B.1.1 Language Definition
Kernel Module Kernel in Listing B.1 defines white spaces and comments to be ignored
by the lexical analyzer.
1 module Nano.Kernel
2 ignore layoutchar | comment ;
3 element layoutchar = ” ” | ”\n” | ”\t” | ”\r” | ”\f” ;
4 element comment = ”//” .∗ ;
Listagem B.1: Module Kernel of Nano Definition
169
170 AP
ˆ
ENDICE B. EXAMPLES OF LANGUAGE DEFINITIONS IN NOTUS
Expressions Module Expressions in Listing B.2 defines all issues concerning expressions,
namely syntactic domains, tokens, variables, and concrete grammar rules. This module
exports the domains Exp, Id, and Value; the tokens id, num, bool; and the variable exp.
Commands Module Commands in Listing B.3 defines all issues c oncerning commands,
namely public syntactic domain Comm, public variable comm, and the concrete gram-
mar rules for assignment, conditional, repetition, and block. This module imports public
identifiers from Expressions.
Programs Module Programs in Listing B.4 defines public syntactic domain Prog, public
variable prog, and the concrete grammar rule for programs. The startsymbol clause in its
header defines that prog is the start symbol of the concrete grammar of Nano. Besides,
modules Expressions, Commands, and Kernel must be imported.
Main Module The main module of this specification (in Listing B.5) just defines the
start symbol of the grammar to be non-terminal prog.
B.1.2 Lexis of Nano
The lexis of Nano comprehends:
• token id in domain Id, w hose lexeme is a string;
• token num in domain Value, whose lexeme is a integral number;
• token bool in domain Value, whose lexeme is a boolean value;
• keywords “or”, “and”, “not”, “if”, “then”, “else”, “while”, “do”, “begin”, “end”,
“read”, “write”;
• operators “+”, “-”, “*”, “/”;
• delimiters: “(”, “)”, and “;”.
Besides, white spaces and comments are defined and are ignored by the lexical analyzer.
B.1. EXAMPLE OF SYNTAX DEFINITION: LANGUAGE NANO 171
1 module Nano.Expressions
2
3 public token id = $[a−zA−Z ]$[a−zA−Z0−9 ]∗;
4 token num : Value = [0−9]+ is asInteger;
5 token bool : Value = ”true” | ”false” is asBoolean;
6
7 public exp ::= exp ”or” andexp
8 | andexp : andexp;
9
10 andexp : Exp ::= andexp ”and” addexp
11 | addexp : addexp;
12
13 addexp : Exp ::= addexp ”+” multexp
14 | addexp ”−” multexp
15 | multexp : multexp;
16
17 multexp : Exp ::= multexp ”∗” unexp
18 | multexp ”/” unexp
19 | unexp : unexp;
20
21 unexp : Exp ::= ”not” primary
22 | ”−” primary;
23
24 primary : Exp ::= ”(” exp ”)” : exp
25 | id
26 | value;
27
28 value ::= bool
29 | num;
Listagem B.2: Module Expressions of Nano Definition
172 AP
ˆ
ENDICE B. EXAMPLES OF LANGUAGE DEFINITIONS IN NOTUS
1 module Nano.Commands
2 import Expressions, Declarations;
3
4 public comm ::= id ”:=” exp ”;” : [id ”:=” exp]
5 | ” if ” exp ”then” comm1 ”else” comm2
6 : [” ifthenelse ” exp comm1 comm2]
7 | ”while” exp ”do” comm : [”while” exp comm]
8 | ”{” decl∗ comm∗ ” }” : [decl∗ ”;” comm∗] ;
Listagem B.3: Module Commands of Nano Definition
1 module Nano.Programs
2 import Commands, Expressions, Declarations;
3
4 prog ::= ”read” id ”;” comm ”;” ”write” exp : [”prog” id comm exp];
Listagem B.4: Module Programs of Nano Definition
1 module Main
2 import Nano.Programs;
3
4 syntax prog;
Listagem B.5: Main Module of Nano Definition
B.1. EXAMPLE OF SYNTAX DEFINITION: LANGUAGE NANO 173
B.1.3 Syntax of Nano
The concrete grammar of Nano is G
C
η
= (V
C
η
, T
C
η
, R
C
η
, prog), where:
• V
C
η
= {prog, comm, exp, andexp, addexp, multexp, unexp, primary, value};
• T
C
η
is the set of tokens defined in Section B.1.2.
• R
C
η
is a set containing rules:
prog → "read" id “;”comm “;”"write" exp
comm → id ":=" exp
| "if" exp "then" comm1 "else" comm2
| "while" exp "do" comm
| "begin" comm+-“;”"end"
exp → exp "or" andexp
| andexp
andexp → andexp "and" addexp
| addexp
addexp → addexp “+”multexp
| addexp “-”multexp
| multexp
multexp → multexp “*”unexp
| multexp "/" unexp
| unexp
unexp → "not" primary
| “-”primary
primary → “(”exp “)”
| id
| value
value → bool
| num
B.1.4 Abstract Grammar of Nano
The abstract grammar of Nano is G
A
η
= (V
A
η
, T
A
η
, R
A
η
, Prog), where:
• V
A
η
= {Prog, Comm, Exp, Id, Value}, which contains all syntactic domains defined
in the modules of Nano specification;
174 AP
ˆ
ENDICE B. EXAMPLES OF LANGUAGE DEFINITIONS IN NOTUS
• T
A
η
is the set containing:
– tokens id, num, and bool;
– keywords “or”, “and”, “not”, “if”, “then”, “else”, “while”, “do”, “prog”;
– operators “+”, “-”, “*”, “/”.
• R
A
η
is a set containing rules:
Prog → "prog" Id Comm Exp
Comm → Id ":=" Exp
| "if" Exp "then" Comm "else" Comm
| "while" Exp "do" Comm
| Comm+
Exp → Exp "or" Exp
| Exp "and" Exp
| Exp “+”Exp
| Exp “-”Exp
| Exp “*”Exp
| Exp "/" Exp
| "not" Exp
| “-”Exp
| Exp
| Id
| bool
| num
Value → bool
| num
Id → id
Grammar G
A
η
may be simplified by Algorithms I and II described in Section C.2, to produce
G
A
η
= (V
A
η
, T
A
η
, R
A
η
, Prog), where:
• V
A
η
= {Prog, Comm, Exp, Id, }, which contains all syntactic domains defined in the
modules of Nano specification;
• T
A
η
is the set containing:
– tokens id, num, and bool;
– keywords “or”, “and”, “not”, “if”, “then”, “else”, “while”, “do”, “prog”;
B.1. EXAMPLE OF SYNTAX DEFINITION: LANGUAGE NANO 175
– operators “+”, “-”, “*”, “/”.
• R
A
η
is a set containing rules:
Prog → "prog" Id Comm Exp
Comm → Id ":=" Exp
| "if" Exp "then" Comm "else" Comm
| "while" Exp "do" Comm
| Comm+
Exp → Exp "or" Exp
| Exp "and" Exp
| Exp “+”Exp
| Exp “-”Exp
| Exp “*”Exp
| Exp "/" Exp
| "not" Exp
| “-”Exp
| Id
| bool
| num
Id → id
B.1.5 Domains of Nano
The domains of Nano are Id, Value, Exp, Comm, and Progs, which are defined from the
abstract grammar G
A
η
and token definitions by:
• Id = L ([a-zA-Z ][a-zA-Z0-9 ]*);
• Value = Int + Bool;
• Exp = Id + Value
+ ({“-”} × Exp × Exp) + ({“not”} × Exp × Exp)
+ (Exp × {“+”} × Exp) + (Exp × {“-”} × Exp)
+ (Exp × {“*”} × Exp) + (Exp × {“/”} × Exp);
• Comm = (Id × {“:=”} × Exp) + ({“while”} × Exp × ×Comm)
+ Comm
+
+ ({“ifthenelse”} × Exp × Comm × Comm);
• Prog = {“prog”} × Id × Comm × Exp.
176 AP
ˆ
ENDICE B. EXAMPLES OF LANGUAGE DEFINITIONS IN NOTUS
1 module Sek.Kernel
2 element layoutchar = ” ” | ”\n” | ”\t” | ”\r” | ”\f” ;
3 element comment = ”//” .∗ ;
4 ignore layoutchar | comment
5
6 Value = Int | Int∗
7 Ans = {stop,error} | Ans(Value,Ans)
Listagem B.6: Definition of the Kernel of Sek
B.2 Example of Semantics Definition: Language Sek
Sek is an imperative language for manipulating of sequences of integer numbers, with
assignment and printing.
B.2.1 Kernel Language
In Sek, blank symbols and comments are ignored. A comment start with two slashes (//)
and goes until the end of the line. Values in Sek are integer numbers and sequences of
integers.
Listing B.6 is the definition of a core Sek language. This module defines that blank symbols
and comments are ignored by means of a ignore clause, and defines the semantic domain
Value, which represents the values of Sek.
B.2.2 Memory Abstraction
Memory in Sek is a mapping from locations to values, which can be integer numbers and
sequences of locations. There is a special position in the memory, named counter, which
represents the next memory cell that can be allocated. Expressible values are integer
numbers, locations, sequences of integers, and sequences of locations. Functions assign,
deref , cont, ref , and new are used for memory manipulation.
B.2. EXAMPLE OF SEMANTICS DEFINITION: LANGUAGE SEK 177
1 module Sek.Memory
2 import Kernel
3
4 Loc = private ({location},Int)
5 Sv = Int | Loc∗
6 Ev = Int | Loc | Int∗ | Loc∗
7
8 State = (Loc | {counter}) −> (Sv | {unused})
9 Cc = State −> Ans
10 Ec = Ev −> Cc
11
12 // assign: assigns a value to a location
13 function assign : Loc −> Cc −> Sv −> Cc
14 assign loc cc sv state = cc state[ loc <− value]
15
16 // Dereference a value if it is a location or passes its
17 // value to t he continuation otherwise
18 function deref : Ec −> Ec
19 deref ec loc = cont ec lo c
20 deref ec ev = ec ev
21
22 // Gives the content of a memory cell
23 function cont : Ec −> Loc −> Cc
24 cont ec loc state = let sv = state loc in ec sv
25
26 // Creates a reference to a value
27 function ref : Ec −> Ec
28 ref ec ev = evaluate new; \loc −> assign loc (ec loc) ev
29
30 // Allocs a new location in memory
31 function new : Ec −> Cc
32 new ec state = let Loc(location, int) = state counter
33 in ec loc state [counter <− Loc(location,int+1)]
Listagem B.7: Definition of Sek Memory
178 AP
ˆ
ENDICE B. EXAMPLES OF LANGUAGE DEFINITIONS IN NOTUS
1 module Sek.Variables
2 import Kernel, Memory
3
4 token v = [A−Z] is asCharacter // sequence variables
5 Var = Char
6 Env = Var −> (Loc | {unbound})
Listagem B.8: Definition of Variables in Sek
B.2.3 Variables
Variables in Sek are single uppercase characters. The environment maps variables into
locations or the special value unbound, which denotes that a variable is not bound in the
environment.
B.2.4 Declarations
Variable declarations are a sequence of uppercase characters preceeded by the keyword
var and separated by commas. Each variable can be listed only once. Function dd is
the denotation of declarations and produces an environment binding variables to memory
locations.
B.2.5 Basic Expressions
The simplest form of expression is a number, which is just a sequence of digits interpreted
as an integer. Function de is the denotation of expressions. The denotation of an integer
number is the number itself. Function dr is the denotation of right-values and simply tests
whether a value is a location, dereferencing the location if necessary.
B.2.6 Commands
The commands in Sek are assignment and printing. Function dc is the denotation of
commands.
The left-hand side of assignments may be sequence names, w hich must be declared varia-
bles. The denotation of the assignment is the evaluation of its left-hand side, which must
B.2. EXAMPLE OF SEMANTICS DEFINITION: LANGUAGE SEK 179
1 module Sek.Declarations
2 import Memory, Variables
3
4 // Variable declarations are preceeded by the keyword ”var”
5 // and separated by commas
6 vars : Var∗ ::= ”var” v+”,” : v+
7
8 Dc = Env −> Cc // Continuation of declarations
9
10 // Denotation of Declarations
11 function dd : Var∗ −> Env −> Dc −> Cc
12 dd env <> dc = dc env
13 dd env var:var∗ dc =
14 let cc1 = \state −> error
15 in case env var of
16 unb ound => eval uate new; \loc −> dc env[var <− loc]
17 => cc1
Listagem B.9: Definition of Declarations in Sek
produce a location where the value of the right-hand side is stored. Function dl denotes
left-values.
For printing commands the expression to be printed is evaluated as a right-value and its
value is appended before the output.
B.2.7 Sequences
Sequences in Sek are lists of integers which are represented as sequences of locations in the
memory, so that it is possible to update individual positions. Indexed variables are sequence
variables followed by an integer number representing its index. Functions asIndexed,
seqelem, locseq, subseq, start seq, and finish seq are defined in module SeqAuxiliary in
Listing B.12.
A sequence expression may be an aggregate, which is a sequence of values separated by
commas and enclosed in <>, or a subsequence of a given sequence limited by its lower
and upper index in the original sequence. Indexed variables may be used as values and as
assignments left-hand s ides.
180 AP
ˆ
ENDICE B. EXAMPLES OF LANGUAGE DEFINITIONS IN NOTUS
1 module Sek.Expressions
2 import Kernel, Variables, Memory
3
4 token n : E = [0−9]+ is asInteger // numbers
5
6 e ::= val : val // Expressions are values
7 val : E ::= n // Values are numbers
8
9 // DENOTATION OF EXPRESSIONS
10 function de : E −> Env −> Ec −> Cc
11
12 // Numbers are just passed to the continuation
13 de int env ec = ec n
14
15 // DENOTATION OF RIGHT−VALUES
16 function dr : E −> Env −> Ec −> Cc
17
18 // if an expression in rhs is a location then it is dereferenced
19 dr e env ec = evaluate de e env; deref ec
Listagem B.10: Definition of Expressions in Sek
B.2. EXAMPLE OF SEMANTICS DEFINITION: LANGUAGE SEK 181
1 module Sek.Comma nds
2 import Variables, Expressions, Memory
3
4 // Commands are assignment and printing
5 c ::= lhs ”=” e | ”print” e
6
7 // Denotation of Commands
8 function dc : C −> Dc −> Cc
9
10 // Left−hand sides are sequence names
11 lhs : E ::= s
12
13 // Assignment: assigns the value of e2 to the location defi ned by e1
14 dc [e1 ”=” e2] env cc = evaluate dl e1 env
15 \loc −> dr e2 env
16 assign loc cc
17
18 // Printing: preppends the value of e in the output
19 dc [”print ” e] env dc = evaluate dr e env; print; dc env
20
21 // Sequence names must be bound to locations in the environment
22 de s env ec = let loc = env s in loc
23
24 // DENOTATION OF LEFT−VALUES
25 function dl : E −> Env −> Ec −> Cc
26
27 // expression in lhs must be a location and it is checked in
28 // the pattern matching in lambda abstraction
29 dl e env ec = evaluate de e env; \loc −> ec loc
30
31 // preppends a value in the output
32 function print : Ev −> Cc −> Cc
33 print int cc state = (int, cc state)
Listagem B.11: Definition of Commands in Sek
182 AP
ˆ
ENDICE B. EXAMPLES OF LANGUAGE DEFINITIONS IN NOTUS
1 module Sek.SeqAuxiliary
2
3 Indexed = (Char,Int)
4 // asIndexed: separates identifier name and index from token i
5 function asIndexed: String −> Indexed
6 asIndexed c:s = Indexed(c,asInteger s)
7
8 function seqelem : Loc −> Int −> Ec −> Cc
9 seqelement loc: 0 ec = ec loc
10 seqelement :loc∗ int = seqelem loc∗ (int − 1)
11
12 // Appends a location to a location list
13 function locseq : Ec −> Loc −> Loc∗ −> Cc
14 locseq ec loc loc∗ = ec (loc: loc∗)
15
16 // Subsequence by index
17 function subseq : Loc∗ −> Int −> Ec −> Int −> Cc
18 subseq loc∗ int1 ec int2 =
19 if lt int1 0 then err
20 elseif lt int2 int1 then err
21 else start seq loc∗ int1 ec int2
22
23 // Finds the start of the subsequence
24 private function start seq : Loc∗ −> Int −> Ec −> Int −> Cc
25 start seq <> 0 ec int2 = finish seq <> ec int2
26 start seq <> int1 ec int2 = err
27 start seq loc∗ 0 ec int2 = finish seq loc∗ ec int2
28 start seq loc : loc∗ int1 ec int2 = start seq loc∗ (int1 − 1) ec (int2 − 1)
29
30 // Finds the end of the subsequence
31 private function finish seq : Loc∗ −> Ec −> Int −> Cc
32 finish seq <> ec 0 = ec <>
33 finish seq <> ec int = err
34 finish seq loc : loc∗ ec int = finish seq loc∗ ec1 ( int − 1)
35 where ec1 = \loc∗ −> ec (loc:loc∗)
Listagem B.12: Definition of Sequence Expressions in Sek
B.2. EXAMPLE OF SEMANTICS DEFINITION: LANGUAGE SEK 183
The denotation of a sequence aggregate is the evaluation of each element, and store each
value in independent positions of the memory; the sequence is then a reference to the list
of locations in the memory.
The denotation of a subsequence is the evaluation of its limiting indices and the extraction
of a sequence of locations containing the elements of the original list. This sequence of
location is stored in a new memory cell, but no new cell is allocated for each elements in
the subsequence, and thus they are alias to the elements in the original list.
The denotation of a sequence element is a value stored in the sequence in the given position.
Positions in se quences start in zero.
B.2.8 Programs
A program in Sek is a sequence of variable declarations followed by a sequence of com-
mands. The denotation of a program is the sequential execution of each c ommand in the
environment produced by the evaluation of the variable declarations. After the execution
of all commands, the execution stops.
B.2.9 Main Module
The main module defines the start symbol of the language’s grammar, the s emantic function
for programs, and input and output streams.
184 AP
ˆ
ENDICE B. EXAMPLES OF LANGUAGE DEFINITIONS IN NOTUS
1 module Sek.Sequences
2 import Memory, Expressions, Variables, Kernel, SeqAuxiliary
3
4 token i = [A−Z][0−9]+ is asIndexed // indexed sequence elements
5
6 // Expressions may be sequences
7 extend e with seq : seq
8
9 // Sequences are lists of values in <> or
10 // subsequences defin ed by sequence and boundaries
11 seq: E ::= ”<” val∗−”,” ”>” : [”<” val∗ ”>”]
12 | v ”[” val ”.. ” val ”]”
13
14 // Values may be sequence elements
15 extend val with i
16 // Left−hand sides may be indexed elements
17 extend lhs with i
18
19 // Sequences of values
20 de [”<” e∗ ”>”] env ec = dseq e∗ env; ref ec
21
22 // Subsequences
23 de [s ”[” e1 ” ..” e2 ”]”] env ec =
24 eval uate dr s env; \loc∗ −> dr e1 env;
25 \int1 −> dr e2 env;
26 subseq loc∗ int1; ref ec
27
28 // Sequence elements are checked if the sequence exists in the environment, and
29 // then the corresponding location in the sequence is passed to the continuation
30 de Indexed(char,int ) env ec = let loc = env char
31 in seqelement loc int ec
32
33 // DENOTATION OF SEQUENCES
34 function dseq : E∗ −> Env −> Ec −> Cc
35 dseq <> env ec = ec <>
36 dseq e:e∗ env ec = evaluate dr e env; ref;
37 \loc −> dseq e∗ env;
38 locseq ec loc
Listagem B.13: Definition of Sequence Expressions in Sek
B.2. EXAMPLE OF SEMANTICS DEFINITION: LANGUAGE SEK 185
1 module Sek.Programs
2 import Declarations, Commands
3
4 // a program is a declaration of variables
5 // followed by a sequence of commands
6 public p ::= vars c∗
7
8 // Denotation of Programs
9 public function dp : P −> Ans
10 dp [var∗ c∗] =
11 let env0 = \char −> unbound
12 state0 = \loc −> unused
13 cc0 = \state −> stop
14 dc0 = \env −> dcs c∗ env cc0
15 in dd var∗ env0 dc0 state0
16
17 // Denotation of Command Sequences
18 function dcs : C∗ −> Dc −> Cc
19 dcs <> cc = stop
20 dcs c:c∗ env = evaluate dc c env; dcs c∗ env cc
Listagem B.14: Definition of Programs in Sek
1 module Main
2 import Sek.Programs
3
4 syntax p // p is the start symbol of the grammar of Sek
5
6 semantics dp // dp is the evaluation function of Sek
7
8 input stdin
9
10 output stdout
Listagem B.15: Main Module of Sek Definition
186 AP
ˆ
ENDICE B. EXAMPLES OF LANGUAGE DEFINITIONS IN NOTUS
B.3 Example of Incremental Definition: Language Tiny
B.3.1 Introduction
Consider Tiny is a programming language containing expressions, commands, variable
declarations, and sequencers break and continue. This section shows the incremental defi-
nition of Tiny using Notus. This language is defined in two specification, so that the first
specification (Tiny0) defines all constructs but the sequencers, which are defined in the
second specification (Tiny1).
B.3.2 Initial Specification
The initial specification defines all constructs but the sequencers break and continue, which
will be defined in the second specification.
B.3.2.1 Kernel
The first module in the description of Tiny is Kernel (Listing B.16, page 187), which defines
that comments and white spaces must be ignored. It also defines identifiers, semantic
domains, and auxiliary functions to manipulate memory.
B.3.2.2 Expressions
The simplest constructs of Tiny consists of expressions involving integral numbers and
boolean values. Numbers consist of any non-empty sequence of digits from 0 to 9, and
boolean values are true and false.
Operators are divided into three categories: (i) arithmetic: +, unary and binary -, *,
div, and mod; (ii) comparative: =, !=, <, >, <=, and >=; (iii) logical: not, and, and or.
Precedence and associativity are defined in Table B.1, and parenthesis can be used to cast
precedence. Values and operators have the usual meaning.
Modules Expressions, Arithmetics, Relationals, and Booleans define lexis, syntax, and
semantics of these features.
B.3. EXAMPLE OF INCREMENTAL DEFINITION: LANGUAGE TINY 187
1 module Bas ics.Kernel
2
3 ignore layoutchar | comment ;
4
5 element layoutchar = ” ” | ”\n” | ”\t” | ”\r” | ”\f” ;
6 element comment = ”//” .∗ ;
7
8 public syntactic Id ;
9 public token id : Id = [A−Za−z]([A−Za−z]|[0−9])∗ ;
10
11 public Loc = ({location},Int);
12 public Val = Int | Bool | Loc ;
13
14 public Store = Loc −> (Val | {unused}) ;
15 public Env = Id −> (Loc | {unbound}) ;
16
17 public Ans = String ;
18
19 public Cc = State −> Ans ;
20 public Ec = Val −> Cc ;
21 public Dc = Env −> Cc ;
22
23 // assigns a value to a location
24 function assign : Loc −> Cc −> Val −> Cc ;
25 // dereference a value if it is a location or passes its
26 // value to t he continuation otherwise
27 function deref : Ec −> Ec ;
28 // gives the content of a memory cell
29 function cont : Ec −> Loc −> Cc ;
30 // creates a reference to a value
31 function ref : Ec −> Ec ;
32 // allocs a new location in memory
33 function new : Ec −> Cc ;
34 // issues an error message
35 function err : Cc ;
Listagem B.16: Module Kernel in the Definition of Tiny
188 AP
ˆ
ENDICE B. EXAMPLES OF LANGUAGE DEFINITIONS IN NOTUS
Operator Precedence Associativity
not, unary - highest precedence right
*, div, mod left
+, binary - left
<, >, <=, >= none
=, != none
and left
or lowest precedence left
Tabela B.1: Precedence and Associativity in Tiny
1 module Bas ics.Expressions
2
3 import Kernel ;
4
5 // Syntactic domain of expressions
6 public syntactic Exp ;
7
8 // Denotation of expressions
9 public de : Exp −> Env −> Ec −> Cc ;
Listagem B.17: Module Expressions in Tiny Definition
B.3.2.3 Module Expressions
Module Expressions (Listing B.17, page 188) defines: (i) the initially empty syntactic
domain Exp, which represents syntax of expressions; (ii) the semantic function for expres-
sions, de. These elements are initially set to empty in order to represent only the interface
necessary to define new expression constructs.
B.3.2.4 Module Arithmetics
Module Arithmetics (Listing B.18, page 190) defines syntax and semantics of expressions
involving numbers. In the lexical part, token num is defined as a sequence of digits, and
since it may be necessary in other modules it is de clared public. Since num is a token it
is automatically included in the lexis definition. In addition, variable digit is defined to be
private to the module because it is auxiliary in the definition of token num.
B.3. EXAMPLE OF INCREMENTAL DEFINITION: LANGUAGE TINY 189
New forms of expressions are defined in the language by adding new syntactic clauses having
syntactic domain Exp as left-hand side. Furthermore, each concrete grammar production
is associated with some abstract grammar rule.
Besides, using symbols "+", "-", "*", "div", "mod", "(", and ")" in the syntactic clauses
indicates they are tokens of the language and therefore must be automatically included in
the lexis of the language.
Furthermore, the semantics of each new construct is defined as new definition of function
de.
B.3.2.5 Module Relationals
Module Relationals (Listing B.19, page 191) initially extends the concrete grammar of Tiny
to contain new production rules corresponding to relational operations. These inclusions
cause the extension of domain Exp and the inclusion of tokens "=", "!=", "<", ">", "<=",
and ">=" in the lexis of the language.
B.3.2.6 Module Booleans
Module Booleans (Listing B.20, page 192) initially defines token bool to represent boo-
lean constants, and new syntactic clauses to boolean operations, by defining rules having
syntactic domain Exp as left-hand side, and their denotations by extending function de.
B.3.2.7 Commands
Module Commands (Listing B.21, page 193) defines syntactic domain Comm to represent
commands and semantic function dc to compute their denotations.
B.3.2.8 Declarations
Module Declarations (Listing B.22, page 193) defines syntactic domain Decl, to repre-
sent declarations, grammar rules for variable declaration and declaration sequences, and
semantic function dd for declarations.
190 AP
ˆ
ENDICE B. EXAMPLES OF LANGUAGE DEFINITIONS IN NOTUS
1 module Bas ics.Arithmetics
2
3 import Expressions, Kernel;
4
5 public token num : Num ::= digit+ is asInteger ; // defines numbers
6 digit ::= [0−9] ;
7
8 addexp : Exp ::=
9 addexp ”+” multexp | addexp ”−” multexp
10 | multexp;
11
12 multexp : Exp ::=
13 multexp ”∗” unary | multexp ”div” unary | multexp ”mod” unary
14 | unary;
15
16 unary : Exp ::=
17 ”−” primary | primary;
18
19 primary ::=
20 ”(” exp ”)” : exp | num ;
21
22 de [num] env ec = ec num;
23
24 de [”−” exp] env ec = de exp env (\int −> ec (−int))
25
26 de [exp1 ”+” exp2] env ec =
27 de exp1 env (\int1 −> de exp2 env (\int2 −> ec (int1 + int2))) ;
28
29 de [exp1 ”−” exp2] env ec =
30 de exp1 env (\int1 −> de exp2 env (\int2 −> ec (int1 − int2))) ;
31
32 de [exp1 ”∗” exp2] env ec =
33 de exp1 env (\int1 −> de exp2 env (\int2 −> ec (int1 ∗ int2))) ;
34
35 de [exp1 ”div” exp2] env ec =
36 de exp1 env (\int1 −> de exp2 env (
37 \int2 −> if int2 == 0 then err else ec (int1 / int2 ))) ;
38
39 de [exp1 ”mod” exp2] env ec =
40 de exp1 env (\int1 −> de exp2 env (
41 \int2 −> if int2 == 0 then err else ec (int1 mod int2))) ;
Listagem B.18: Module Arithmetics in Tiny Definition
B.3. EXAMPLE OF INCREMENTAL DEFINITION: LANGUAGE TINY 191
1 module Bas ics.Re lationals
2
3 import Kernel, Expressions, Arithmetics;
4
5 eqexp ::=
6 ineqexp ”==” ineqexp
7 | ineqexp ”’=” ineqexp
8 | ineqexp ;
9
10 ineqexp ::=
11 addexp ”<” addexp
12 | addexp ”>” addexp
13 | addexp ”<=” addexp
14 | addexp ”>=” addexp
15 | addexp ;
16
17 de [exp1 ”==” exp2] env ec =
18 de exp1 env (\int1 −> de exp2 env (\int2 −> ec (int1 == int2))) ;
19
20 de [exp1 ”’=” exp2] env ec =
21 de exp1 env (\int1 −> de exp2 env (\int2 −> ec (int1 ’= int2))) ;
22
23 de [exp1 ”<” exp2] env ec =
24 de exp1 env (\int1 −> de exp2 env (\int2 −> ec (int1 < int2))) ;
25
26 de [exp1 ”>” exp2] env ec =
27 de exp1 env (\int1 −> de exp2 env (\int2 −> ec (int1 > int2))) ;
28
29 de [exp1 ”<=” exp2] env ec =
30 de exp1 env (\int1 −> de exp2 env (\int2 −> ec (int1 <= int2))) ;
31
32 de [exp1 ”>=” exp2] env ec =
33 de exp1 env (\int1 −> de exp2 env (\int2 −> ec (int1 >= int2))) ;
Listagem B.19: Module Relationals in Tiny Definition
192 AP
ˆ
ENDICE B. EXAMPLES OF LANGUAGE DEFINITIONS IN NOTUS
1 module Bas ics.B ooleans
2
3 import Kernel, Expressions, Arithmetics, Relationals;
4
5 token bool : Bool ::= ”true” | ”false ” is asBoolean ; // defines numbers
6
7 extend primary with bool ;
8
9 exp : Exp ::=
10 exp ”or” andexp
11 | andexp ;
12
13 andexp : Exp ::=
14 andexp ”and” eqexp
15 | eqexp ;
16
17 extend unary with ”not” exp ;
18
19 de [bool] env ec = ec bool;
20
21 de [”not” exp] env ec = de exp env (\bool −> ec (˜ bool))
22
23 de [exp1 ”and” exp2] env ec =
24 de exp1 env (
25 \bool1 −> case bool1 of
26 true => de exp2 env ec
27 false => ec false
28 ) ;
29
30 de [exp1 ”or” exp2] env ec =
31 de exp1 env (
32 \bool1 −> case bool1 of
33 false => de exp2 env ec
34 true => ec true
35 ) ;
Listagem B.20: Module Booleans in T iny Definition
B.3. EXAMPLE OF INCREMENTAL DEFINITION: LANGUAGE TINY 193
1 module Bas ics.Com mands
2
3 import Kernel, Expressions ;
4
5 public syntactic Comm ;
6
7 public function dc : Comm −> Env −> Cc −> Cc ;
Listagem B.21: Module Commands in Tiny Specification
1 module Bas ics.De clarations
2
3 import Kernel, Expressions ;
4
5 public syntactic Decl ;
6
7 public decl : Decl ::=
8 ”var” id ”;” : [”var” id]
9 | decl∗ ;
10
11 public function dd : Decl −> Env −> Dc −> Cc ;
Listagem B.22: Module Declarations in Tiny Definition
194 AP
ˆ
ENDICE B. EXAMPLES OF LANGUAGE DEFINITIONS IN NOTUS
1 module Bas ics.InputOutput
2
3 import Kernel, Commands;
4
5 extend Loc with {input,output} ;
6 extend Val with String ;
7
8 function read :: Ec −> Cc ;
9 function write :: Cc −> Val −> Cc ;
10
11 extend comm with ”write” exp;
12 extend exp with ”read” ;
13
14 de [”read”] env ec = read ec ;
15
16 dc [”write” exp] env cc = de exp env (write cc) ;
Listagem B.23: Module InputOutput in Tiny Definition
B.3.2.9 Input and Output
Module InputOutput (Listing B.23, page 194) initially extends domain Loc to allow input
and output sequences be stored in the memory; also, domain Val is extended to contain
strings, which represent input and output streams. Auxiliary functions to read and write
values are defined. The syntactic domain of commands is extended to include writing, and
the syntactic domain of expressions is extended to include reading. The semantics of both
constructs are given by defining new clauses of functions dc and de.
B.3.2.10 Variables and Assignment
Module Variables (Listing B.24, page 195) defines identifiers as expression by extending
grammar variable primary. Then, the rule for commands is extended to include assignment
statement. The semantics for declarations, identifier expression, and assignment are given
by defining new clauses in functions dd, de, and dc.
B.3. EXAMPLE OF INCREMENTAL DEFINITION: LANGUAGE TINY 195
1 module Bas ics.Variables
2
3 import Declarations, Expressions, Commands, Kernel ;
4
5 extend primary with id ;
6
7 extend comm with id ”:=” exp ”;” : [id ”:=” exp] ;
8
9 dd [”var” id] env dc =
10 new (\loc −> dc (env[id <− loc])) ;
11
12 dd [decl∗] env dc =
13 case decl∗ of
14 () => dc ;
15 decl’ :: decl∗’ => dd decl’ en v ( \env’ −> dd decl∗’ env’ dc)
16
17 de [id ] env ec =
18 case env id of
19 unb ound => err
20 loc => deref ec loc
21
22 dc [id ”:=” exp] env cc =
23 case env id of
24 unb ound => err
25 loc => de exp e nv (assign loc cc)
Listagem B.24: Module Variables in Tiny Definition
196 AP
ˆ
ENDICE B. EXAMPLES OF LANGUAGE DEFINITIONS IN NOTUS
B.3.2.11 Control Flow
Module ControlFlow (Listing B.25, page 197) defines syntax and semantics for conditi-
onal, repetition, and blocks. Auxiliary function dcs is used to iterate over sequences of
commands.
B.3.2.12 Programs
Module Programs (Listing B.26, page 198) defines syntax and semantics for programs,
which consist of commands. Semantic function dp executes the command corresponding
to a program in an empty environment, an store which only maps input to the input stream
and output to an empty sequence, and in a continuation, for which, given a final store,
returns the sequence associated with the output location.
B.3.2.13 Main Module
Module Main (Listing B.27, page 198) defines the start symbol of the grammar to be prog,
the semantic f unction to be dp, and uses s tandard input and output.
B.3.3 Specification Tiny1
B.3.3.1 Main Module
Module Main of specification Tiny1 (Listing B.28, page 198) is an extension module, which
applies transformation IncludeSequencers to specification Tiny0.
B.3.3.2 Transformer Mo dule
Transformer IncludeSequencer (Listing B.29, page 199) decorates the semantics of com-
mands inside semantic equation for while, by indicating in the environment the continua-
tions for break and continue.
B.3. EXAMPLE OF INCREMENTAL DEFINITION: LANGUAGE TINY 197
1 module Bas ics.ControlFlow
2
3 import Kernel, Expressions, Declarations, Commands ;
4
5 public comm : Comm ::=
6 ”if” exp ”then” comm1 ”else” comm2
7 | ”while” exp ”do” comm
8 | ”begin” decl comm∗ ”end” ;
9
10 dc [”if” exp ”then” comm1 ”else” comm2] env cc =
11 de exp env (\b ool −>
12 case bool of true => dc comm1 env cc
13 false => dc comm2 env cc
14 ) ;
15
16 dc [”while” exp ”do” comm] env =
17 fix (\f cc −> de exp env (\bool −>
18 case bool of true => dc comm env (f cc)
19 false => cc
20 )) ;
21
22 dc [”begin” decl comm∗ ”end”] env cc =
23 dd decl env (\env’ −> dcs comm∗ env’ cc) ;
24
25 function dcs : Comm∗ −> Env −> Cc −> Cc ;
26 dcs () env cc = cc
27 dcs comm:comm∗ env cc =
28 dc comm e nv (dcs comm∗ env cc) ;
Listagem B.25: Module ControlFlow in Tiny Definition
198 AP
ˆ
ENDICE B. EXAMPLES OF LANGUAGE DEFINITIONS IN NOTUS
1 module Programs
2
3 import Kernel, Commands;
4
5 public syntactic Prog;
6
7 public prog : Prog ::= comm ;
8
9 public dp : Prog −> String −> String ;
10
11 dp [comm] string =
12 string ’ where store = dc comm env0 cc0 store0
13 string ’ = store output
14 env0 = \id −> unb ound
15 cc0 = \store −> store output
16 store0 = (\loc −> unused)[input <− string, output <− ””];
Listagem B.26: Module Programs in Tiny Definition
1 module Main
2
3 import Kernel, AuxiliaryImplementations, Programs;
4
5 syntax prog;
6 semantics dp;
7 input stdin;
8 output stdout;
Listagem B.27: Main Module of Spe cification Tiny0
1 extension IncludeSequencer(Tiny0)
2 contains Sequencers
Listagem B.28: Main Module of Spe cification Tiny1
B.3. EXAMPLE OF INCREMENTAL DEFINITION: LANGUAGE TINY 199
1 transformation IncludeSequencer
2 import Basics.Kernel, Basic.Commands, Basic.ControlFlow,
3 Basic.Expressions, Sequencers.Sequencers ;
4
5 replace dc [com] env cc within dc [”while” exp ”do” comm] env’ cc’
6 by dc [com] (env[cc’/break,cc/continue])
Listagem B.29: Transformer IncludeSequencer
1 module Sequencers.Sequencers
2
3 import Commands, Kernel;
4
5 extend comm with ”break” | ”continue” ;
6
7 extend Id with public {break,continue}
8
9 dc [”break”] env cc = env break;
10
11 dc [”continue”] env cc = env continue;
Listagem B.30: Module Sequencers
B.3.3.3 Sequencers
Module Sequencers (Listing B.30, page 199) includes new grammar rules for sequencers
break and continue, defines special p ositions for both sequencer as identifiers, and defines
the their semantics.
200 AP
ˆ
ENDICE B. EXAMPLES OF LANGUAGE DEFINITIONS IN NOTUS
Apˆendice C
Auxiliary Algorithms
C.1 Transforming Notus Grammars into BNF
Function ζ takes a grammar G defined in Notus and produces a new grammar G
in BNF.
The auxiliary function ζ
: C → (C × 2
R
× 2
V
), where C is the set of all rule constituents,
V is the set of all grammar variables, and R is the set of all production rules
1
. Function
ζ
applied to a rule constituent α is a triple (β, R
α
, V
α
), where β is a rule constituent in
conformity with usual parser generators syntax, R
α
is a (possibly empty) set of grammar
rules which must be included in R, and V
α
is a (possibly empty) set of grammar variables
which must be inc luded in V .
Function ζ
is recursively defined as follows:
• ζ
(λ) = (λ, ∅, ∅);
• ζ
(empty) = (λ, ∅, ∅);
• ζ
(v) = (v, ∅, ∅), if v ∈ V ;
• ζ
(t) = (t, ∅, ∅), if t ∈ T ;
• ζ
(α
1
α
2
· · · α
m
) = (β
1
β
2
· · · β
m
, R
α
, V
α
), where:
– (β
i
, R
α
i
, V
α
i
) = ζ
(α
i
), for 1 ≤ i ≤ m;
1
The notation 2
A
represents the power-set of A.
201
202 AP
ˆ
ENDICE C. AUXILIARY ALGORITHMS
– R
α
=
m
i=1
R
α
i
;
– V
α
=
m
i=1
V
α
i
;
• ζ
(α*) = (v, {v → β v, v → λ} ∪ R
α
, {v} ∪ V
α
), where:
– (β, R
α
, V
α
) = ζ
(α);
– v is a new variable;
• ζ
(α+) = (v, {v → β v, v → β} ∪ R
α
, {v} ∪ V
α
), where:
– (β, R
α
, V
α
) = ζ
(α);
– v is a new variable;
• ζ
(α*-t) = (v, R
∪ R
α
, {v, v
1
} ∪ V
α
), where:
– R
= {v → v
1
, v → λ, v
1
→ β t v
1
, v
1
→ β};
– (β, R
α
, V
α
) = ζ
(α);
– v, v
1
are new variables;
• ζ
(α+-t) = (v, R
∪ R
α
, {v} ∪ V
α
), where:
– R
= {v → β t v
1
, v → β};
– (β, R
α
, V
α
) = ζ
(α);
– v is a new variable;
If G = (V, T, R, S) is a grammar, then G
= ζ(G) = (V ∪ V
, T, R
, S), where:
• V
= {v ∈ V
α
| A → α ∈ R ∧ (β, R
α
, V
α
) = ζ
(α)};
• R
= R
1
∪ R
2
, where:
– R
1
= {A → β | A → α ∈ R ∧ (β, R
α
, V
α
) = ζ
(α)};
– R
2
= {p ∈ R
α
| A → α ∈ R ∧ (β, R
α
, V
α
) = ζ
(α)}.
C.2. SIMPLIFICATION OF ABSTRACT GRAMMARS 203
For instance, consider grammar G = ({E} , {x, f, ",", "(", ")"} , R, E), where
R : E → x | f "(" E*-"," ")"
The conversion of this grammar via function ζ produces grammar
G
= ({E, v, v
1
} , {x, f, "," , "(" , ")" } , R
, E),
where
R
: E → x | f "(" v ")"
v → v
1
| λ
v
1
→ v
1
"," E | E
C.2 Simplification of Abstract Grammars
Given an abstract grammar G = (V, T, R, S), it is possible to obtain a simplified, but equi-
valent, version of G, using algorithms for elimination of unused symb ols. These algorithms
are adapted from Sipser (1996).
Algorithm I: Elimination of Variables Which Do Not Generate Strings. The
first algorithm consists of eliminating variables from which no string in T
∗
is generated.
Given a grammar G = (V, T, R, S), this algorithm initially creates a mapping m
0
: V → 2
2
V
from variables to sets of sets of variables. For each rule X → α ∈ R, {X
1
, · · · , X
k
} ∈ m
0
X,
if each X
i
appears in α.
Then function ϕ : (V → 2
2
V
) → (V → 2
2
V
) is defined as:
ϕ m v = {A − Z
m
| A ∈ m
0
v} ,
where Z
m
= {w ∈ V | ∅ ∈ m w}. From function ϕ, define a sequence of mappings M =
m
0
, m
1
, m
2
, · · · , such that m
i+1
= ϕ m
i
, for i ≥ 0. Then a new grammar equivalent to G
is given by G
= (Z
m
, T, R
, S), where:
• m = lub M , i.e the least upper bound
2
of M, and therefore a fix-point of ϕ.
• R
= {v → α ∈ R | v ∈ Z
m
∧ α ∈ (T ∪ Z
m
)
∗
};
2
The existence of m is a direct consequence from the fact that the sets are finite, and all elements in
Z
m
i
⊂ Z
m
i+1
, for all i ≥ 0.
204 AP
ˆ
ENDICE C. AUXILIARY ALGORITHMS
For instance, consider grammar G = (V, T, R, S), where V = {A, B, C, D, E, F, S}, T =
{a, b, c, d, e, f, g}, and R given by:
R : S → AbB | Cd | Df
A → Ac | d
B → Cd | Bc | A
C → De | Cf
D → Dg | Ee
E → Ce | Db | Ed
F → Cb | F ab | c
Mapping m
0
created from G, mappings m
1
and m
2
defined using function ϕ are given by:
m
0
m
1
m
2
S → {{A, B} , {C} , {D}}
A → {{A} , ∅}
B → {{C} , {B} , {A}}
C → {{D} , {C}}
D → {{D} , {E}}
E → {{C} , {D} , {E}}
F → {{C} , {F } , ∅}
S → {{B} , {C} , {D}}
A → {∅}
B → {{C} , {B} , ∅}
C → {{D} , {C}}
D → {{D} , {E}}
E → {{C} , {D} , {E}}
F → {{C} , ∅}
S → {∅, {C} , {D}}
A → {∅}
B → {{C} , ∅}
C → {{D} , {C}}
D → {{D} , {E}}
E → {{C} , {D} , {E}}
F → {{C} , ∅}
Z
m
0
= {A, F } Z
m
1
= {A, B, F } Z
m
2
= {A, B, F, S}
Since ϕ m
2
= m
2
, m = m
2
, and from this mapping, the only variables which generate
strings in T
∗
are A, B, F , and S. Then grammar G
= ({A, B, F, S} , T, R
, S), where:
R
: S → AbB
A → Ac | d
B → Bc | A
F → F ab | c
Note: terminals e, f, and g are not used in this grammar; however, it is not necessary to
eliminate them in this algorithm, since they are unreachable symbols and, for this reason,
will be eliminated in Algorithm II.
Algorithm II: Elimination of Unreachable Symbols. The second algorithm consists
of eliminating terminals and variables unreachable from the starting symbol. This problem
is solved by modelling the resulting grammar of the first algorithm, G
= (V
, T, R
, S), as
C.3. AUTOMATIC GENERATION OF ABSTRACT GRAMMARS 205
GFED@ABC
S
//
c
c
c
c
c
c
c
c
c
c
c
c
c
GFED@ABC
A
//
b
b
b
b
b
b
b
b
b
b
b
b
b
?>=<89:;
d
?>=<89:;
e
?>=<89:;
b
GFED@ABC
B
//
JJ
OO
?>=<89:;
c
GFED@ABC
f
GFED@ABC
F
__c
c
c
c
c
c
c
c
c
c
c
c
c
??
Ð
Ð
Ð
Ð
Ð
Ð
Ð
Ð
Ð
Ð
Ð
Ð
Ð
JJ
//
?>=<89:;
a
?>=<89:;
g
Figura C.1: Example of Graph Generated by Algorithm II for Grammar G
.
a directed graph H = (N, E), where N = V
∪ T , and for each n
1
, n
2
∈ N, (n
1
, n
2
) ∈ E
if n
1
∈ V
and there exists at least one rule n
1
→ αn
2
β ∈ R
, for some α, β ∈ (V
∪ T )
∗
.
From this graph, it is possible to create a new grammar G

= (V

, T

, R

, S), where:
• V

= V
∩
ˆ
Γ
+
(S), where
ˆ
Γ
+
(S) is the transitive closure of vertex S in graph H; V

represents all variables which can be present in some sentential form generated by S;
• T

= T ∩
ˆ
Γ
+
(S); this set represents all terminals which can be present in some
sentential form generated by S;
• R

= {A → α ∈ R
| A ∈ V

∧ α ∈ (V

∪ T

)
∗
∧ α = A}; this set represents all use-
ful rules of G.
For instance, consider grammar G
produced in the example for Algorithm I. Algorithm II
creates the graph shown in Figure C.1, and in this graph,
ˆ
Γ
+
(S) = {A, B, S, b, c, d}. Then,
this algorithm produces grammar G

= ({A, B, S} , {b, c, d} , R

, S), where:
R

: S → AbB
A → Ac | d
B → Bc | A
C.3 Automatic Generation of Abstract Grammars
In order to derive abstract grammar G
from a concrete grammar G, consider the auxiliary
function χ
: C → (C × 2
R
× 2
V
× 2
T
), where C is the set of all rule constituents, V is the
206 AP
ˆ
ENDICE C. AUXILIARY ALGORITHMS
set of all grammar variables, R is the set of all production rules, and T is the set of all
grammar terminals. Function χ
is recursively defined as:
• χ
(λ) = (empty , ∅, ∅, {empty });
• χ
(empty) = (empty, ∅, ∅, {empty});
• χ
(v) = (d, ∅, {d} , ∅), where d is the name of the domain of variable v;
• χ
(t) = (d, {d → t} , {d} , {t}), where d is the name of the domain of token t, if t is
defined to be in some domain;
• χ
(t) = (t, ∅, ∅, {t}), if token t is defined to be in no domain;
• χ
(α
1
α
2
· · · α
m
) = (β
1
β
2
· · · β
m
, R
α
, V
α
, T
α
), where:
– (β
i
, R
α
i
, V
α
i
, T
α
i
) = χ
(α
i
), for 1 ≤ i ≤ m
– R
α
=
m
i=1
R
α
i
; V
α
=
m
i=1
V
α
i
; T
α
=
m
i=1
T
α
i
;
• χ
(α*) = (β*, R
α
, V
α
, T
α
), where (β, R
α
, V
α
, T
α
) = χ
(α);
• χ
(α+) = (β+, R
α
, V
α
, T
α
), where (β, R
α
, V
α
, T
α
) = χ
(α);
• χ
(α*-t) = (β*, R
α
, V
α
, T
α
), where (β, R
α
, V
α
, T
α
) = χ
(α);
• χ
(α+-t) = (β+, R
α
, V
α
, T
α
), where (β, R
α
, V
α
, T
α
) = χ
(α).
The abstract grammar G
= χ(G) = (V
, T
, R
, d
S
) is defined as follows:
• T
= {t ∈ T
α
| A → α ∈ R ∧ (β, R
α
, V
α
, T
α
) = χ
(α)};
• V
= {v ∈ V
α
| A → α ∈ R ∧ (β, R
α
, V
α
, T
α
) = χ
(α)};
• R
= R
1
∪ R
2
, where:
– R
1
= {A → β | A → α ∈ R ∧ (β, R
α
, V
α
, T
α
) = χ
(α)};
– R
2
= {p ∈ R
α
| A → α ∈ R ∧ (β, R
α
, V
α
, T
α
) = χ
(α)}.
• d
S
is the domain of variable S.
Bibliografia
Aldrich, J., Open Modules: A Proposal for Modular Reasoning in Aspe ct-Oriented Pro-
gramming, Tech. rep., Carnegie Mellon, 2004.
Andrade, C. A. R., A. L. M. Santos, and P. H. M. Borba, AspectH: Uma Extens˜ao Ori-
entada a Aspectos de Haskell, in WASP - Workshop on Aspect Oriented Programming,
Bras´ılia, DF, Brazil, 2004.
AspectWerks, http://aspectwerkz.codehaus.org/, 2005,
´
Ultimo acesso: 27 de novembro de
2005.
Atkinson, C., and T. K¨uhne, Aspect-Oriented Development with Stratified Frameworks,
IEEE Software, 20 , 81–89, 2003.
Bigonha, R. S., Notas de Aulas de Semˆantica Denotacional, 2003,
´
Ultimo acesso: 27 de
novembro de 2005.
B¨orger, E., and W. Schulte, Programmer Friendly Modular Definition of the Semantics
of Java, in Formal Syntax and Semantics of Java, edited by J. Alves-Foss, vol. 533 of
Lecture Notes in Computer Science, Springer, 1998.
Boute, R., Functional Declarative Language Design and Predicate Calculus: a Practical
Approach, ACM Trans. Program. Lang. Syst., 27 , 988–1047, 2005.
Bravenboer, M., and E. Visser, Parse Table Composition. Separate Compilation and Binary
Extensibility of Grammars, in Software Language Engineering (SLE 2008), edited by
D. Gasevic and E. van Wyk, Lecture Notes in Computer Science, Springer, Toulouse,
France, 2009, (to appear).
Cardelli, L., and P. Wegner, On Understanding Types, Data Abstraction, and Poly-
morphism, ACM Comput. Surv., 17 , 471–523, 1985.
207
208 BIBLIOGRAFIA
Cenciarelli, P., A. Knapp, B. Reus, and M. Wirsing, An Event-Based Structural Opera-
tional Semantics of Multi-Threaded Java, Lecture Notes in Computer Science, 1523 ,
157–200, 1999.
Clifton, C., and G. Leavens, Observers and Assistants: A Proposal for Modular Aspect-
oriented Reasoning, in Workshop on Foundations of Aspect-Oriented Languages (FOAL),
Enschede, The Netherlands, 2002.
Coady, Y., G. Kiczales, M. Feeley, and G. Smolyn, Using AspectC to Improve the Modu-
larity of Path-specific Customization in Operating System Code, in Proceedings of the
8th European software engineering conference, pp. 88–98, ACM Press, Vienna, Austria,
2001.
Costa, M. R., Compila¸c˜ao de um C´alculo Lambda Estendido para Supercombinadores,
Master’s thesis, Universidade Federal de Minas Gerais, 2000.
Crepalde, M. A., R. S. Bigonha, and F. Tirelo, Semˆantica Multidimensional de Java, Tech.
Rep. LLP-02/2008 , Universidade Federal de Minas Gerais, 2008a.
Crepalde, M. A., R. S. Bigonha, F. Tirelo, and T. C. do A. P. Soares, Manual do Usu´ario
de Notus, Tech. Rep. LLP-01/2008 , Universidade Federal de Minas Gerais, 2008b.
de Moor, O., K. Backhouse, and S. D. Swierstra, First-class Attribute Grammars, Infor-
matica, 24 , 2000.
Dijkstra, E. W., A Discipline of Programming, Prentice Hall, Englewood Cliffs, New Jersey,
1976.
Espinosa, D. A., Semantic Lego, Ph.D. thesis, Columbia University, New York, NY, USA,
1995.
Fokkinga, M., Calculate categorically!, Formal Aspects of Computing, 4 , 673–692, 1992.
Fokkinga, M. M., and L. Meertens, Adjunctions, Tech. Rep. Memoranda Inf 94-31, Uni-
versity of Twente, Enschede, Netherlands, 1994.
Gamma, E., R. Helm, R. Johnson, and J. Vlissides, Design Patterns: Elements of Reusable
Object-Oriented Software, Addison-Wesley, 1995.
Gayo, J. E. L., Reusable Semantic Specifications of Programming Languages, in Proceedings
of the 6th Brazilian Symposium on Programming Languages, Rio de Janeiro, Brazil, 2002.
BIBLIOGRAFIA 209
Gordon, M. J. C., The Denotational Description of Programming Languages: An Intro-
duction, Springer-Verlag, 1979.
Gradecki, J. D., and N. Lesieck, Mastering AspectJ: Aspect-Oriented Programming in Java,
Wiley Publishing, Inc., 2003.
Gurevich, Y., Evolving Algebras, in IFIP 1994 World Computer Congress, edited by
B. Pehrson and I. Simon, vol. I: Technology and Foundations, pp. 423–427, Elsevier,
Amsterdam, 1994.
Gurevich, Y., Evolving Algebras 1993: Lipari Guide, in Specification and Validation
Methods, edited by E. B¨orger, pp. 9–36, Oxford University Press, 1995.
Hannemann, J., and G. Kiczales, Design Pattern Implementation in Java and aspectJ, in
Proceedings of the 17th ACM SIGPLAN Conference on Object-Oriented Programming,
Systems, Languages, and Applications, pp. 161–173, ACM Press, Seattle, Washington,
USA, 2002.
Harrison, W., and S. Kamin, Compilation as Metacomputation: Binding Time Separa-
tion in Modular Compilers, Tech. rep., Department of Computer Science, University of
Illinois, Urbana-Champaign, 2000.
Harrison, W. L., and S. N. Kamin, Modular compilers based on monad transformers, in
IEEE Computer Society International Conference on Computer Languages, pp. 122–131,
IEEE Computer Society, Chicago, USA, 1998.
Hoare, C. A. R., An Axiomatic Basis for Computer Programming, Commun. ACM , 12 ,
576–580, 1969.
Ivanovi´c, M., and V. Kuncak, M odular Language Specifications in Haskell, in Proceedings
of the Third International Conference on Theoretical Aspects of Computer Science with
practical applications, 2000.
Jones, M. P., and L. Duponcheel, Composing Monads, Tech. rep., Yale University Com-
puter Science Department, New Haven, Connecticut, 1993.
Jones, N. D., C. K. Gomard, and P. Sestoft, Partial Evaluation and Automatic Program
Generation, Prentice-Hall, Inc., Upper Saddle River, NJ, USA, 1993.
210 BIBLIOGRAFIA
Jones, S. L. P., and P. Wadler, Imperative Functional Programming, in POPL ’93: Proce-
edings of the 20th ACM SIGPLAN-SIGACT Symposium on Principles of Programming
Languages, pp. 71–84, ACM Press, Charleston, South Carolina, United States, 1993.
Kay, A. C., The Early History of Smalltalk, in HOPL-II: The second ACM SIGPLAN
Conference on History of Programming Languages, pp. 69–95, ACM, Cambridge, Mas-
sachusetts, United States, 1993.
Kiczales, G., Aspect-Oriented Programming – Keynote Talk at EclipseCon 2004, 2002,
dispon´ıvel em http://www.cs.ubc.ca/˜gregor/.
´
Ultimo acesso: 23 de maio de 2004.
Kiczales, G., and E. Hilsdale, Aspect-Oriented Programming, in Proceedings of the 8th
European software engineering conference held jointly with 9th ACM SIGSOFT interna-
tional symposium on Foundations of software engineering, p. 313, ACM Press, Vienna,
Austria, 2001.
Kiczales, G., and M. Mezini, Aspect-Oriented Programming and Modular Reasoning, in
ICSE ’05: Proceedings of the 27th international conference on Software engineering, pp.
49–58, ACM, St. Louis, MO, USA, 2005.
Kiczales, G., J. Lamping, A. Mendhekar, C. Maeda, C. V. Lopes, J.-M. Loingtier, and
J. Irwin, Aspect-Oriented Programming, in Proceedings of the 11th European Conference
on Object-Oriented Programming, p. 220ff, Springer-Verlag, Jyv¨askyl¨a, Finland, 1997.
Kiczales, G., E. Hilsdale, J. Hugunin, M. Kersten, J. Palm, and W. G. Griswold, An
Overview of AspectJ, in Proceedings of the 15th European Conference on Object-Oriented
Programming, Springer-Verlag, Budapest, Hungary, 2001.
Kim, H., AspectC#: An AOSD Implementation for C#, 2002.
King, D. J., and P. Wadler, Combining Monads, in Proceedings of the 1992 Glasgow
Workshop on Functional Programming, pp. 134–143, Springer-Verlag, London, UK,
1993.
Krishnamurthi, S., K. Fisler, and M. Greenberg, Verifying Aspect Advice Modularly, SIG-
SOFT Softw. Eng. Notes, 29 , 137–146, 2004.
Laddad, R., AspectJ in Action: Practical Aspect-Oriented Programming, Manning, 2003.
BIBLIOGRAFIA 211
Lafferty, D., and V. Cahill, Language-Independent Aspect-oriented Programming, in Pro-
ceedings of the 18th ACM SIGPLAN conference on Object-oriented programing, systems,
languages, and applications, pp. 1–12, ACM Press, Anaheim, California, USA , 2003.
L¨ammel, R., Declarative Aspect-Oriented Programming, in Proceedings of the ACM SIG-
PLAN Workshop on Partial Evaluation and Semantics-Based Program Manipulation,
edited by O. Danvy, Technical report BRICS-NS-99-1, University of Aarhus, pp. 131–
146, San Antonio, Texas, 1999.
Liang, S., Modular Monadic Semantics and Compilation, Ph.D. thesis, Yale University,
1997, adviser-Paul Hudak.
Liang, S., and P. Hudak, Modular Denotational Semantics for Compiler Construction, in
ESOP ’96: Proceedings of the 6th European Symposium on Programming Languages and
Systems, pp. 219–234, Springer-Verlag, London, UK, 1996.
Liang, S., P. Hudak, and M. Jones, Monad Transformers and Modular Interpreters, in
POPL ’95: Proceedings of the 22nd ACM SIGPLAN-SIGACT symposium on Principles
of programming languages, pp. 333–343, San Francisco, California, United States, 1995.
Loredo, F. S., R. S. Bigonha, and F. Tirelo, Implementa¸c˜ao de Semˆantica Vaga em Notus,
Tech. Rep. LLP-03/2008 , Universidade Federal de Minas Gerais, 2008.
Maia, M. A., Implementa¸c˜ao Eficiente de uma Linguagem para Defini¸c˜ao de Semˆantica,
Master’s thesis, Universidade Federal de Minas Gerais, 1994.
Menezes, P. B., and E. H. Haeusler, Teoria das Categorias para Ciˆencia da Computa¸c˜ao,
no. 12 in S´erie Livros Did´aticos, Instituto de Inform´atica da UFRGS, Ed. Sagra Luzzato,
2001.
Meyer, B., Object-Oriented Software Construction, Prentice Hall, New Jersey, 1997.
Moggi, E., Computational Lambda-Calculus and Monads, in Proceedings of the Fourth
Annual Symposium on Logic in computer science, pp. 14–23, IEEE Press, Pacific Grove,
California, United States, 1989.
Moggi, E., Notions of Computation and Monads, Inf. Comput., 93 , 55–92, 1991.
Mosses, P. D., Making denotational semantics less concrete, in Proc. Int. Workshop on
Semantics of Programming Languages, Bad Honnef , no. 41 in B ericht, pp. 102–109,
Abteilung Informatik, Universit¨at Dortmund, 1977.
212 BIBLIOGRAFIA
Mosses, P. D., The Modularity of Action Semantics, Internal Report IR–75 , Dept. of
Computer Science, Univ. of Aarhus, 1988, revised version of a paper presented at a
CSLI Workshop on Semantic I ssues in Human and Computer Languages, Half Moon
Bay, California, March 1987 (proceedings unpublished).
Mosses, P. D., Action Semantics, vol. 26 of Cambridge Tracts in Theoretical Computer
Science, Cambridge University Press, 1992.
Mosses, P. D., An Introduction to Action Semantics, in Logic and Algebra of Specification,
Marktoberdorf Summer School 1991, Proceedings, vol. 94 of NATO ASI Series F , pp.
247–288, Springer, 1993.
Mosses, P. D., AN-2: Revised Action Notation—Syntax and Semantics, 2000, available at
http://www.brics.dk/ pdm/pape rs/Mosses-AN- 2-Semantics/.
Mosses, P. D., The Varieties of Programming Language Semantics (and Their Uses),
in Perspectives of System Informatics, 4th Intl. Andrei Ershov Memorial Conference,
PSI 2001, Akademgorodok, Novosibirsk, Russia, Revised Papers, edited by D. Bjørner,
M. Broy, and A. V. Zamulin, vol. 2244 of LNCS , pp. 165–190, 2001.
Mosses, P. D., Modular Structural Operational Semantics, J. Logic and Algebraic Program-
ming, 60–61 , 195–228, 2004, special issue on SOS.
Mosses, P. D., A Constructive Approach to Language Definition, Journal of Universal
Computer Science, 11 , 1117–1134, 2005.
Mosses, P. D., and D. A. Watt, The Use of Action Semantics, in Formal Description of
Programming Concepts III, Proc. IFIP TC2 Working Conference, Gl. Avernæs, 1986 ,
pp. 135–166, North-Holland, 1987.
Mosses, P. D., and D. A. Watt, Pascal Action Semantics, Version 0.6, 1993,
http://www.brics.dk/ pdm/pape rs/MossesWatt-Pascal-AS/.
Moura, H. P., An Overview of Action Semantics, in I Simp´osio Brasileiro de Linguagens
de Programa¸c˜ao, Belo Horizonte, MG, Brazil, 1996.
Myers, G. J., Reliable Software through Composite Design, Petrocelli/Charter, New York,
1975.
Nygaard, K., and O.-J. Dahl, The Development of the SIMULA Languages, History of
Programming Languages I , pp. 439–480, 1981.
BIBLIOGRAFIA 213
Oliveira, F. F., Compila¸c˜ao de uma Linguagem Funcional Orientada por Objetos para
Defini¸c˜ao de Semˆantica Denotacional, Master’s thesis, Universidade Federal de Minas
Gerais, 1998.
Ossher, H., and P. Tarr, Hyper/J: Multi-Dimensional Separation of Concerns for Java, in
Proceedings of the 22nd International Conference on Software Engineering, pp. 734–737,
ACM Press, Limerick, Ireland, 2000.
Ossher, H., and P. Tarr, Using Multidimensional Separation of Concerns to (Re)Shape
Evolving Software, Communications of the ACM , 44 , 43–50, 2001.
Parnas, D. L., On the Criteria to be Used in Decomposing Systems into Modules, Com-
munications of the ACM , 15 , 1053–1058, 1972.
Plotkin, G. D., A Structural Approach to Operational Semantics, Tech. rep., Computer
Science Department, Aarhus University, Aarhus, Denmark, 1981.
Rajan, H., and K. Sullivan, Eos: Instance-Level Aspects for Integrated System Design,
SIGSOFT Softw. Eng. Notes, 28 , 297–306, 2003.
Rajan, H., and K. J. Sullivan, Classpects: Unifying Aspect- and Object-Oriented Lan-
guage Design, in ICSE ’05: Proceedings of the 27th international conference on Software
engineering, pp. 59–68, ACM Press, St. Louis, MO, USA, 2005.
Schmidt, D. A., Programming Language Semantics, ACM Comput. Surv., 28 , 265–267,
1996.
Scott, D., Data Type as Lattices, SIAM J. on Comp., 5 , 522–587, 1976.
Scott, D., and C. Strachey, Toward a Mathematical Semantics for Computer Languages,
Programming Research Group Technical Monograph PRG-6, Oxford Univ. Computing
Lab., 1971.
Shutt, J. N., Monads for Programming Languages, Tech. rep., Computer Science Depart-
ment, Worcester Polytechnic Institute, Worcester, Massachussets, 2003.
Sipser, M., Introduction to the Theory of Computation, International T homson Publishing,
1996.
Soares, T. C. A. P., Compila¸c˜ao de Semˆantica Denotacional Modular, Master’s thesis,
Universidade Federal de Minas G erais, 2007.
214 BIBLIOGRAFIA
Spinczyk, O., A. Gal, and W. Schr¨oder-Preikschat, AspectC++: An Aspect-oriented Ex-
tension to the C++ Programming Language, in Proceedings of the Fortieth International
Conference on Tools Pacific, pp. 53–60, Australian Computer Society, Inc., Sydney, Aus-
tralia, 2002.
Steele Jr., G. L., Building Interpreters by Composing Monads, in POPL ’94: Proceedings of
the 21st ACM SIGPLAN-SIGACT symposium on Principles of programming languages,
pp. 472–492, ACM Press, Portland, Oregon, United States, 1994.
Stoy, J. E., Denotational Semantics: The Scott-Strachey Approach to Programming Lan-
guage Theory, MIT Press, Cambridge, MA, USA, 1981.
Strachey, C., and C. Wadsworth, Continuations: a Mathematical Semantics Which Can
Deal with Full Jumps, Tech. rep., Programming Research G roup, Oxford University,
Oxford, 1974.
Tennent, R. D., The Denotational Semantics of Programming Languages, Communications
of the ACM , 19 , 437–453, 1976.
Tirelo, F., M. A. Maia, V. O. D. Iorio, and R. S. Bigonha, M´aquinas de Estado Abstratas,
in Anexo do III Simp´osio Brasileiro de Linguagens de Programa¸c˜ao, Porto Alegre, RS,
Brazil, 1999.
Tirelo, F., R. da Silva Bigonha, M. da Silva Bigonha, and M. T. de Oliveira Valente, Desen-
volvimento de Software Orientado por Aspectos, Anexo da XXIII Jornada de Atualiza¸c˜ao
em Inform´atica, XXIV Congresso da Sociedade Brasileira de Computa¸c˜ao, 2004.
Tirelo, F., R. S. Bigonha, and J. Saraiva, Disentangling Denotational Semantics Specifica-
tions, Journal on Universal Computer Science, 2009, (a ser publicado).
Tucker, D. B., and S. Krishnamurthi, Pointcuts and Advice in Higher-Order Languages,
in Proceedings of the Aspect-Oriented Software Development Conference (AOSD 2003),
pp. 158–167, ACM Press, Boston, MA, USA, 2003.
Turi, D., and G. Plotkin, Towards a Mathematical Operational Semantics, in LICS ’97:
Proceedings of the 12th Annual IEEE Symposium on Logic in Computer Science, p. 280,
IEEE Computer Society, Washington, DC, USA, 1997.
von Staa, A., Programa¸c˜ao Modular, Editora Campus, Rio de Janeiro, 2000.
BIBLIOGRAFIA 215
Wadler, P., Comprehending Monads, in LFP ’90: Proceedings of the 1990 ACM conference
on LISP and functional programming, pp. 61–78, ACM Press, Nice, France, 1990.
Wadler, P., The Essence of Functional Programming, in POPL ’92: Proceedings of the
19th ACM SIGPLAN-SIGACT Symposium on Principles of Programming Languages,
pp. 1–14, ACM Press, Albuquerque, New Mexico, United States, 1992.
Wadler, P., Monads for Functional Programming, in Advanced Functional Programming,
First International Spring School on Advanced Functional Programming Techniques-
Tutorial Text, pp. 24–52, Springer-Verlag, London, UK, 1995.
Wadler, P., How to Declare an Imperative, ACM Comput. Surv., 29 , 240–263, 1997.
Walker, D., S. Zdancewic, and J. Ligatti, A Theory of Asp e cts, in ICFP ’03: Proceedings
of the eighth ACM SIGPLAN international conference on Functional programming, pp.
127–139, ACM Press, Uppsala, Sweden, 2003.
Wand, M., G. Kiczales, and C. Dutchyn, A Semantics for Advice and Dynamic Join Points
in Aspect-Oriented Programming, ACM Trans. Program. Lang. Syst., 26 , 890–910, 2004.
Wansbrough, K., and J. Hamer, A Modular Monadic Action Semantics, in Proceedings of
the Conference on Domain-Specific Languages, Santa Barbara, California, pp. 157–170,
The USENIX Association, 1997.
Watt, D. A., An Action Semantics of Standard ML, in Proceedings of the 3rd Workshop on
Mathematical Foundations of Programming Language Semantics, pp. 572–598, Springer-
Verlag, London, UK, 1988.
Watt, D. A., JOOS Action Semantics, Tech. rep., Department of Computer Science, Uni-
versity of Glasgow, Glasgow, Scotland, 1997.
Zhang, Y., and B. Xu, A Survey of Semantic Description Frameworks for Programming
Languages, SIGPLAN Not., 39 , 14–30, 2004.
Livros Grátis
( http://www.livrosgratis.com.br )
Milhares de Livros para Download:
Baixar livros de Administração
Baixar livros de Agronomia
Baixar livros de Arquitetura
Baixar livros de Artes
Baixar livros de Astronomia
Baixar livros de Biologia Geral
Baixar livros de Ciência da Computação
Baixar livros de Ciência da Informação
Baixar livros de Ciência Política
Baixar livros de Ciências da Saúde
Baixar livros de Comunicação
Baixar livros do Conselho Nacional de Educação - CNE
Baixar livros de Defesa civil
Baixar livros de Direito
Baixar livros de Direitos humanos
Baixar livros de Economia
Baixar livros de Economia Doméstica
Baixar livros de Educação
Baixar livros de Educação - Trânsito
Baixar livros de Educação Física
Baixar livros de Engenharia Aeroespacial
Baixar livros de Farmácia
Baixar livros de Filosofia
Baixar livros de Física
Baixar livros de Geociências
Baixar livros de Geografia
Baixar livros de História
Baixar livros de Línguas
Baixar livros de Literatura
Baixar livros de Literatura de Cordel
Baixar livros de Literatura Infantil
Baixar livros de Matemática
Baixar livros de Medicina
Baixar livros de Medicina Veterinária
Baixar livros de Meio Ambiente
Baixar livros de Meteorologia
Baixar Monografias e TCC
Baixar livros Multidisciplinar
Baixar livros de Música
Baixar livros de Psicologia
Baixar livros de Química
Baixar livros de Saúde Coletiva
Baixar livros de Serviço Social
Baixar livros de Sociologia
Baixar livros de Teologia
Baixar livros de Trabalho
Baixar livros de Turismo