Parser für Funktionen

Hallo ePvpers,

ich habe ein kleines Problem, und zwar soll ich einen Parser erstellen, der Ausdrücke FUNKTION1(a,b) und FUNKTION1(a,b) erkennt, wobei a und b wiederum von der selben Form sein können, oder aber einfach eine zahl.

Die Grammatik, die ich mir dazu ausgedacht habe, wäre:

command - > FUNKTION1(term,term) | FUNKTION2(term,term)
term - > command | num
num -> [0-9]+

Ich habe nun Probleme damit, einen Parser aus dieser Grammatik zu konstruieren.
Darum bitte ich euch, mir entweder nützliche Ansätze oder treffende Literaturhinweise zu geben.

MFG und danke,
*KiRa*

P.S.:Falls ihr Ansätze habt, bitte ich euch allerdings, mir KEINEN kompletten Lösungsweg zu geben, da ich den Code selbst schreiben möchte.

Recursive descent parser?

Rekursiver Abstieg ? Wikipedia
[Only registered and activated users can see links. Click Here To Register...]

Habt ihr aber sicher auch in der Vorlesung behandelt.

Quote:

Originally Posted by dowhile Recursive descent parser? Rekursiver Abstieg ? Wikipedia [Only registered and activated users can see links. Click Here To Register...] Habt ihr aber sicher auch in der Vorlesung behandelt.

Danke für deine zwei links. Lustig ist nur, dass ich selbst gerade am KIT im 1. Semester bin, weshalb ich erst die Aufgabe habe, also kannte ich die Folien bereits.

Allerdings konnte ich das Problem nun lösen, weshalb der thread geschlossen werden kann.

Vielen Dank,
*KiRa*

Ich hätte einen Rekursiven Parser als Java Projekt, falls Interesse besteht.

Von der Logik her, schreibst du dir eine Funktion, welche deinen übergebenen String char für char durchgeht und so die Grammatik überprüft.
Du speicherst den String in einer globalen Variable und schreibst dir eine Funktion mit folgender Signatur:
welche überprüft, ob die ersten x Zeichen deines Stringes dem übergebenen Commando entsprechen oder nicht.
Am besten legst du für deine Sammlung an Commandos eine Aufzählung an (Enum) und gehst nun jedes enum mit deiner isTerminal Funktion durch. Falls Sie true zurückgibt handelt es sich um eines der übergebenen Commandos, falls false zurückgegeben wird, wird der Index des Parsers zurück auf 0 gesetzt und auf das nächste Commando geprüft.

Ich würde die Eingabe erst in Tokens zerteilen, dann kannst du direkt mit equals() oder einem switch arbeiten. Der Abgabetermin ist aber auch schon vorbei.

Quote:

Originally Posted by Menan Ich hätte einen Rekursiven Parser als Java Projekt, falls Interesse besteht. Von der Logik her, schreibst du dir eine Funktion, welche deinen übergebenen String char für char durchgeht und so die Grammatik überprüft. Du speicherst den String in einer globalen Variable und schreibst dir eine Funktion mit folgender Signatur: Code: boolean isTerminal(String pcommand) welche überprüft, ob die ersten x Zeichen deines Stringes dem übergebenen Commando entsprechen oder nicht. Am besten legst du für deine Sammlung an Commandos eine Aufzählung an (Enum) und gehst nun jedes enum mit deiner isTerminal Funktion durch. Falls Sie true zurückgibt handelt es sich um eines der übergebenen Commandos, falls false zurückgegeben wird, wird der Index des Parsers zurück auf 0 gesetzt und auf das nächste Commando geprüft.

Wie du vielleicht meinem vorherigen Beitrag entnehmen kannst, hat sich das Problem bereits gelöst. Die Logik hinter dem Parser war auch nicht da Problem, sondern die Umsetzung von Streamtokenizer zum StringTokenizer.

@dowhile:
Ich finde allerdings dass das splitten in einzelne Tokens vor dem Parsen eher unschön ist, da dabei ein wenig das rekursive abarbeiten des Strings verloren geht. Ist aber wohl ansichtssache.

Quote:

Originally Posted by *KiRa* @dowhile: Ich finde allerdings dass das splitten in einzelne Tokens vor dem Parsen eher unschön ist, da dabei ein wenig das rekursive abarbeiten des Strings verloren geht. Ist aber wohl ansichtssache.

Finde ich nicht. Wenn du StreamTokenizer genutzt hast, hast du das aber doch ohnehin auch so gemacht. Also ich meine nicht unbedingt den String erst komplett in alle Tokens zu zerlegen, und anschließend erst mit dem Parsen zu beginnen; die Schritte dürfen schon verschmelzen, wobei das ja eher ein technisches Detail ist.
Aber die Aufteilung in Lexer / Tokenizer und Parser ist normal.