Les ">>" dans les paramètres de type sont-ils traités par une règle spéciale ?

Question

Je suis confus par le Spécification Java sur la façon dont ce code devrait être codé :

ArrayList<ArrayList<Integer>> i;

La spécification dit :

La traduction la plus longue possible est utilisée à chaque étape, même si le résultat ne permet pas de créer un programme correct alors qu'une autre traduction lexicale le ferait.

Si je comprends bien, l'application de la règle de la "correspondance la plus longue" donnerait les jetons :

• Liste de tableaux
• <
• Liste de tableaux
• <
• Entier
• >>
• i
• ;

qui n'a pas été analysé. Mais bien sûr, ce code est analysé sans problème.

Quelle est la spécification correcte pour ce cas ?

Cela signifie-t-il qu'un lexer correct doit être sans contexte ? Cela ne semble pas possible avec un régulier lexer.

Answer 1

Basé sur la lecture le code lié par @sm4 il semble que la stratégie soit :

• tokenize l'entrée normalement. Donc A<B<C>> i; serait symbolisé par A, <, B, <, C, >>, i, ; -- 8 jetons, pas 9.

• pendant l'analyse syntaxique hiérarchique, lors de l'analyse syntaxique des génériques et d'une > est nécessaire, si le jeton suivant commence par > -- >> , >>> , >= , >>= ou >>>= -- il suffit de frapper le > et repousser un jeton raccourci sur le flux de jetons. Exemple : lorsque l'analyseur arrive à >>, i, ; tout en travaillant sur la règle typeArguments, il analyse avec succès typeArguments, et le flux de jetons restant est maintenant légèrement différent >, i, ; depuis le premier > de >> a été retiré pour correspondre à typeArguments.

Ainsi, bien que la tokénisation se produise normalement, une certaine re-tokénisation se produit dans la phase d'analyse hiérarchique, si nécessaire.

Answer 2

La spécification du langage Java 10 (3.2 Lexical Translations) indique :

La traduction la plus longue possible est utilisée à chaque étape, même si le résultat ne permet pas d'obtenir un programme correct alors qu'une autre traduction lexicale le ferait. Il existe une exception : si la traduction lexicale a lieu dans un contexte de type (§4.11) et que le flux d'entrée comporte deux caractères > consécutifs ou plus suivis d'un caractère non->, alors chaque caractère > doit être traduit par le token de l'opérateur de comparaison numérique >.
Les caractères d'entrée a--b sont transcrits (§3.5) sous la forme suivante a, --, b qui ne fait partie d'aucun programme grammaticalement correct, même si la tokénisation a, -, -, b pourrait faire partie d'un programme grammaticalement correct.
Sans la règle pour les caractères >, deux > parenthèses consécutives dans un type tel que List<List<String>> serait considéré comme l'opérateur de décalage vers la droite signé >>, tandis que trois parenthèses > consécutives dans un type tel que List<List<List<String>>> serait symbolisé par l'opérateur de décalage droit non signé >>>. Pire encore, la tokénisation de quatre parenthèses > consécutives ou plus dans un type tel que List<List<List<List<String>>>> serait ambiguë, car diverses combinaisons de jetons >, >> et >>> pourraient représenter les caractères >>>>.

Les versions antérieures du C++ ont apparemment souffert de ce problème et ont donc exigé au moins un espace blanc entre les deux symboles adjacents inférieur à (<) et supérieur à (>), par exemple vector <vector<int> > . Heureusement, ce n'est plus le cas.