Wiki**3

Especificação e código de base

Q: O manual da referência da linguagem Zu 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: No ficheiro "postfix_writer.cpp" existe um comentário a dizer que "Zu doesn't have functions". No entanto, o manual de referência tem uma secção inteira acerca de funções. Existem funções? R: O material originalmente no CVS, embora corresponda ao compilador para a linguage Zu, é realmente o compilador para a linguagem Simple em todas as ocorrências da palavra "simple" foram indiscriminadamente substituídas por "zu". É, assim, natural que alguns comentários válidos para Simple não o sejam para Zu (isto pode ser visto como uma das necessidades de alteração do compilador de Simple para obter o compilador de Zu).

Representação de conceitos e estrutura (AST) (nós)

Código

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_writter, type_checker e xml_writter, 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.

Definição de nós

Q: É necessário adicionar classes nós para representar comentário? 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 do 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: Existe a necessidade de criar uma classe pointer_node? R: O conceito de pointer_node (que corresponderia a um literal para o tipo ponteiro), não existe. A razão é que o único literal para ponteiros é 0 (zero), que é um literal inteiro e, como tal, representado por uma instância de integer_node.

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. Os literais de ponteiros não existem (0, o único literal possível para ponteiros, é um literal inteiro).

Q: É necessária a definição do nó file_node? R: Não: o conceito não existe em Zu. 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 "zu"? R: Os nós correspondentes a este dois conceitos já estão definidos no compilador fornecido no repositório (CVS), sendo inteiramente apropriados para o "zu" (ou seja, a sua redefinição é desnecessária).

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).