| AVISOS - Avaliação em Época Normal |
|---|
|
Esclarecimento de dúvidas:
|
|
Requisitos para desenvolvimento, material de apoio e actualizações do enunciado (ver informação completa em Projecto de Compiladores):
|
|
Processo de avaliação (ver informação completa em Avaliação do Projecto):
|
| Material de Uso Obrigatório |
|---|
| As bibliotecas CDK e RTS de apoio ao desenvolvimento do projecto são de uso obrigatório: |
|
| A máquina virtual, fornecida para desenvolvimento do projecto, já contém todo o material de apoio. |
| Uso Obrigatório: Repositório GIT |
| Apenas se consideram para avaliação os projectos existentes no repositório GIT oficial. Apenas se considera para avaliação o ramo main.
Trabalhos não presentes no repositório no final do prazo têm classificação 0 (zero) (não são aceites outras formas de entrega). Não são admitidas justificações para atrasos em sincronizações do repositório. A indisponibilidade temporária do repositório, desde que inferior a 24 horas, não justifica atrasos na submissão de um trabalho. |
| Q: O manual da referência da linguagem XPL refere queo valor devolvido por uma função, através de atribuição ao left-value especial com o nome da função, deve ser do tipo declarado. O que é este left-value especial? R: Na prática, este left-value é uma variável automática associada a cada função, servindo para guardar o valor actual do retorno dessa função, para ser retornado quando a função devolver o controlo ao chamador. |
| Q: Reparei o header contém getters e setters + operators definidos, deixando os "métodos complicados" para implementação no .cpp. Devemos empregar este padrão daqui em diante? R: A ideia é que os .h de uma dada classe tenham as declarações da classe e que o .cpp tenham as implementações de métodos (especialmente os complicados). No entanto, os .h também podem ter métodos e funções (especialmente as que forem simples e inline). Em C++, ter classes distribuídas por pares de ficheiros com o mesmo nome da classe, embora não obrigatória, é muito conveniente e evita problemas de organização de código. |
| Q: Adicionei um novo nó XXX_node à pasta "ast" e actualizei o método correspondente do_XXX_node na classe do visitor xml_writer. No entanto, o compilador não compila. R: Devido à estrutura do padrão de desenho Visitor, não é suficiente definir o método do_XXX_node apenas numa das classes concretas dos visitors (na directoria "targets"). É necessária a definição do método em todas as classes dos visitors, incluindo na superclasse basic_ast_visitor. |
| Q: Quando adicionei o meu primeiro nó na pasta "ast", tive de propagar a alteração pelo postfix_writer, type_checker e xml_writer, adicionando a assinatura dos métodos do_*_node. De outra forma compilava com erros. É normal ou há alguma forma de ultrapassar isto? R: Sim, é normal: é uma consequência do padrão de desenho Visitor. |
| Q: É necessário adicionar classes nós para representar comentários? R: Apenas existem nós para conceitos (semântica) da linguagem. Os comentários não existem, do ponto de vista de materialização sob a forma de código ou dados, logo não é necessário representá-los como elementos da árvore sintáctica do programa. |
| Q: Posso adicionar nós ao compilador, mas que já existem na CDK? R: Apenas devem ser incluídos no compilador nós que não existam ainda na CDK. Definir nós com o mesmo significado dos da CDK é um erro de modelação. Não basta mudar o namespace: se o nó tem a mesma semântica que o da CDK, então não deve existir no compilador. |
| Q: Acrescentei um novo nó ao compilador. O novo nó tem o mesmo nome que um da CDK (mas está noutro namespace). Fiz mal? R: Se o novo nó, apesar de ter o mesmo nome que um da CDK, tiver uma semântica diferente (i.e., representa informação diferente), então pode ter sentido existir. |
| Q: Qual é o motivo para as classes de tipos de dados não deverem existir na pasta "ast" do projecto? A CDK já tem nós como integer_node, double_node, etc. R: Os tipos de dados não correspondem a nós da árvore sintáctica, já que estão a outro nível, sendo instâncias da estrutura basic_type (CDK). Os nós integer_node, double_node, etc., não correspondem a tipos, mas sim a literais dos tipos correspondentes. |
| Q: O nil_node que está na CDK corresponde ao literal que pode ser aceite pelo tipo ponteiro? R: Este nó corresponde à ausência de um nó, no contexto do padrão de desenho Null Object. Como tal, não pode ser usado como expressão. |
| Q: É necessária a definição do nó file_node? R: Não: o conceito não existe em XPL. Embora a gramática do manual de referência mencione a estrutura, ela não corresponde a nenhum conceito específico da linguagem: cada ficheiro é simplesmente uma sequência de declarações, i.e., o conteúdo é representável como uma instância de sequence_node. |
| Q: É necessário modelar com um nó especial o left-value especial do valor de retorno das funções? R: Essa variável não tem uma correspondência directa com nós de variáveis, mas sim com o nó de definição das funções (este nó é suficiente para modelar e controlar a geração de código desse left-value). |
| Q: É preciso ser feita a distinção entre if-then-else e if-else? Representam a mesma ideia? R: Pode ser conveniente fazer a distinção entre os dois conceitos (apesar de, no fundo, representarem a mesma ideia), já que permite geração de código mais adaptada a cada um deles. |
| Q: Relativamente aos conceitos if-then-else e if-else, tenho de os redefinir no compilador de XPL? R: Os nós correspondentes a este dois conceitos já estão definidos no compilador fornecido no repositório (CVS), sendo inteiramente apropriados para XPL (ou seja, a sua redefinição é desnecessária e errada). |
| Q: Gostaria de saber se, quando se declara uma função, posso definir o valor de retorno por omissão, ou se esse valor só pode ser especificado quando se trata de uma definição de função. R: O valor por omissão só é relevante quando se define a função, já que é apenas utilizado no corpo da função. |
| Q: O evaluation_node já está definido no Simple. Qual é a sua função? R: Este nó serve para permitir usar expressões onde são esperadas entidades que não produzem valores. O nó permite descartar o resultado calculado por uma expressão (de acordo com o seu tipo), quando esse resultado não é útil (por exemplo, quando a expressão é usada como instrução). |
| Q: O program_node do Simple existe em XPL? R: Cada tipo de nó representa uma entidade numa linguagem. Na linguagem Simple (a linguagem de partida), o conceito de programa existe (representa a função principal) e, assim, também o de program_node. Em XPL não existem programas, mas sim listas de declarações/definições. Deste modo, o conceito de program_node em XPL não tem razão para existir. |