Como um Java Compiler Parse TypeCasts?

Question

Uma expressão simples como

(x) - y

é interpretado de maneira diferente, dependendo de x é um nome de tipo ou não. Se x não é um nome de tipo, (x) - y apenas subtrai y a partir de x. Mas se x é um nome de tipo, (x) - y calcula o negativo de y e lança o valor resultante para digitar x.

Em um compilador t típico C ou C ++, a questão de saber se x é um tipo ou não é responsável porque o analisador comunica essas informações ao Lexer assim que processar uma declaração typedef ou estrutura. (Eu acho que essa violação exigida dos níveis foi a parte mais desagradável do design de C.)

Mas em Java, x não pode ser definido até mais tarde no código -fonte. Como um compilador Java desambigua essa expressão?

É claro que um compilador Java precisa de vários passes, pois o Java não requer declaração antes de usar. Mas isso parece sugerir que a primeira passagem precisa fazer um trabalho muito desleixado em analisar expressões e, em seguida, em uma passagem posterior, faça outra, mais precisa, análise de expressões. Isso parece desperdício.

Existe uma maneira melhor?

Answer 1

Acho que encontrei a solução que me satisfaz. Graças aos MMYers, percebi que precisava verificar as especificações formais da sintaxe para elenco de tipo.

A ambiguidade é causada por + e - sendo operadores unários e binários. Java resolve o problema por esta gramática:

CastExpression:
        ( PrimitiveType Dimsopt ) UnaryExpression
        ( ReferenceType ) UnaryExpressionNotPlusMinus

(Vejo http://java.sun.com/docs/books/jls/third_edition/html/expressions.html#238146)

Então, '+' e '-' são explicitamente proibidos imediatamente após o ')' de um elenco, a menos que o elenco use um tipo primitivo - conhecido pelo compilador a priori.

Answer 2

Acabei de testar, e este código:

Double y = new Double(0.1);
System.out.println((Double)-y);

dá um erro de compilação:

operator - cannot be applied to Double, java.lang.Double.

Colocar parênteses ao redor do -y faz com que seja compilado bem. Então, aparentemente, Java resolve esse problema simplesmente não o permitindo na gramática (se essa é a terminologia certa; não sou especialista em compiladores).