Pisanie parsera w ten sposób to jest masakra i zalecam sobie jednak odpuścić ;) W normalnym zyciu pisze się gramatykę a potem generuje parser na jej podstawie. Z punktu widzenia gramatyki dość łatwo widać takie rzeczy jak kolejność operacji. Dla działań mógłbyś mieć np. gramatykę:
S -> A | A + A | A - A
A -> B | B*B | B/B | B%B
B -> S | (S) | liczba
Oczywiście możesz pisać sobie parser ręcznie jak lubisz, ale mimo to zacząłbym od zdefiniowania gramatyki a dopiero potem na jej podstawie myślał o parserze.
Jeśli nie jesteś za bardzo w temacie automatów i języków, to taką gramatykę czyta się mniej wiecej tak:
- S to jest twoje "wejsćie
- każda linijka mówi na co można zamienić symbole
Wiec jak masz np. S = 2+2*2 to parsuje sie to tak:
- Najpierw zamieniamy
S według produkcji A+A, gdzie pierwsze A to 2 a drugie A to 2*2 (to jest jednoznaczne! inaczej sie nie da)
- Następnie zamieniamy pierwsze A na B a później to B na liczbę
- Drugie A zamieniamy na
B*B a następnie każde z tych B na liczbę.
Jakbyśmy mieli np. S = (2+2)*2 to parsujemy tak:
- Najpierw zamieniamy
S na A, następnie to A na B*B
- Pierwsze
B (nasze 2+2) zamieniamy (S) następnie to S na A+A, potem każdą z tych literek na B a następnie na liczbę
- Drugie
B zamieniamy na liczbę
PS: gramatyka pisana z palca przed chwilą, więc może być jakaś głupia :P
I teraz majac taka gramatykę dość łatwo napisać funkcje parsujące bo zwycajnie zamieniasz sobie takie S -> A | A + A | A - A na funkcję z 3 możliwościami, analogicznie jak te case w kodzie który wrzuciłeś.