Rechenausdrücke als XML ausdrücken

[JanHH]

Hallo,

mag jetzt etwas wirr erscheinen, aber ich frage mich..

Also Rechenausdrücke kann man ja als Baumstruktur darstellen. Also bspws der Ausdruck

var1*(var2+4)

ist ja eigentlich

Knoten (var1) * Knoten (var2+4)

und der rechte Knoten ist halt

Knoten(var2) + Knoten(4)

ist wohl klar wie ich das meine.

Wenn man das nun mit xml darstellen will, wobei jeder Knoten einen Typ hat und einen linken und einen rechten Teil, bekommt man für das Beispiel

<mult>
   <left>var1</left>
   <right
      <plus>
         <left>var2</left>
         <right>4</right>
      </plus>
   </right>
</mult>

Soweit klar, oder?

Bin nun gerade dabei, mir jaxb und emf anzuschauen. Wenn man das nun automatisch in java-Code überführen lässt, und die Objekte für die plus- und mult-Tags auch die entsprechende Funktionalität haben, kann man daraus doch auf sehr einfache Art und Weise die Möglichkeit schaffen, in java frei definierbare Rechenausdrücke (die halt im xml-Format angegeben werden) zu verarbeiten, oder?

Klingt das vernünftig, oder total unsinng, und es gibt viel einfachere Methoden? Ich suche halt nach einem Weg, meine Applikation möglichst einfach basierend auf möglichst vielen leistungsfähigen Standardframeworks zügig zusammenzubauen.

 

[Marco13]

Keine Antwort bisher ... Die naheliegende Gegenfrage: Warum sollte man

<mult>
   <left>var1</left>
   <right
      <plus>
         <left>var2</left>
         <right>4</right>
      </plus>
   </right>
</mult>

schreiben, wenn man auch
[c]var1*(var2+4)[/c]
schreiben könnte?

 

[JanHH]

Weil man keinen Parser für derartige Ausdrücke programmieren will, sondern sich die ganze interne Baumstruktur, die die Berechnung ausführt, von einem XML-Framework (bin gerade bei EMF) automatisch erzeugen lassen will.

 

[0x7F800000]

Das wäre für die praxis imho unbrauchbar. LaTeX ist schon schwer lesbar genug (und da kann man zumindest mal visuell kontrollieren, was man eintippt), MathML ist dann aber nochmal wesentlich geschwätziger: das würde kein Mensch freiwillig benutzen, da schreibt man sich eher einen ordentlichen Parser...

 

[Wildcard]

Kein Problem mit EMF. Für EMF ist egal in welcher Repräsentation das Modell vorliegt, das muss nicht XML sein. In deinem Fall ist XText genau das richtige. Anhand einer einfachen Grammatik wird dir Lexer + Parser + Linker ( + auf Wunsch sogar ein ganzer Eclipse Editor mit Code Completion, Outline,...) erzeugt. XText kann sowohl mit vorhandenen EMF Modellen arbeiten, als auch EMF Modelle direkt aus der Grammatik ableiten.
Eine Grammatik für Arithmetrische Ausdrücke ist sehr einfach zu schreiben und dank dem Tree-Rewrite Support in XText ist der resultierende AST sogar wesentlich besser als bei bspw. ANTLR.
Für dich als Entwickler macht es hinterher keinen Unterschied ob das Modell textuell oder als XML vorliegt. Die API ist die gleiche, das Handling ist das gleiche, das EMF Modell ist das gleiche.

 

[JanHH]

Das klingt ja ganz interessant. Parser schreiben kommt vorerst nicht in Frage weil es wirklich darum geht, das Projekt so nebenbei mit so wenig Arbeit wie möglich zum Laufen zu bringen, zumindest in der ersten Version. Später Parser schreiben ginge. Für den Anfang ist das Arbeiten mit solchen sperrigen XML-Ausdrücken ausreichend. Es ist auch ein Experiment darin, ein Projekt mit so vielen vorgefertigten Frameworks und so wenig händischer Programmierarbeit wie möglich auf die Beine zu stellen.

Ich hab an der "Vorgängersoftware" jahrelang gearbeitet und fast alles per Hand programmiert. Nun hats geknallt in der Firma, ich musste kündigen, habe aber gemerkt dass ich genau so ein Produkt für eigene Zwecke gut gebrauchen könnte, und habe festgestellt, dass es sich, wenn man viele Standardkomponenten verwendet, in drei Monaten nachbauen lassen müsste, sogar in besserer Qualität, clusteringfähig dank EJB/seam, mit schickerer Oberfläche dank Facelets, mit Datenbankanbindung dank JPA, und und und.. nur was ich nicht habe, ist viel Zeit dafür.

 

[Wildcard]

Ich glaube du hast nicht ganz verstanden. Du bekommst den Parser für diese Art Ausdrücke innerhalb von 2 Stunden fix und fertig ohne eine Zeile Quelltext.
Sogar mit dem exakt gleichen EMF Modell wie du es für XML verwenden willst. Wenn du genauer beschreibst was alles möglich sein soll kann ich dabei sogar helfen.

 

[Wildcard]

Hier mal ein Beispiel:

grammar org.example.arithmetric.MyDSL with org.eclipse.xtext.common.Terminals

generate myDSL "http://www.example.org/arithmetric/MyDSL"

Model :
    (expressions+=Expression)*';';

Expression:
    AtomicExpression
     ({ChainExpression.left=current} operator=Operator right=Expression)?;


AtomicExpression returns Expression:
     LiteralExpression | ParenthesisExpression; 


LiteralExpression:
    value=INT;

enum Operator:
	PLUS='+'| MINUS='-' | MULTIPLY='*' | DIVIDE='/';
	
ParenthesisExpression:
	'(' expression=Expression ')';

Diese Grammatik erzeugt dir automatisch folgendes Ecore:

Ohne eine Zeile Code wird dir ein Parser generiert der solche Ausdrücke problemlos parsen kann:

(123 + (213 - 123 * 23) / (123 - 34234))

Als kleines Extra bekommst du sogar einen Eclipse Editor mit Validierung, Outline, Auto Completion, Syntax highlighting und noch viel mehr Features die ich an diesem kleinen Beispiel nicht zeigen kann:

Das alles war jetzt innerhalb von 10 Minuten nur anhand der obigen Grammatik und ohne eine einzige Zeile Code.
Der einzige Schritt der noch händisch zu tun bleibt ist ein Interpreter der den Expression Baum ausrechnet und das ist trivial und müsste für den XML Weg auf die gleiche Weise interpretiert werden.
Für dein Ecore ist es völlig egal ob es als XML, textuell, in einer Datenbank, oder sonstwo gespeichert wird. Das ist einer der vielen Vorzüge von EMF.

Dadurch das der Parser intern mit ANTLR erzeugt wird hast du sogar so nette Features wie error recovery. Das sorgt dafür das eine Quelldatei auch dann noch geparst werden kann wenn sie syntaxfehler hat.

 

[Wildcard]

Erweitert man das nun auf einfache Weise um Variablen erhält man folgendes Ergebnis (deklarierte Variablen werden automatisch in der auto completion angeboten, referenzen auf nicht deklarierte Variablen automatisch als Fehler erkannt):

Immer noch ohne eine Zeile Code, lediglich mit erweiterter Grammatik:

grammar org.example.arithmetric.MyDSL with org.eclipse.xtext.common.Terminals

generate myDSL "http://www.example.org/arithmetric/MyDSL"

Model :
    (statements+=Statement)*;

Expression:
    AtomicExpression
     ({ChainExpression.left=current} operator=Operator right=Expression)?;


AtomicExpression returns Expression:
     LiteralExpression | ParenthesisExpression | VariableReference; 


LiteralExpression:
    value=INT;

enum Operator:
	PLUS='+'| MINUS='-' | MULTIPLY='*' | DEVIDE='/';

Statement:
'var' output=Variable '=' input=Expression ';';
	
ParenthesisExpression:
	'(' expression=Expression ')';
	
Variable:
	name=ID;	
	
VariableReference:
	value=[Variable];

 

[JanHH]

Allerbesten dank!!!!

Würde Dir jetzt einen virtuellen Keks hier schenken, wenn das möglich wäre. Oder ein Freibier .

Das Problem ist, auch wenn es nur 2 std. dauert, es erfordert auch Einarbeitung, und das dauert dann alles in allem doch wieder zu lange. Aber werd da scheinbar doch nicht drumrum kommen. Aber gut zu wissen dass es auch sowas schon vorgefertigt gibt . Ein kompletter Skript-Parser für das Dokument ist zumindest was, was langfristig auch noch irgendwann sein muss.

 

[GastWildcard]

Eigentlich meinte ich 2 Stunden inklusive Einarbeitungszeit. Ich habe die Einarbeitungszeit hinter mir und daher war das in 10 Minuten erledigt...

 

[JanHH]

Du Optimist

 

[Wildcard]

Es hängt wie gesagt nur an der Grammatik. Mit dem Ding von oben hast du ja schon eine gewisse Vorarbeit. Daraus dann den Code für Parser, Lexer, AST, Eclipse Editor, Modell,... zu erstellen erfordert 2 Klicks

 

[Sanix]

Das ist ja krass, wir machen das gerade von Hand in der Schule und das geht ohne Programmieraufwand...

 

[DamienX]

Ich häng mich eigentlich nicht OT in fremde threads aber merci Wild
für die Mühe.

Vllt. wirds mal Zeit für deinen ersten Blog Eintrag.

Greetings

 

[Wildcard]

Das ist ja krass, wir machen das gerade von Hand in der Schule und das geht ohne Programmieraufwand...

Parsergeneratoren gibt es wie Sand am Meer, ANTLR ist nur einer davon. Das ist zwar nett, aber noch nicht das fundamental neue an XText. Die eigentlichen Alleinstellungsmerkmale von XText sind eher:

• Linker Logik ist direkt Teil der Grammatik wodurch echte Referenzen möglich werden
• Neben Lexer Parser und AST wird ein Linker generiert
• Die Grammatik wird in ein mächtiges EMF Modell überführt
• man kann Grammatiken für bestehende EMF Modelle schreiben
• Man kann von Grammatiken 'erben'
• Es wird ein Eclipse Editor generiert der automatisch die wichtigsten Merkmale des Java Editors enthält (Hyperlinks, live Validation, Auto Completion, Template Support, Outline, Marker, Highlighting,...