Je suppose que le jeton d'un nombre (ce que vous appelez littéral) s'appelle LITERAL
, et que les noms de variables immédiatement après les littéraux ne sont pas une construction normale (dans les langages algébriques c'est généralement le cas, sauf si vous voulez 9 foo
pour signifier 9 * foo
).
Vous devez écrire une règle de bison pour analyser la séquence LITERAL VAR
et retourner un numéro (probablement un autre jeton en plus LITERAL
sauf si vous voulez une règle récursive, par exemple 9u u
). Le code pour cette règle doit vérifier que VAR
est u
(ou un autre postfix juridique) et renvoyer une erreur s'il trouve quelque chose d'inattendu.
J'ai utilisé des séquences de ce type avant d'analyser des unités (par exemple g = 9.81 m/(s^2);
).
Si vous voulez exiger que le u
suivent immédiatement le littéral et le résultat sera un signe LITERAL
, alors vous allez devoir changer votre règle de lex, en supposant unquoted les espaces ne sont pas transmis à l'analyseur.
+1. Donc, vous avez utilisé VAR LITERAL avec succès. Avez-vous essayé de mettre cela dans la lex et d'écrire une bonne partie du compilateur? Je suis exigeant vous suivre immédiatement. Donc je suppose que je vais le mettre dans le fichier lex. –
PS: Peut être intéressant pour vous http://area51.stackexchange.com/proposals/7848/compiler-design. Il faut quelques upvotes et down (vous pouvez faire 5each) –
Eh bien, vous devez prendre du recul et vous demander, "que devrait signifier cette construction, de toute façon?" Dans mon exemple, la réponse était "un suffixe ajoute des unités à une valeur, et ces unités ont leurs propres règles de syntaxe similaires aux équations." Dans votre cas, je suppose que c'est quelque chose comme "un suffixe" u "signifie que la valeur est non signée." De ce qui suit: "Est-ce que l'analyseur considère un littéral non signé distinct d'un littéral signé? Si oui, avez-vous considéré comment la promotion devrait fonctionner, c'est-à-dire signé + unsigned =?" (Cela n'a pas de réponse parfaite.) –