Alternativa A - O analisador entra em um estado de erro e para a análise
Introdução ao Problema
Esta questão trata de análise sintática com analisadores LL(1), que são parsers descendentes determinísticos amplamente utilizados na compilação de linguagens de programação.
Conceitos Fundamentais
Analisador LL(1):
- Realiza análise sintática top-down (de cima para baixo)
- Utiliza uma unidade de lookahead (o próximo símbolo da entrada)
- Requer tabelas de parsing determinísticas
Condição LL(1):
Para que uma gramática seja LL(1), cada célula da tabela de parsing deve conter no máximo uma produção. Conflitos ocorrem quando múltiplas produções poderiam ser aplicadas para o mesmo par (não-terminal, símbolo de lookahead).
## Análise das Alternativas
| Alternativa | Avaliação | Motivo |
|---|
| A | ✅ Correta | Conflito = impossibilidade de escolha determinística → erro |
| B | ❌ Incorreta | Tabelas de precedência são para parsers LR/shift-reduce, não LL(1) |
| C | ❌ Incorreta | Ordem de aparecimento não resolve ambiguidade em LL(1) |
| D | ❌ Incorreta | Escolha aleatória viola o princípio de determinismo |
| E | ❌ Incorreta | Aceitação ocorre apenas com entrada válida completa |
## Por que a Alternativa A é Correta?
Quando ocorre um conflito na tabela LL(1):
- Não há como escolher qual produção aplicar sem violar o modelo determinístico
- Isso indica que a gramática não é LL(1) ou houve erro de digitação no código fonte
- O comportamento padrão do analisador é entrar em estado de erro
- O compilador pode então exibir mensagem de erro e tentar recuperação de erros ou parar
Exemplo prático: Se a tabela tiver duas produções para (S, a), o analisador não sabe se expande S → α ou S → β. Sem informação adicional, ele não pode continuar.
Conclusão
Em compiladores, conflitos de parsing significam falha na análise. O analisador LL(1) não possui mecanismos internos para resolver ambiguidades — por isso, a gramática deve ser modificada durante o projeto da linguagem, não durante a execução do parser.
Alternativa A.