View source for Compiladores/Projecto de Compiladores/Projecto 2017-2018/Perguntas e respostas sobre GR8

{{PRJCompiladoreAvisosEN20172018}}
<!--{{PRJCompiladoreAvisosEE20172018}}-->
{{PRJCOMandatory20172018}}
{{TOCright}}
== Especificação e código de base ==
<!--
{|
|'''Q:''' O manual da referência da linguagem XPL refere que o 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?<br>
'''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.
|}
-->
== 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?<br>
'''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.<br>
'''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?<br>
'''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ários?<br>
'''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?<br>
'''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?<br>
'''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.<br>
'''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?<br>
'''R:''' Este nó corresponde à ausência de um nó, no contexto do [https://en.wikipedia.org/wiki/Null_Object_pattern 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'''?<br>
'''R:''' Não: o conceito não existe em GR8. 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:''' É preciso ser feita a distinção entre if-then-else e if-else? Representam a mesma ideia?<br>
'''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 GR8?<br>
'''R:''' Os nós correspondentes a este dois conceitos já estão definidos no compilador fornecido no repositório (CVS), sendo inteiramente apropriados para GR8 (ou seja, a sua redefinição é desnecessária e errada).
|-
|'''Q:''' O '''evaluation_node''' já está definido no Simple. Qual é a sua função?<br>
'''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 GR8?<br>
'''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 GR8 não existem programas, mas sim listas de declarações/definições. Deste modo, o conceito de '''program_node''' em GR8 não tem razão para existir.
|}

== Análise lexical ==

== Análise sintáctica ==

== Análise semântica ==

== Geração de código ==

[[category:Compiladores 2017/2018]]
[[category:Projecto de Compiladores]]
[[category:Compiladores]]
[[category:Ensino]]