Formelsprache TO LotusScript Code-generierer schreiben

[flaite]

Ob der Aufwand aber in Relation zum zu erzielenden Erfolg steht wage ich zu bezweifeln.

Dir fehlt einfach der Glauben an die Kraft und Reinheit der GOF Design Patterns, Ulrich.




 

[koehlerbv]

Als Ergebnis erhalte ich @if(@Command([CN];@UserName)="Hein Bloed";1;2) zurück; und jetzt ?

Und das Ergebnis müsste ja eigentlich lauten: "Syntax error !" 

Ich halte das Thema auch für hochinteressant - aber eher theoretischer Natur. Das Vorgehen bei @functions und mit LS ist ja teilweise ein völlig anderes, und ein pures Umsetzen von @functions nach LS erscheint mir zweifelhaft. @functions habe ihre Welt (und lassen sich teilweise durch LS überhaupt nicht ersetzen), und LS hat eben einen ganz anderen Hintergrund. Ein derart automatisch umgesetzter Code waäre auf jeden Fall alles andere als optimal.

Weiterhin: Warum soll neben @functions (source code) und LS (target code) noch eine weitere Sprache (und System) (Java) zum Tragen kommen ?

Bernhard

[Gandhi]

@Bernhard: Syntaxüberprüfung ist definitiv gar nicht drin
@Eknori: Genau das soll es auch

Wie gesagt: Jede einzelne Anweisung wird erst mal in einen neuen Tree umgewandelt - der im ersten Schritt eben Deine gesamte Formel ist, da sie aus nur einer verschachtelten Anweisung besteht.

Bsp.:
_Field feld:=feld;  ==> erster Tree
_retVal:=@if(@Command([CN];@UserName)="Hein Bloed";1;2)  ==> zweiter Tree
_b:=@if(cond1;@if(cond2;@if(cond3;.....==>dritter Tree

jeder Tree muss dann baummässig soweit aufgesplittet werden, bis nichts mehr geht - und die Blätter/Endknoten dann in Script übersetzt und zusammengebaut werden.
Die Sache mit dem Array von Trees hat meiner Meinung nach den grossen Vorteil, dass die Reihenfolge nicht verloren geht.

Um das Ergebnis zu erhalten, dass Du gerne hättest, Ulrich, vergeht sicher noch ein wenig Zeit.

Insgesamt ist es aber aufgrund des relativ klaren Syntax (Tokentrennung) vermutlich relativ einfach Formulas so zu zerlegen (ganz im Gegensatz zu LotusScript - wo so eine schöne Trennung mittels klar definierter Zeichen und simplen Regeln fehlt)

Das Hauptproblem sehe ich in der (Deppenarbeit) alle Formeln umzusetzen - und in der Kontextabhängigkeit von Formeln. FormelAgents umzusetzten ist sicher gar kein Problem, was aber macht man z.B. mit Wertformeln.
Ich will mich daher auf Agenten beschränken - und hier kann man das ruhig auch in Java machen - wobei man sich damit - zunächst (bis zur Eclipse Plattform) einiges verstellt.

[Gandhi]

Aber das gibt tatsächlich Probleme ohne Ende...

Angenommen:

Am Ende eines Baumes steht: 1:2:3:4
Also ein Integer Array.
Das muss man erst identifizieren bevor man es weiterverarbeiten kann.

Und selbst bei einer Beschränkung auf Agenten gibt es ja solche, die auf alle Dokumente der DB wirken, solche, die auf eine Auswahl wirken und solche, die auf keine speziellen Dokumente wirken. Also 3 verschiedene Scripte je nach Agenteneinstellung...

[eknori]

Syntaxüberprüfung ist definitiv gar nicht drin

Doch, wo .ohl, siehe !!HELP!! Projekt 

und bitte nicht mit Heiligenbildchen kontern ...

[flaite]

und bitte nicht mit Heiligenbildchen kontern ...

Das ist kein Heiligenbildchen. Auf dem schönen Bild ist eindeutig die Jungfrau Maria zu sehen.

Aber jetzt mal im ernst. Ich schaue mir das einfach mal an wie weit ich komme. Der Rest ist eh Spekulation. Bisher sind aus meiner Sicht noch keine besonders gewichtigen Gegenargumente gekommen. Ausser, dass es sehr viel ist. Aber das habe ich ja auch schon gesagt.
Und ich habe auch gesagt, dass es mir schon ausreichen würde, wenn eine Teilmenge der Formeln übersetzbar wäre. Ich will aber ein System schaffen, dass komplexitätsmässig gut skalliert. Dh. dass es am Ende genauso einfach ist, eine zusätzliche Formel einzubinden wie am Anfang. Oder noch einfacher, weil das Framework besser ist. Aber erst am Wochenende, weil ich in meinem Tagesjob
- momentan auch eine sehr interessante Aufgabe habe: Allgemeines Generierungsverfahren einer XML Datei aus verschiedenen Notesanwendungen für XML-Beschreibungsdateien (unterschiedliche und änderbare Typen) und
- wir Anfang September ein Punktrelease haben und da sind noch issues auf der Liste.

Möglicherweise ist die Grundarchitektur relativ einfach und die explodierende Anzahl an in die Gesamtarchitektur problemlos einplugg-baren Klassen ist dann Fleißarbeit. Ich weiss es einfach noch nicht. Prognosen sind schwierig, vor allem wenn sie sich auf die Zukunft beziehen.
Naja. Ich werds mal anfangen.

@Gandi: Ich würd keine Arrays nehmen, sondern List, bzw. als konkrete Klasse wohl java.util.ArrayList. Das Identifizieren ist kein Problem. Ich will die semantische Bedeutung quasi schon beim parsen klären (vereinfacht ausgedrückt). Aber das ist alles Spekulation.

Axel

[flaite]

@Bernhard: einen Sinn hat das schon und ich hab das weiter oben gesagt: Ich arbeite öfters mit älteren Formelsprache-Code. Und da wurde Formelsprache in Kontexten verwendet, in denen wir heute Skript verwenden. Und das macht die Anwendungen schwer wartbar. Ich hab schon einige male per Hand bestehenden Formelsprachecode in LotusScript umgewandelt. Andreas G. (zu schwieriger Nachname) hat glaub ich auch mal erwähnt, dass er das gemacht hat. Oft ist der Kontext, in dem in bestehenden Anwendungen Formelsprache verwendet wird historisch gewachsen. Und dafür kann das hilfreich sein.
Es soll in keinem Fall eine Art Tool werden, mit dem Leute die "Formelsprache nicht können" Lotusscript generieren. Sondern es hat einen ganz klaren Fokus auf "Refaktorierung von Legacy Code".
Anwender brauchen Java nicht zu können. Ich kann da verschiedene Interfaces für bauen. Eine GUI, eine Webseite, Files, ein Webservice. Egal.
Anwender müssen natürlich Java können, um Arten von Formeln konvertieren zu können, die noch nicht unterstützt werden. Es gibt ja viele Formeln. Und da es explizit als Framework-Code gedacht ist, soll es relativ einfach sein Erweiterungen zu schreiben. D.h. es gibt einen gewissen Rahmen, auf denen die Klassen aufsetzen können.

Es gibt bestimmte prä-XHTML-parsing openSource Frameworks in Java, mit denen HTML Files geparsed und aus den einzelnen Tags ein Objektbaum generiert wird. Da könnte ich vermutlich einiges abkupfern.

Axel

[koehlerbv]

@Bernhard: Syntaxüberprüfung ist definitiv gar nicht drin

Das war schon klar, Gandhi. Der von Dir gepostete Code war sehr gut lesbar  Das war eher ein Joke auf Ulrichs Beispiel - und eigentlich nicht (ganz) ernst gemeint, da eine Validierung wohl dann die absolute Kür sein müsste (der zu übertragende Code sollte ja wenigstens schon mal lauffähig gewesen sein).

Bernhard

[koehlerbv]

Völlig ohne Frage, Axel. Ich habe es logischerweise auch mit Situationen zu tun, in denen "hysterisch gewachsener" Code mit @functions sinnvollerweise (weil @functions dort wegen fehlender Möglichkeiten / durchaus auch schlechter Wartbarkeit) durch LS ersetzt werden müssen.

Bisher bedeutete das nach meiner Erfahrung immer Situationen, in denen das ganze Herangehen auszutauschen war. Und an vielen Stellen sind @functions prinzipiell nicht austauschbar, weil technisch bedingt einfach nicht ersetzbar.

Weiterhin - und was ich schon einmal geschrieben habe: Wenn man @functions austauscht gegen LS, dann verfolgt man damit sinnvollerweise auch ein ganz anderes Konzept der Programmierung. Ich kann mir einfach nicht vorstellen, dass eine sture "Sprachkonvertierung" hier wirklichen Zugewinn generierert.

Als eine Art "Recompiler / Umsetzer" mit starkem Parser ist das Thema natürlich hochinteressant. Ich bezweifele nur den praktischen Nutzen. Ansonsten  würde ich mich da liebend gerne beteiligen (mein erstes "Projekt" war Mitte der 80er ein 6510 Assembler, der logischerweise erstmal in Maschinencode zu erstellen war, bis er selber "mithelfen" konnte, sich selber verbessern zu helfen).

Bernhard

[flaite]

... denke aber, dass auch wenn man nur Teile des Formelsprache-Code automatisch in LotusScript umwandelt, dann hat man eine Basis, mit der die Umstellung auf LotusScript einfacher ist. Das soll ja keine LotusScript Programmiermaschine ohne menschliche Interaktion sein. Man kann den generierten Code ja weiterverarbeiten.

Aber das sind eh alles erstmal ungelegt Eier.
Ich suche erst einmal nach openSource Projekten mit einer ähnlichen Aufgabe.
Bisher gefunden:
http://sourceforge.net/projects/htmlparser
FALLS JEMAND EINEN WEITEREN VORSCHLAG HAT, bitte posten.

Ich versuche dann Design-Prototypen zu erstellen. Sobald ich etwas habe, poste ich.

Axel

[Gandhi]

Projekte dieser Art müsste es zuhauf geben - wenn man ein wenig weiter abstrahiert - denn es ist ja im Grunde nichts anderes als ein Compiler/Interpreter, der eine Sprache (Formulalanguage) in einen 'Bytecode' (Lotus Script) umwandelt

Eigentlich ganz lustig aus psychologischer Sicht: Axel will aus Formula was Java-ähnliches machen (Bitte, bitte nicht ernst nehmen!). Über die Motivation will ich gar keine Vermutungen anstellen.

Zum Compiler/Parserbau müsste es doch eigentlich tonnenweise Literatur geben? Vielleicht hilft das weiter: http://de.wikipedia.org/wiki/Compilerbau

[flaite]

Ich glaub, dass es etwas anderes ist einen Kompiler für eine Programmiersprache zu schreiben, als eine Skriptsprache in die andere zu transformieren. Ausserdem habe ich nicht nach vielen Treffern sondern nach nahen Treffern gefragt.
Ohne jede gut/schlecht Wertung.
Bei Gandi scheint das manchmal nach dem alten kubanischen Sprichwort zu laufen:
El cubano comprende el mundo hablando.
Der Kubaner versteht die Welt, indem er redet.
Wobei ich mich da irgendwie auch nicht beschweren kann. 

[Gandhi]

Der Compilerbau (auch: Übersetzerbau) ist eine Disziplin der Informatik. Sie beschäftigt sich mit dem Entwurf und der Programmierung von Compilern, die einen Quellcode (ein meist in einer höheren Programmiersprache verfasstes Programm, also einen Quelltext) in einen Zielcode (meist eine weniger ausdrucksstarke Sprache, vorrangig Maschinensprache) umsetzen.

Ich finde, das passt sehr gut.

Und: wie soll ich wissen, was ich denke, bevor ich höre, was ich sage

Have a nice day

[flaite]

Bisheriges Zwischenergebnis der kollektiven Recherche:
- 1 openSource Projekt, an dem Joshua Kerevsky, mindestens 3 weitere Senior Java Entwickler und mehrere ungenannte Java Entwickler nach strengen Qualitätskriterien ca. 5 Mannjahre dran gearbeitet haben.
- 1 Wikipedia Eintrag bestehend aus ca 40 brillianten Worten von einem Typen aus dem Internet.

[Gandhi]

Nun, wärst Du meinem Link gefunden, so hättest Du gefunden:

FLEX:http://www.gnu.org/software/flex/ Erzeugt ein Programm zur Trennung von Tokens - Voraussetzung: Lexik bekannt. Macht die halbe Arbeit. Ist vermutlich nicht in Java vorliegend.

Bison:http://www.gnu.org/software/bison/bison.html Erzeugt Parser (in C) nach Vorgabe der Grammatik.

Coco/R:http://www.ssw.uni-linz.ac.at/Research/Projects/Coco/ ist ein Compilergenerator - und fasst soz. die Funktion der beiden og. Tools zusammen. Dieser ist offensichtlich sogar unter Java verfügbar.

JavaCC:https://javacc.dev.java.net/ Vereint ebenso Parser und Scanner - ist in Java verfügbar - und wie alle o.g. mehr oder weniger Open Source.

Das alles stand in meinem geposteten Link - ich hoffe es wird nützlich sein.
Die Programme gehen sogar noch einen Abstraktionsschritt weiter: Sie erzeugen Programme, die Programme compilieren können (und auch wenn es Dir nicht gefällt: genau das hast Du vor - genauer: Du willst einen Transpiler)

Transpiler (wieder aus dieser Seite Wikipedia, wo sich Typen aus dem Internet in brillianten Worten verewigen):

Transpiler (auch Transcompiler) übersetzen Quellcode einer Programmiersprache in den Quellcode einer anderen Programmiersprache. Zum Beispiel ist bei den .NET-Programmiersprachen von Microsoft eine Übersetzung von C# nach VB.NET relativ einfach, da beide Sprachen auf demselben Grundgerüst aufbauen (.NET-Framework).

[flaite]

JavaCC ist sicherlich interessant. Glaub aber, dass es sicher zu komplex wäre, für das was ich vorhabe.
Wir brauchen ja keine komplexe Grammatik definieren. Formelsprache ist eigentlich einfach.
Ich parse NotesFormelCode.
Das nächste Token-Ende nach @ ist (.
Das nächste Tokenende nach ( ist ; , ),  bzw. @ oder [

Ich bin da auch kein Experte drin, aber ich versuch erstmal ein bischen weniger akademisch da dranzugehen. Vielleicht scheitert das.

thx Axel

[animate]

ich finde das ist ein sehr schönes Beispiel, um Test-Driven Development anzuwenden.

Einfach anfangen und langsam größer werden.

Siehe Bowling Kata von Uncle Bob (http://butunclebob.com/ArticleS.UncleBob.TheBowlingGameKata) und Agile Software Development Kapitel 6

 

[eknori]

Das nächste Tokenende nach ( ist ;

und was ist bei strukturierten @IF ? Ohne eine Grammatik gehst du da auf die Bretter ...

TokenEnde kann immer nur ein ")" sein. Erst dann kannst du anfangen alles zwischen dem ( und dem ) aufzudröseln

Ach ja, das letzte Element in einer Formel muß nicht zwingend das ; sein.

"nicht akademisch" an die Sache heranzugehen halte ich für durchaus brauchbar; am Ende wirst du aber wieder bei den akademischen Lösungsansätzen enden  ...

Das Projekt ist interessant; allerdings kippt es bei der Kosten /Nutzen Rechnung eindeutig hin zu den Kosten.

Da bin ich eindeutig schneller, mir alle Formeln einmal anzuschauen, mir auf einen Blatt Papier zu notieren, was die so alles machen, mir ein Bier zu trinken und zu überlegen, wie ich die festgestellten Gemeinsamkeiten in eine LS Script Lib übertrage bevor ich mir Gedanken über ein Transpiler Building mache. Wie gesagt, ICH würde diesen Weg beschreiten; DEIN Weg ist ein anderer.

[koehlerbv]

TokenEnde kann immer nur ein ")" sein.

Nö. FIELD xyz := "Hier steht keine Klammer am Ende."

Nur so als Beispiel.

Ansonsten : Volle Zustimmung, Ulrich. Ich hatte das ja auch schon so ähnlich geschrieben: Aufwand / Nutzen steht für mich (! - persönliche Meinung !) in keinerlei Verhältnis. Parser / Converter oder wie auch immer zu schreiben, mache ich äusserst gerne (da kann man so richtig Grips 'reinstecken), aber - wenn erforderlich - stelle ich nicht so sonderlich wesensverwandte Programmiermethoden wie @functions und LS lieber manuell um.

Bernhard

[flaite]

(http://butunclebob.com/ArticleS.UncleBob.TheBowlingGameKata) und Agile Software Development Kapitel 6

I second that a lot. 
Und so ist das auch richtig. Andere Leute finden vielleicht test driven development Unsinn oder theoretisch. Und dann sehen sie es vielleicht irgendwo. Und dann: Oh. Das ist aber sehr professionell. Man kann aber auch einfach irgendwann damit anfangen. Und dann ist es gar nicht so schwierig.

Wie definiert ihr den Begriff "Grammatik"?
Was ich skizziert habe, kann auch als eine Art Grammatik angesehen werden.
Eben eine agile Grammatik.

Ich find heute abend werden mal wieder ein paar sehr starke Aussagen getroffen bevor ich überhaupt angefangen habe.
Ich glaube: Die OOD gibt mir eine ausreichende Flexibilität, um ausreichend auf die variablen Fälle zu reagieren.
Ihr glaubt, das nicht.
Bevor ich nicht angefangen habe, wissen wir es einfach nicht.

Gruß Axel