A avaliação da entrega intermédia considera a execução de intervenções em várias regiões do código do compilador em desenvolvimento, assim como a gestão do projecto correspondente.

A avaliação é realizada sobre a versão existente no CVS às 12:00 de 2012/04/20. Projectos que não apresentem alterações relativamente ao conteúdo inicial do repositório CVS ou relativamente à entrega inicial não serão considerados.

Advertem-se os alunos sobre a consulta de colegas de anos anteriores. Estas consultas podem ser positivas, mas comportam algum risco, pois o processo e critérios de avaliação podem ter mudado. Além disso, a proficiência do colega pode majorar negativamente o resultado da avaliação em curso. Não são admitidas quaisquer justificações com base na história da disciplina.

Estas condições são aplicáveis à data da entrega intermédia (2012/04/20).

Em caso de dúvidas suscitadas por qualquer elemento neste texto, no projecto, ou na disciplina em geral, os alunos são fortemente encorajados a consultar o corpo docente.

VALORAÇÕES

Existem 6 valores(dos 20 disponíveis para o projecto) associados a esta entrega:

• gestão do projecto: 1 valor
  • projecto com a estrutura correcta no repositório CVS: 0.5 valores (i.e., código que não apresente a estrutura canónica de um compilador desenvolvido com a CDK é considerado sem a estrutura correcta -- consultar estas páginas sobre o desenvolvimento do projecto com base no repositório CVS)
  • projecto compila e produz compilador "tll" ("tll", com letras minúsculas: variações correspondem a "não compilação"): 0.5 valores

Se o projecto compilar, poderão ser atribuídos mais 5 valores(desenvolvimento do compilador), distribuídos como se segue:

• Flex (completo): 1.5 valores
  
  • Tokens correspondentes aos símbolos e palavras chave (simples ajuste do Compact)
  • Identificadores (simples ajuste do Compact)
  • Inteiros (devem estar implementadas todas as bases 8 e 16 -- a base 10 já está implementada no Compact)
  • Reais (extensão dos inteiros)
  • Strings (extensão do Compact)
  • O Flex deve retornar os tokens ao byacc (sobre DEBUG, ver abaixo) -- o não retorno de tokens penaliza fortemente toda a componente Flex (ver penalizações)
• BYACC (completo): 1 valor
  
  • Regras correspondentes a literais de reais e strings (simples extensão do Compact)
  • Regras correspondentes a ciclos, etc. (simples extensão e adaptação do Compact)
  • Regras correspondentes a declarações de variáveis
  • Regras correspondentes a declarações/definições de funções
  • As acções correspondentes às regras definidas no BYACC devem estar implementadas (simples criação de nós) -- a não implementação corresponde a penalizações (var abaixo)
• Nós (nodes) (completo): 1 valor
  
  • Todos os nós necessários para a linguagem (utilizados na especificação BYACC e em passos subsequentes) devem ser criados
  • A não criação de nós motivada pela ausência de definição de acções no BYACC é penalizada (ver abaixo)
  • Sugere-se (por simplicidade de gestão do código) a separação das várias classes de nós em namespaces coerentes (à la Compact; este aspecto, no entanto, não é avaliado)
• Semântica (visitors) (XMLwriter completo; PFwriter ver a seguir): 1.5 valores
  
  • O "visitor" XMLwriter deve estar completamente implementado (ver também DEBUGabaixo)
  • O "visitor" PFwriter deve ter todos os métodos (correspondentes aos nós, tal como o XMLwriter), embora alguns possam estar ainda vazios (i.e., podem não executar qualquer acção)
  • Métodos correspondentes a acções semelhantes às existentes devem ser modelados nos existentes (exemplo, processWhileNode -> processForNode) (mesmo que não modificados numa primeira instância)
  • A presença de implementações de semântica no PFwriter (tabela de símbolos, validação de tipos, etc.) não é penalizada, mas não será avaliada nesta entrega

PENALIZAÇÕES

Existem penalizações relativas à (deficiente) execução do projecto.
São considerados os seguintes aspectos preliminares:

1. A linguagem TLL contém a linguagem Compact (excepto no correspondente à atribuição não ser uma expressão em Compact), pelo que não há razão para não utilizar completamente o compilador Compact, eventualmente com pequenas alterações.
2. A semântica da linguagem TLL contém a da linguagem Compact (excepto no correspondente à atribuição não ser uma expressão em Compact), pelo que a implementação de alguns aspectos da linguagem TLL não requer qualquer reimplementação relativamente ao Compact.
3. O compilador Compact foi fornecido completamente funcional, assim como a versão inicial do compilador TLL no respositório CVS (igual ao Compact e apenas alterado, para ter o nome TLL em lugar de Compact).
4. A criação de novos nós não apresenta quaisquer dificuldades (são classes muito simples)
5. O código dos métodos do visitor XMLwriter corresponde a uma simples impressão dos atributos dos nós, através de uma travessia da árvore que formam e que os contém.
6. O compilador é obrigatoriamente desenvolvido em C++.

Considerando os aspectos 1. a 6., são aplicadas as seguintes penalizações:

• Destruição de funcionalidade do compilador Compact sem substituição por funcionalidade equivalente do compilador TLL: 4 valores
• Não definição dos nós para regras BYACC em avaliação (ver acima) ou não utilização de nós definidos para a escrita dessas acções: 2 valores
• A utilização de funções e estruturas C, quando existem alternativas directas C++ (malloc em lugar de new, por exemplo; strcmp, etc. em lugar da classe std::string; e outras) terá uma penalização máxima de 1 valor
• Não utilização de qualquer material obrigatório: 6 valores(e considera-se projecto não realizado)
  

DEBUG

Esta secção é apresentada como auxiliar ao aluno no despiste de problemas durante o desenvolvimento do compilador, especialmente para aliviar o problema do "debug via printf" (que pode, mesmo assim, continuar a ser usado).

Em lugar de destruir código, frequentemente para colocar no seu lugar uma instrução de escrita (algo que é, por vezes, executado de forma deficiente), sugere-se a utilização das potencialidades integradas nas ferramentas e no material de desenvolvimento:

No Flex, depois do primeiro %%, colocar (separado da primeira coluna do ficheiro por, pelo menos, um espaço), a instrução set_debug(1);(assume-se que a %opção debug está activa).
Esta acção activa a produção de saída de "debug" do Flex, onde são indicadas a execução dos emparelhamentos de caracteres e a activação de regras, com indicação da linha da especificação que foi utilizada.

%option debug
...

%%
        { set_debug(1); }

... resto das regras...

%%

No shell, dar o seguinte comando (activa também o "debug" no BYACC, indicando a zona da gramática que está a ser utilizada):

export YYDEBUG=1

O visitor XMLwriter foi concebido para produzir uma representação textual hierárquica (árvore XML) correspondente ao programa em compilação.
É muito útil para inspeccionar a contrução da árvore de nós por parte do BYACC, permitindo, inclusivamente, a apresentação gráfica.