PROJAVA: Um Tradutor de Prolog para Java

Transcrição

1 UNIVERSIDADE CATÓLICA DE PELOTAS ESCOLA DE INFORMÁTICA CURSO DE CIÊNCIA DA COMPUTAÇÃO PROJAVA: Um Tradutor de Prolog para Java por AUGUSTO MECKING CARINGI Projeto de Graduação submetido como requisito parcial à obtenção do grau de Bacharel em Ciência da Computação. Orientador: Prof. Jorge L. V. Barbosa Co-Orientadores: Prof. Adenauer C. Yamin Prof. Luiz A. M. Palazzo Pelotas, Novembro de 2002

2 2 Dedico, in memoriam, à minha avó, Noemi de Assumpção Osorio Caringi.

3 3 Quem, de três milênios, Não é capaz de se dar conta Vive na ignorância, na sombra, À mercê dos dias, do tempo. Johann Wolfgang von Goethe

4 4 SUMÁRIO LISTA DE FIGURAS 6 LISTA DE TABELAS 7 RESUMO 8 ABSTRACT 9 1 INTRODUÇÃO O Contexto do Trabalho Principais Contribuições do Autor Estrutura do Texto HOLOPARADIGMA Contexto e Motivação Hololinguagem Holojava PROLOG Origens Implementação O Modelo de Execução Prolog WAM: Warren Abstract Machine Técnica de Binarização Sistemas Prolog em Java jprolog Prolog Café PROJAVA Visão Geral Estrutura de um Tradutor JavaCC

5 5 4.4 JJTree Definição da Gramática Prolog Árvore de Sintaxe Abstrata IMPLEMENTAÇÃO Ambiente de Execução do Prolog Café Indexação de Cláusulas Funcionamento Estrutura do Código Traduzido Benchmarks Limitações CONCLUSÕES 40 7 REFERÊNCIAS BIBLIOGRÁFICAS 42 A Gramática Prolog para o JavaCC 45 B Programas Prolog usados nos benchmarks 49 B.1 Árvore Genealógica B.2 Série de Fibonacci B.3 Manipulação de Listas B.4 Torres de Hanói C Exemplo de Código Traduzido: Fibonacci 51 D Exemplo de Holoprograma 55

6 6 LISTA DE FIGURAS FIGURA 1 Política de Conversão de Holo para Java FIGURA 2 Gerenciamento de Arquivos na Conversão de Holo para Java 18 FIGURA 3 Módulos do Prolog Café FIGURA 4 Diagrama de Execução FIGURA 5 Diagrama de Geração do Parser FIGURA 6 Gramática Prolog FIGURA 7 Exemplo de Árvore de Sintaxe Abstrata FIGURA 8 Funcionamento Interno do PROJAVA FIGURA 9 Diagrama de Tradução de Prolog para Java

7 7 LISTA DE TABELAS TABELA 1 Principais Opções do JavaCC TABELA 2 Tipo de Produções do JavaCC TABELA 3 Classes Java que modelam os termos Prolog TABELA 4 Benchmarks

8 8 RESUMO O Holoparadigma foi desenvolvido com as seguintes motivações: exploração do paralelismo implícito, atuar sobre arquiteturas distribuídas, trabalhar com múltiplos paradigmas e explorar a execução dos múltiplos paradigmas de forma paralela e distribuída. Com o objetivo de validar o modelo no menor prazo de tempo possível, foi implementada uma ferramenta para tradução de código Holo para código Java. Algumas abstrações da Hololinguagem podem ser traduzidas diretamente para Java; outras, entretanto, necessitam de programas adicionais. Este trabalho se enquadra nesse contexto e contribuirá para integração da programação em lógica ao Holoparadigma. Seu objetivo é a implementação de um módulo para tradução de Prolog para Java. Este módulo será responsável pela tradução das ações modulares lógicas da Hololinguagem em código Java, substituindo o módulo utilizado anteriormente, o qual apresenta sérios problemas de desempenho. Palavras-chave: Holoparadigma, Holojava, Prolog, Técnicas de tradução Prolog, Programação Multiparadigma

9 9 ABSTRACT Holoparadigm was developed with the following motivations: to exploit the implicit parallelism, to be run in distributed architectures, to work with multiple paradigms and to explore the execution of multiple paradigms in a parallel and distributed manner. With the goal of validating the model in the shortest time possible, was implemented a tool for the translation of Holo code to Java. Some abstractions of Hololanguage could be translated direct to Java, others however need additional programs. This work is fit in this context and will contribute to the integration of logic programming to Holoparadigm. Its goal is the implementation of a module to translate Prolog to Java. This module will be responsible for the translation of Hololanguage s modular logic actions to Java code, replacing the previously used module which have serious performance problems. Keywords: Holoparadigm, Holojava, Prolog, Prolog translation techniques, Multiparadigm Programming

10 10 1 INTRODUÇÃO Maior produtividade na programação pode ser obtida através da escolha do paradigma de programação mais apropriado ao tratamento do problema, entretanto, no desenvolvimento de sistemas de software complexos, muitas vezes, um único paradigma não é suficiente. Nesses casos, a melhor abordagem é a programação multiparadigma (HORSPOOL 1996). Linguagens de programação tradicionais (baseadas no paradigma imperativo) são criticadas por não possuírem embasamento matemático, pela dificuldade que elas trazem ao desenvolvimento de software, por não possuirem clareza e por forçarem o programador a pensar de maneira seqüencial. Por outro lado, quase a totalidade de sistemas implementados para uso industrial e comercial são desenvolvidos em linguagens imperativas, ficando os paradigmas alternativos restritos ao meio acadêmico. Provavelmente isso se atribua ao fato de que a transição-de-estados, conceito fundamental da programação imperativa, seja, na verdade, um paradigma muito útil para resolver problemas práticos. Contudo, torna-se claro que certos tipos de problemas são resolvidos de muito melhor forma através de paradigmas não-imperativos. Resolvidos de muito melhor forma significa que a solução é mais clara, mais legível, mais concisa e que ele modela de uma maneira muito melhor o problema tratado (HORSPOOL 1996). Um dos principais representantes dos paradigmas não-convencionais é o paradigma da programação em lógica, paradigma este que tem como modelo computacional a lógica do cálculo de predicados; conforme COLMERAUER (1992), o termo programação em lógica é devido a Robert Kowalski, que vislumbrou a possibilidade de utilização da lógica como linguagem de programação. Prolog, por sua vez, é a linguagem pioneira e principal representante do paradigma da programação em lógica. De acordo com COLMERAUER (1992), Prolog, que é a abreviação de PROgrammation en LOGique, foi desenvolvida no início da década de 70 por ele e seus colegas, na Universidade de Marselha. Desde

11 11 então, a linguagem foi alvo de intensas pesquisas e, entre as suas principais áreas de aplicação, destacam-se: Sistemas baseados em conhecimento; Sistemas de bases de dados; Sistemas especialistas; Processamento da linguagem natural; Engenharia de software; Prova automática de teoremas; Construção de compiladores; Computação simbólica. Segundo STERLING (1994), um programa lógico é um conjunto de axiomas, ou regras, que definem relações entre objetos. A computação de um programa lógico é uma dedução de conseqüências do programa. Um programa define um conjunto de conseqüências, que são seu significado. A arte da programação em lógica consiste em construir programas concisos e elegantes que apresentem o significado desejado. Umas das principais idéias da programação em lógica é de que um algoritmo é constituído por dois elementos disjuntos: a lógica e o controle. O componente lógico corresponde à definição do que deve ser solucionado, enquanto o componente de controle estabelece como a solução pode ser obtida. O programador precisa somente descrever o componente lógico de um algoritmo, deixando o controle da execução a cargo do sistema computacional. Isto possibilita que o programador simplesmente especifique o problema, ao invés de ter que descrever o procedimento para solucioná-lo (PALAZZO, 1997). Este alto poder de expressão, aliado à capacidade de exploração do paralelismo implícito da linguagem Prolog, a torna umas das peçaschave do Holoparadigma. HORSPOOL (1996) e BARBOSA (2002) analisam as diferentes técnicas de programação multiparadigma. A Hololinguagem é classificada como uma linguagem

12 12 multiparadigma de unificação total, porém, com o objetivo de testar os holoprogramas no menor espaço de tempo possível, foi desenvolvida uma ferramenta que traduz código Holo para código Java, neste caso, a abordagem utilizada para fins de execução consiste na programação multiparadigma baseada em tradução, posto que os diferentes paradigmas que compõem o Holo são traduzidos para o paradigma imperativo/orientado a objetos da linguagem Java. A ferramenta Holojava, a qual tem seu funcionamento detalhado no capítulo 2, realiza a tradução dos holoprogramas para Java através de um mapeamento das construções Holo para construções Java. Entretanto, alguns aspectos não possuem equivalentes em Java; nesses casos, são utilizadas ferramentas adicionais, Tratandose especificamente do código Prolog, a ferramenta utilizada até então para tradução era o Prolog Café, contudo, o baixo desempenho deste software, bem como a necessidade do domínio desta tecnologia de tradução, foram os fatores motivadores do presente trabalho. 1.1 O Contexto do Trabalho O Holoparadigma (BARBOSA, 2001) foi desenvolvido com as seguintes motivações: exploração do paralelismo implícito, atuar sobre arquiteturas distribuídas, trabalhar com múltiplos paradigmas e explorar a execução destes de forma paralela e distribuída. Este trabalho se enquadra neste contexto e tem por objetivo central a implementação de um novo tradutor de código fonte Prolog para código fonte Java, com o intuito de substituir o utilizado anteriormente, o qual possui sérios problemas de desempenho. O foco do trabalho é a integração do paradigma da programação em lógica ao Holoparadigma, através do novo tradutor.

13 1.2 Principais Contribuições do Autor 13 Além de participar de discussões sobre os aspectos relativos à integração do paradigma da programação em lógica ao Holoparadigma, destaca-se a atuação do autor nos seguintes aspectos do trabalho: Identificação da origem do problema de desempenho do tradutor utilizado posteriormente; Definição da melhor abordagem para sanar o gargalo de desempenho; Identificação da necessidade de aproveitamento do ambiente de execução do Prolog Café; Implementação do novo tradutor. 1.3 Estrutura do Texto O presente trabalho está dividido em seis capítulos, de forma a introduzir o leitor gradativamente no tema proposto. O primeiro capítulo é a introdução, onde foram apresentados os objetivos, o contexto do do trabalho e também as contribuições do autor. No segundo capítulo, são introduzidos conceitos referentes ao Holoparadigma e tecnologias relacionadas, incluindo Holojava, a ferramenta de tradução de Holo para Java. O terceiro capítulo trata da linguagem Prolog, sua história, suas principais características, fundamentos e técnicas de implementação, além do tradutor atualmente utilizado na Holojava: Prolog Café. Nos capítulo quatro e cinco, são descritos respectivamente, o modelo proposto para o novo tradutor e sua implementação e, no sexto, estão as conclusões deste trabalho.

14 14 A gramática Prolog no formato da ferramenta JavaCC utilizada no desenvolvimento do tradutor PROJAVA está no anexo A. No anexo B, por sua vez, estão os programas em Prolog utilizados nos testes de tradução e benchmarks. A listagem completa do programa que calcula Fibonacci traduzido para Java pode ser encontrada no anexo C e, finalmente, o anexo D contém um exemplo de programa na Hololinguagem.

15 15 2 HOLOPARADIGMA 2.1 Contexto e Motivação Conforme BARBOSA (2002), o Holoparadigma (de forma abreviada, Holo) é um modelo multiparadigma que possui uma semântica simples e distribuída. Através dessa semântica, o modelo estimula a exploração automática da distribuição (distribuição implícita). O estímulo à distribuição implícita é seu principal objetivo. O paralelismo implícito propõe a detecção automática do paralelismo e sua exploração através de mecanismos inseridos no software básico dos sistemas computacionais. Por sua vez, nos últimos anos, os sistemas distribuídos têm recebido cada vez mais atenção, tanto dos centros de pesquisa quanto das empresas. Nesse contexto, torna-se interessante a integração dos temas paralelismo implícito e sistemas distribuídos em um tópico de pesquisa denominado distribuição implícita (BARBOSA, 2002). O Holoparadigma possui como unidade de modelagem os entes e, como unidade de informação, os símbolos. Um ente elementar é organizado em três partes: interface, comportamento e história. Um ente composto possui a mesma organização de um ente elementar, no entanto, suporta a existência de outros entes na sua composição (entes componentes). Cada ente possui uma história. A história fica encapsulada no ente e, no caso dos entes compostos, é compartilhada pelos entes componentes. De acordo com BARBOSA (2002), um ente elementar assemelha-se a um objeto do paradigma orientado a objetos. Do ponto de vista estrutural, a principal diferença consiste na história, a qual atua como uma forma alternativa de comunicação e sincronização. Um ente composto assemelha-se a um grupo. Neste caso, a história atua como um espaço compartilhado vinculado ao grupo.

16 Hololinguagem Conforme BARBOSA (2002), a Hololinguagem (de forma abreviada Holo), implementa os conceitos propostos pelo Holoparadigma. Suas principais características são: multiparadigma: Holo integra múltiplos paradigmas básicos. Atualmente, estão integrados os paradigmas imperativo, em lógica e orientado a objetos; sem tipos e orientada ao processamento simbólico: o símbolo é a unidade de informação do Holoparadigma. A Hololinguagem é baseada no processamento de símbolos e não possui tipos de dados; integração da atribuição e unificação: as variáveis lógicas são manipuladas através da unificação (paradigma em lógica), mas também existe suporte para atribuição; programação de alta ordem: Holo suporta programação de alta ordem, isto significa que símbolos representandos entes e suas partes podem ser manipulados através de variáveis; blackboard hierárquico: exite suporte a vários níveis de blackboard; suporte à Holoclonagem: Holo implementa a clonagem múltipla e seletiva como proposto no Holoparadigma; mobilidade: a mobilidade lógica é suportada explicitamente, já a mobilidade física fica a cargo do ambiente de execução; suporte à concorrência: existe suporte à concorrência entre ações e entre entes; sintaxe lógica compatível com Prolog: os aspectos lógicos da sintaxe da linguagem são compatíveis com a linguagem Prolog; sintaxe imperativa baseada no Pascal: os aspectos imperativos da sintaxe são baseados no Pascal, pela sua simplicidade e algumas semelhanças sintáticas com Prolog.

17 17 Um holoprograma é formado por descrições de entes (entes estáticos), as quais são formadas por Cabeça e Corpo. A cabeça contém o nome de um ente, seus argumentos e uma descrição de sua clonagem. O corpo é formado por duas partes: Comportamento e História. A história é um blackboard que pode ser acessado pelas ações, pelos entes componentes ou pela própria história. O comportamento é constituído por um conjunto de ações que implementam a funcionalidade, existindo cinco tipos diferentes: Ação Lógica (Logic Action - LA): ação formada por um único predicado lógico (uma ou mais cláusulas com mesmo nome e aridade); Ação Imperativa (Imperativa Action - IA): ação formada por uma função imperativa; Ação Modular Lógica (Modular Logic Action - MLA): ação formada por um módulo que encapsula ações lógicas; Ação Modular Imperativa (Modular Imperative Action - MIA): ação formada por um módulo que encapsula ações imperativas; Ação Multiparadigma (Multiparadigm Action - MA): ação que suporta o encapsulamento de LAs e IAs. 2.3 Holojava De acordo com BARBOSA (2001), visando à realização de testes de Holoprogramas (programas em Holo) no menor espaço de tempo possível, foi criada uma ferramenta de conversão de programas, denominada HoloJava. Esta ferramenta converte programas em Holo (linguagem origem) para programas em Java (linguagem destino). Esta técnica é bastante usada na avaliação de novas linguagens, pois a utilização de uma linguagem destino que possua uma plataforma (compilação e execução) já disponível antecipa a realização de testes e a difusão de resultados da pesquisa. Diversos estudos indicam que Java pode ser utilizada como linguagem intermediária na construção de compiladores. Java suporta diretamente várias abstrações

18 18 do Holoparadigma (ações imperativas, concorrência, etc). No entanto, algumas características de Holo não são suportadas (ações lógicas, blackboard e mobilidade). Por outro lado, existem bibliotecas que complementam a plataforma Java e podem ser utilizadas para implementação dos aspectos não suportados. Por exemplo, ações lógicas em Prolog Café (BANBARA, 1999), história em Jada ou JavaSpaces e mobilidade física em Voyager ou Horb. A figura 1 mostra detalhadamente esta política de conversão. Holo Java Ente estático Clonagem de Transição suportando concorrência inter ente (ação clone) Mobilidade lógica (ação move) Ação Imperativa (IA) Ação Modular Lógica (MLA) Invocação explícita História Afirmação para a história (símbolo "!") Pergunta não destrutiva bloqueante para a história (símbolo ".") Pergunta destrutiva bloqueante para a história (símbolo "#") Pergunta não bloqueante e não destrutiva para a história (símbolo "?") Pergunta não bloqueante destrutiva para a história (símbolo "?#") Classe Criação de um objeto (comando new) encapsulado em uma thread e atualização da HoloTree Reorganização da HoloTree e controle de membership nos entes envolvidos Método Classes em Java (Prolog Café) Mensagem Espaço de objetos em Jada Inserção de um fato no espaço Jada (método "out") Obtenção de um fato no espaço Jada (método "read") Obtenção de um fato no espaço Jada (método "in") Obtenção de um fato no espaço Jada (método "read_nb") Obtenção de um fato no espaço Jada (método "in_nb") FIGURA 1: Política de Conversão de Holo para Java A figura 2 ilustra como é feito o gerenciamento dos arquivos na conversão de Holo para Java. É utilizado no exemplo o programa datamining.holo, o qual é composto de 3 entes e uma ação modular lógica (MLA); a listagem completa do

19 19 programa está no anexo D. datamining.holo HoloJava 1 Ente Ente Ente MLA holo mine miner fib holo.java mine.java miner.java fib.pl 2 Prolog Café Predicado fib/2 3 Compilador Java PRED_fib_2.java holo.class + *.class 4 JVM FIGURA 2: Gerenciamento de Arquivos na Conversão de Holo para Java Através de benchmarks realizados em BARBOSA (2001a), foi possível constatar o baixo desempenho do Prolog Café. Em um programa Holo de 73 linhas, das quais apenas 12 compondo uma MLA, 98,93% do tempo total de conversão foi gasto pelo Prolog Café na tradução da MLA, e os resultados se repetiram em diferentes programas, a conversão de um programa sem MLAs chegou a ser 105 vezes mais rápida se comparada a um programa com MLAs. Baseado em tal fato, a utilização das ações modulares lógicas foi considerada um ponto crítico no desempenho da conversão.

20 20 3 PROLOG 3.1 Origens O nome Prolog, abreviação de PROgrammation en LOGique, foi inventado em Marselha no ano de 1972, ele foi escolhido por Philippe Roussel para designar um software projetado para implementar um sistema de comunicação homemmáquina em linguagem natural (COLMERAUER, 1992). A idéia chave por trás da programação em lógica é que, computação pode ser expressa como dedução controlada. 3.2 Implementação A implementação de Prolog tem uma longa história. Os primeiros sistemas foram implementados pelo grupo em torno de Colmerauer, em Marselha, sendo que o primeiro interpretador foi escrito em 1972, em Algol. Se, por um lado, foi demonstrado que era possível a implementação de uma linguagem baseada na lógica do cálculo de predicados, por outro, foi constatado que o principal problema era o baixo desempenho. O primeiro compilador Prolog foi escrito por David Warren em conjunto com Fernando e Luís Pereira em Esse compilador provou que era possível executar Prolog com desempenho semelhante ao das linguagens imperativas tradicionais e contribuiu muito para o sucesso da linguagem Prolog. 3.3 O Modelo de Execução Prolog As duas partes básicas de um interpretador Prolog são a parte de unificação e a de resolução. A resolução é bastante simples, ela consiste em um mecanismo de resolução-sld simplificado, que procura as cláusulas de cima para baixo e avalia os objetivos da esquerda para a direita. Esta estratégia leva ao mecanismo de retrocesso (backtracking) e ao layout usual das áreas de dados e pilha. A resolução manipula a

21 21 pilha de alocação, chamada de procedimentos, e o backtracking. Unificação em Prolog é definida como a seguir: duas constantes unificam se elas são iguais; duas estruturas unificam se seus functores (nome e aridade) são iguais e todos os argumentos unificarem; duas variáveis livres unificam e são amarradas juntas; uma variável livre e uma constante ou estrutura unificam e a constante ou estrutura é amarrada à variável. 3.4 WAM: Warren Abstract Machine Seis anos após o desenvolvimento de seu compilador, David Warren apresentou um novo conjunto de instruções abstratas Prolog. Este novo Prolog Engine veio a se tornar muito popular com o nome Warren Abstract Machine (WAM). Desde então, ele tem sido a base para praticamente todas as implementações Prolog a partir do ano de O Objetivo da WAM é de servir como um modelo simples e eficiente de implementação para interpretadores de byte code, bem como geradores de código nativo. GRUNE et al. (2001) analisam o fato de que enquanto poucos códigos intermediários para linguagens imperativas alcançaram mais que fama local, o código WAM se tornou um padrão de fato, e isso pode refletir a complexidade da tarefa de compilar Prolog. O modelo de execução da WAM é mais semelhante ao das linguagens imperativas do que qualquer outro modelo. A principal idéia é a divisão da unificação em duas partes, a cópia dos argumentos do objetivo chamador para registradores de argumentos e então a unificação destes registradores de argumentos com a cabeça da cláusula chamada. Isto é muito semelhante à passagem de parâmetros para funções em linguagens imperativas como C.

22 22 De acordo com GRUNE et al. (2001), as instruções da WAM lidam com itens como a seleção da cláusula adequada a usar na dedução de um fato, unificação sob várias circunstâncias e backtracking. Além disso, a WAM faz toda a alocação de memória, empregando, para isso, cinco pilhas. 3.5 Técnica de Binarização Conforme LINDGREN (1994), um problema fundamental em executar Prolog, consiste em como mapear eficientemente o controle (incluindo recursão e backtracking) para um hardware convencional. A solução tradicional para este problema, é traduzir código Prolog em instruções para uma máquina abstrata que gerencie as estruturas de controle da linguagem Prolog. Tipicamente isso é realizado através da WAM ou uma variante dela, outra abordagem, entretanto, é a técnica de binarização. A idéia chave do Prolog Binário é a transformação das cláusulas convencionais em cláusulas binárias utilizando Continuation Passing Style (CPS). A essência da técnica de CPS consiste em inserir um argumento adicional em cada predicado, que representa o próximo predicado a ser executado em caso de sucesso. Pesquisas na área de linguagens funcionais demonstraram que a técnica de CPS pode expressar o controle de uma computação de uma maneira muito semelhante ao que os gráficos de controle de fluxo fazem para as linguagens imperativas (LINDGREN, 1994). BinProlog, um sistema Prolog muito eficiente desenvolvido por Paul Tarau (TARAU, 1990) demonstrou as vantagens e desvantagens desta abordagem de implementação. Em Prolog Binário, uma cláusula tem no máximo um subobjetivo, dessa forma, a regra de controle da resolução-sld que era implícita, tornase explícita. O código a seguir ilustra como uma cláusula normal pode ser transformada em uma cláusula binária. nrev([],[]). nrev([h T],R) :- nrev(t,l), append(l,[h],r).

23 23 nrev([],[],cont) :- call(cont). nrev([h T],R,Cont) :- nrev(t,l, append(l,[h],r,cont)). KRALL (2002) também analisa os prós e contras deste método de implementação, o qual é motivado pelas simplificações que se tornam possíveis no sistema de execução. BinProlog, por exemplo, utiliza uma versão muito simplificada da WAM, entretanto, algumas desvantagens, como maior consumo de memória, se tornam presentes. 3.6 Sistemas Prolog em Java A implementação de sistemas eficientes Prolog em Java é atualmente alvo de pesquisas (BANBARA, 1999). O número de sistemas deste tipo cresce a cada dia: BirdLand s Prolog in Java, CKI Prolog, DGKS Prolog, JavaLog, Jinni, JP, jprolog, LL, MINERVA, W-Prolog e Prolog Café. Destes, apenas jprolog e Prolog Café são tradutores, os outros são interpretadores jprolog jprolog foi o primeiro conversor de Prolog para Java, desenvolvido em 1996 por Bart Demoen e Paul Tarau, ele se baseia na técnica binarização (TARAU, 1990). O sistema consiste em um conjunto de classes Java que dão suporte à execução, incluindo uma série de predicados built-in e um tradutor escrito em Prolog. O tradutor não suporta o bootstraping de forma que é necessário um sistema Prolog (SICSTus por exemplo) para realizar a conversão. Para executar o código, uma vez que ele tenha sido traduzido, basta uma máquina virtual Java. Conforme informações obtidas no site do projeto, JPROLOG (2002), o tradutor foi escrito em Prolog por dois motivos: a falta de um gerador de parsers em Java eficiente na época do projeto (1996), e as facilidades oferecidas pela linguagem Prolog para tal tipo de tarefa, incluíndo a extensão DCG (Gramática de Cláusulas Definidas).

24 Prolog Café Conforme BANBARA (1999), Prolog Café é uma ferramenta que traduz código fonte de um superconjunto de Prolog, chamado LLP (Linear Logic Programming Language), para código fonte Java. O programa foi desenvolvido por Mutsunori Banbara e Naoyuki Tamura, tendo por base o jprolog. Benchmarks também realizados por BANBARA (1999) demonstram que o código gerado é 2,2 vezes mais rápido se comparado ao código do jprolog. Além do tradutor, o programa consiste de um ambiente de execução para o código traduzido, o qual é fortemente inspirado na WAM e um conjunto de predicados built-in alguns escritos diretamente em Java e outros traduzidos a partir do Prolog. A figura 3 ilustra os módulos da ferramenta, e a figura 4, por sua vez, mostra como é feita a execução. O sistema possui duas versões do mesmo tradutor, ambos com a mesma funcionalidade, um implementado em Prolog e outro em Java, este último sendo obtido através da técnica de bootstraping, isto é, o tradutor em Prolog é usado como entrada para ele próprio, obtendo como saída um tradutor em Java. De acordo com AHO (1995), bootstraping consiste em utilizar as facilidades oferecidas por uma linguagem para compilar a si mesma. Prolog Café Ambiente de Execução para o código traduzido Tradutor de Prolog para Java escrito em Prolog (acompanha versão bootstrapped) Classes que dão suporte a execução (termos, algoritmo de unificação, etc.) Predicados Built in escritos em Java FIGURA 3: Módulos do Prolog Café

25 25 Código Traduzido de Prolog para Java Ambiente de Execução Conjunto de classes Java que dão suporte a execução do código traduzido Máquina Virtual Java (JVM) Sistema Operacional FIGURA 4: Diagrama de Execução

26 26 4 PROJAVA 4.1 Visão Geral Uma vez identificado que o baixo desempenho da ferramenta Prolog Café deve-se ao fato de o tradutor ser bootstrapped, e reconhecendo que o ambiente de execução da mesma é fruto de muitos anos de pesquisa relacionada à tradução de Prolog para linguagens imperativas, chegou-se à conclusão que a melhor abordagem seria reescrever o tradutor, a partir do zero, totalmente em Java, porém aproveitando as classes que dão suporte à execução do código traduzido. Para que isto seja possível, basta que o novo tradutor seja capaz de gerar um código compatível com o run-time environment já existente. Além disso, tal abordagem minimiza o impacto de adaptação à Holojava de um módulo de tradução de Prolog para Java totalmente diferente do que já vinha sendo utilizado. 4.2 Estrutura de um Tradutor O trabalho de um tradutor pode ser dividido basicamente em três partes: 1. Análise léxica 2. Análise Sintática 3. Geração do Código As primeiras duas fases compõem o núcleo do sistema e envolvem o entendimento do programa fonte e a verificação da correção léxica e sintática. A esse processo damos o nome de parsing. A função do analisador léxico é obter e dividir os tokens no programa fonte. Um token é uma peça significativa do fonte, como uma palavra chave, pontuação ou literais como números ou strings, trechos que são descartados incluem espaços em

27 27 branco e comentários. A análise sintática consiste em obter uma cadeia de tokens provenientes do analisador léxico e verificar se a mesma atende às especificações sintáticas da gramática da linguagem. Conforme AHO (1995) existem três tipos gerais de analisadores sintáticos: método universal, top-down e bottom-up. Através do método universal é possível trabalhar com qualquer gramática, analisadores de tal classe são muito ineficientes. Os do tipo top-down e bottom-up, bem mais eficientes, trabalham somente com determinadas subclasses das gramáticas, mas que são, contudo, suficientemente expressivas para descrever as construções sintáticas das linguagens de programação. Para implementação, duas abordagens podem ser utilizadas, escrever o analisador léxico e o analisador sintático manualmente ou fazer uso de ferramentas que realizam a geração automática de tais tipos de software a partir de determinadas regras. Na década de 50, com o advento dos primeiros compiladores, a construção de analisadores, especialmente os sintáticos, era considerada uma tarefa árdua. Desde então, muita teoria foi desenvolvida na área, com grande destaque para a Teoria das Linguagens Formais, de modo que, atualmente, a construção manual é desconsiderada na maior parte dos casos, deixando-se tal tarefa para ferramentas automatizadas. Existe uma série de ferramentas deste tipo, sendo as mais conhecidas, os tradicionais lex (gerador de analisadores léxicos) e yacc (gerador de analisadores sintáticos) que advêm do mundo Unix; tais programas, porém, não geram código em Java. Dentro da gama de ferramentas que geram código Java, uma destacou-se como padrão: JavaCC (Java Compiler Compiler). É interessante observar que tal classe de software também é conhecida como Compilador de Compiladores. Outro fator que determinou a adoção do JavaCC foi a prévia utilização do mesmo no projeto Holoparadigma, posto que o parser da Hololinguagem é gerado através dele. Tendo o processo de parsing sido executado com sucesso e não gerado nenhum erro, o sistema terá uma representação interna do programa a qual pode ser facilmente manipulada pelo último estágio do tradutor: o gerador de código, que, ao contrário do parser, precisa ser escrito manualmente a fim de se obter o compor-