Seite 1 von 1

Frage zu Aufgabe 1.5

Verfasst: 20. Nov 2011 20:47
von AlexanderF
hallo,

ich habe 2 kurze Fragen zu Aufgabe 1.5.

Können wir vor der Angabe der Klassen des Asts und der Angabe der parse Methoden,

die Grammatik (wie auch in der Vorlesung einmal angesprochen, oder in Stellen im Buch, z.B. s.120) substituieren,
also die S und E Produktion zusammenfassen zu
S ::= while(B) S end | ID,
um unnötig viele Klassen und Methoden zu vermeiden?


zweite Frage:

ist die Aufgabe so gedacht, dass es ein BooleanIteral in der Tokenklasse definiert ist (analog zum IntegerLiteral Folie 16 im Foliensatz zu Lexer und Parser),
so dass man die Klasse die einen B (Teil-)AST repräsentiert, von Terminal abgeleitet werden kann,

oder ist sie so gedacht,

dass man den AST zu B von AST direkt ableiten soll,
und dann extra einen weiteren TRUE AST und einen FALSE AST von B ableiten lassen?


mit freundlichen Grüßen,
Alexander

Re: Frage zu Aufgabe 1.5

Verfasst: 21. Nov 2011 17:50
von Jens Huthmann
Können wir vor der Angabe der Klassen des Asts und der Angabe der parse Methoden,

die Grammatik (wie auch in der Vorlesung einmal angesprochen, oder in Stellen im Buch, z.B. s.120) substituieren,
also die S und E Produktion zusammenfassen zu
S ::= while(B) S end | ID,
um unnötig viele Klassen und Methoden zu vermeiden?
Nein, führen Sie keine Substitution durch. Beachten Sie aber das die Aufgabe nur die Namen der Klassen fordert, Sie müssen die Klassen nicht implementieren. Nur die parseN Methoden werden von Ihnen verlangt.
ist die Aufgabe so gedacht, dass es ein BooleanIteral in der Tokenklasse definiert ist (analog zum IntegerLiteral Folie 16 im Foliensatz zu Lexer und Parser),
so dass man die Klasse die einen B (Teil-)AST repräsentiert, von Terminal abgeleitet werden kann,

oder ist sie so gedacht,

dass man den AST zu B von AST direkt ableiten soll,
und dann extra einen weiteren TRUE AST und einen FALSE AST von B ableiten lassen?
Ich weiß nicht ob ich die Frage ganz richtig verstanden habe aber: true und false sind kein gemeinsames Token mit verschiedener Schreibweise sondern getrennte Tokens. Man kann also von B einen true oder false AST ableiten.

Re: Frage zu Aufgabe 1.5

Verfasst: 21. Nov 2011 19:00
von AlexanderF
Jens Huthmann hat geschrieben:
ist die Aufgabe so gedacht, dass es ein BooleanIteral in der Tokenklasse definiert ist (analog zum IntegerLiteral Folie 16 im Foliensatz zu Lexer und Parser),
so dass man die Klasse die einen B (Teil-)AST repräsentiert, von Terminal abgeleitet werden kann,

oder ist sie so gedacht,

dass man den AST zu B von AST direkt ableiten soll,
und dann extra einen weiteren TRUE AST und einen FALSE AST von B ableiten lassen?
Ich weiß nicht ob ich die Frage ganz richtig verstanden habe aber: true und false sind kein gemeinsames Token mit verschiedener Schreibweise sondern getrennte Tokens. Man kann also von B einen true oder false AST ableiten.
also, ich wollte eigentlich nur nachfragen, ob die Aufgabe überhaupt so gedacht war,
dass man extra neben AST, und B (das von AST ableitet ist), und alle weiteren Klassen die man anlegt (bzw. nennt),

auch extra eine TrueB Klasse und eine FalseB Klasse anlegen/nennen soll, die dann von B abgeleitet wären, (nach etwas nachdenken darüber, vermute ich eher nicht)

oder ob es so gedacht ist, (vermutlich schon eher)
dass keine extra TrueB und FalseB Klassen erforderlich sind (so wie man auch bei einem Triangle Parser nicht für jeden möglichen Integerwert eine Extra Klasse anlegen würde),
und man true und false als Literale ansieht (ebenso wie 1 oder 42 Integer Literale sind)?

mit freundlichen Grüßen,
Alexander

Re: Frage zu Aufgabe 1.5

Verfasst: 22. Nov 2011 14:25
von Bill
AlexanderF hat geschrieben: also, ich wollte eigentlich nur nachfragen, ob die Aufgabe überhaupt so gedacht war,
dass man extra neben AST, und B (das von AST ableitet ist), und alle weiteren Klassen die man anlegt (bzw. nennt),

auch extra eine TrueB Klasse und eine FalseB Klasse anlegen/nennen soll, die dann von B abgeleitet wären, (nach etwas nachdenken darüber, vermute ich eher nicht)

oder ob es so gedacht ist, (vermutlich schon eher)
dass keine extra TrueB und FalseB Klassen erforderlich sind (so wie man auch bei einem Triangle Parser nicht für jeden möglichen Integerwert eine Extra Klasse anlegen würde),
und man true und false als Literale ansieht (ebenso wie 1 oder 42 Integer Literale sind)?

mit freundlichen Grüßen,
Alexander
Die Tatsache, dass simple Typen in der Aufgabe vorkommen, ist beabsichtigt. Sie sollen sich die Frage stellen, wie Sie mit für Ihre Programme insgesamt gültigen Literalen oder Token umgehen. Im vorliegenden Fall impliziert die sehr kleine Menge vorliegender Literale, dass diese direkt als einzelne Token innerhalb der parseN-Methoden verwendet werden sollen. Wenn Sie eine davon abweichende Lösung hervorbringen, die dennoch in sich schlüssig ist, so werden wir auch diese akzeptieren.

Re: Frage zu Aufgabe 1.5

Verfasst: 22. Nov 2011 22:51
von AlexanderF
Jens Huthmann hat geschrieben:
Können wir vor der Angabe der Klassen des Asts und der Angabe der parse Methoden,

die Grammatik (wie auch in der Vorlesung einmal angesprochen, oder in Stellen im Buch, z.B. s.120) substituieren,
also die S und E Produktion zusammenfassen zu
S ::= while(B) S end | ID,
um unnötig viele Klassen und Methoden zu vermeiden?
Nein, führen Sie keine Substitution durch. Beachten Sie aber das die Aufgabe nur die Namen der Klassen fordert, Sie müssen die Klassen nicht implementieren. Nur die parseN Methoden werden von Ihnen verlangt.
ok,

mal anders gefragt,

ein AST ist ja ein Abstrakter Syntaxbaum (Abstract Syntax Tree), der sich an der abstrakten Grammatik orientiert, und nicht an der konkreten Grammatik.
Und der Abstrakte Syntaxbaum enthält ja auch im Normalfall nur noch die Informationen, die für die Bedeutung des Programms von Bedeutung sind, und verwirft alle restlichen Informationen, wie z.B. die konkrete Schreibweise von Schlüsselwörtern (also hier etwa: while(, ) und end).

Ist es also ok,
(unter Beibehaltung der gegebenen konkreten Grammatik; wobei am Rande: bei dieser ist mir auch gerade ein Fehler aufgefallen:
In der Auflistung der Nichtterminalsymbolen steht ein T, wohingegen bei den Produktionen ein E verwendet wird)

die folgende Grammatik als abstrakte Grammatik zu wählen:
G = ({S, B, ID}, {while(, ), end, true, false, a, b, c}, P, S), P :
S ::= while ( B ) S end | ID
B ::= true | false
ID ::= a | b | c

und die Klasse E(bzw. T) und die Methode parseE(bzw parseT) wegzulassen?

das hätte die Vorteile,
1. dass der Abstrakte Syntaxbam nur noch die wirklich benötigten Informationen enthält,
und
2. dass man in der parseS() Methode den Aufrufs der parseE() Methode, welches paradoxerweise einen E AST zurückgeben würde, der für die Bedeutung des Programms aber gar nicht weiter benötigt wird, durch ein accept(Token.END) ersetzen kann.

Mit freundlichen Grüßen,
Alexander

Re: Frage zu Aufgabe 1.5

Verfasst: 23. Nov 2011 09:57
von Bill
AlexanderF hat geschrieben: ok,

mal anders gefragt,

ein AST ist ja ein Abstrakter Syntaxbaum (Abstract Syntax Tree), der sich an der abstrakten Grammatik orientiert, und nicht an der konkreten Grammatik.
Und der Abstrakte Syntaxbaum enthält ja auch im Normalfall nur noch die Informationen, die für die Bedeutung des Programms von Bedeutung sind, und verwirft alle restlichen Informationen, wie z.B. die konkrete Schreibweise von Schlüsselwörtern (also hier etwa: while(, ) und end).

Ist es also ok,
(unter Beibehaltung der gegebenen konkreten Grammatik; wobei am Rande: bei dieser ist mir auch gerade ein Fehler aufgefallen:
In der Auflistung der Nichtterminalsymbolen steht ein T, wohingegen bei den Produktionen ein E verwendet wird)

die folgende Grammatik als abstrakte Grammatik zu wählen:
G = ({S, B, ID}, {while(, ), end, true, false, a, b, c}, P, S), P :
S ::= while ( B ) S end | ID
B ::= true | false
ID ::= a | b | c

und die Klasse E(bzw. T) und die Methode parseE(bzw parseT) wegzulassen?

das hätte die Vorteile,
1. dass der Abstrakte Syntaxbam nur noch die wirklich benötigten Informationen enthält,
und
2. dass man in der parseS() Methode den Aufrufs der parseE() Methode, welches paradoxerweise einen E AST zurückgeben würde, der für die Bedeutung des Programms aber gar nicht weiter benötigt wird, durch ein accept(Token.END) ersetzen kann.

Mit freundlichen Grüßen,
Alexander
Eins vorweg:
Sie haben korrekt identifiziert, dass sich in die Liste der Nicht-Terminale der Fehlerteufel eingeschlichen hat. Selbstverständlich muss es lauten "G = ({S, E, B, I D}, ..."

Bezüglich Ihres Anliegens zur abstrakten Syntax:
Das von Ihnen vorgeschlagene Vorgehen ist im Falle dieser speziellen Aufgabe möglich. Insofern es sich prinzipiell allerdings um einen eigenständigen Datentyp handelt, würde man hier üblicherweise eine eigenständige Implementierung wählen.