Haupt-Projekt "SyntaxExpressions"
Soll das Parsen von nahezu jeder Script-Sprache ermöglichen,
in dem bis hin zu den kleinsten Bausteinen alles auseinander
genommen und wieder individuell zusammen gefügt werden kann.

Unter-Projekt "CodeShredder" (Step 1)
Script anhand von Regex-Pattern gezielt in alle Bausteine zerlegen.
Liest den SourceCode aus einem String oder einer existierenden Datei
und gibt eine Auflistung mit allen gefundenen Bausteinen,
sowie deren Start- und End-Positionen zurück.

CodeShredder v1.1.1 (07.08.2012)
- Einleitung
- SHRED und NOSHRED
- Komplexe Verschachtelungen

CodeShredder - Einleitung

Zu erst muss der Shredder initialisiert werden

Als Consolen-Anwendung gibt es die Debug-Option

Nun müssen die Muster hinzugefügt werden, nach denen gesucht werden soll.
Der Aufruf der Funktion ist: AddPattern(Name, RegexPattern, RegexOptions)
Das benutzte Pattern (Muster) ist ganz simpel und sucht nach allen normalen Wörtern.

Einfachste Art einen Code zu laden:

"myShredderResult" besitzt 3 Variablen auf die zugegriffen werden kann:
".OriginalText" - hat den den Code gespeichert, wie er vor dem Zerlegen war.
".ResultText" - ist der Code der nach dem Zerlegen übrig geblieben ist.
".Matches" - ist letzt endlich die Auflistung aller gefundener Bausteine.

".Matches" ist eine Sortedlist mit einem Integer als Schlüssel.
Dieser Schlüssel ist zugleich die Position im Code an der der Baustein anfängt.

Die Werte der Sortedlist haben den Typ "ShredderMatch". Dieser Typ hat folgende Member:
".Name" - Der Name des Musters mit dem dieser Baustein gefunden wurde.
".Range" - Bietet Angaben über Start und End-Position des Gesamten Bausteins.
".Groups" - Hier befinden sich Schließlich alle gefundenen Gruppen.

Eine gefundene Gruppe ist vom Typ "ShredderGroup" und hat folgende Member:
".Name" - Der Name der Gruppe
".Value" - Inhalt der Gruppe
".Range" - Wie oben auch.

Jedoch kurz zurück zum Hinzufügen der Muster.
In unserem Falle hat das Muster den Namen "IfThenEndif".
Die einzelnen Zeilen des Pattern bedeuten:


Das Script arbeitet also nur mit "ResultText", geht alle zuvor eingegebenen Pattern durch, speichert die gefundenen Sachen, ersetzt den Teil in "ResultText" mit Space und sucht dann weiter.

Nehmen wir dazu unseren Test Code von ganz oben: "if a then if b then c endif endif"
Nach und nach werden alle Wörter gefunden. Das sieht in etwa so aus:

In "myShredderResult.Matches" stecken also nun die 9 Bausteine.
Sie alle haben den Namen "IfThenEndif". Logisch, denn sie alle wurden mir diesem Muster gefunden.

Die zugehörigen Schlüssel (Da es sich um eine Sortedlist handelt) sind folgende:
myShredderResult.Matches.Keys(0) = 0
myShredderResult.Matches.Keys(1) = 3
myShredderResult.Matches.Keys(2) = 5
myShredderResult.Matches.Keys(3) = 10
myShredderResult.Matches.Keys(4) = 13
myShredderResult.Matches.Keys(5) = 15
myShredderResult.Matches.Keys(6) = 20
myShredderResult.Matches.Keys(7) = 22
myShredderResult.Matches.Keys(8) = 28

Wir erinnern uns an das Muster mit dem Pattern. Dort werden
die Wörter ebenfalls gespeichert durch: \b(?<Word>\w+)\b

Jedes Match besitzt somit je eine Gruppe. Und jede davon hat somit den Namen "Word".
Die Werte für die Gruppen sind:
myShredderResult.Matches.Values(0).Groups("Word").Item(0).Value = "if"
myShredderResult.Matches.Values(1).Groups("Word").Item(0).Value = "a"
myShredderResult.Matches.Values(2).Groups("Word").Item(0).Value = "then"
myShredderResult.Matches.Values(3).Groups("Word").Item(0).Value = "if"
myShredderResult.Matches.Values(4).Groups("Word").Item(0).Value = "b"
myShredderResult.Matches.Values(5).Groups("Word").Item(0).Value = "then"
myShredderResult.Matches.Values(6).Groups("Word").Item(0).Value = "c"
myShredderResult.Matches.Values(7).Groups("Word").Item(0).Value = "endif"
myShredderResult.Matches.Values(8).Groups("Word").Item(0).Value = "endif"

Und das war es auch schon. Mehr macht der Shredder nicht,
aber das was er macht, macht er bestens und in einer Art,
die auf allzu jeden Syntax anwendbar ist.

CodeShredder - SHRED und NOSHRED

Nehmen wir als Beispiel folgendes Muster:


Die Gruppe von SHRED wird komplett im ResultText mit leerem Raum überschrieben. Dies kann manchmal ungewollt Auswirkungen haben. Denn die Blöcke für die If-Anweisung und die Then-Befehle können noch Sachen beinhalten die weiter zerlegt werden müssen. Sie müssen also irgendwie im ResultText bleiben, sodass nur "if", "then" und "else" gefunden und ersetzt werden.

Diese möglichkeit gibt uns NOSHRED. Es gibt an, dass der Inhalt dieser Gruppe wieder zurück geschrieben werden soll, damit er evtl weiter zerlegt werden kann. Es ist auch kein Problem, den Inhalt dieser NOSHRED-Gruppen trotzdem speichern zu lassen.

(?<if>(?<NOSHRED>.*?))
Speichert in dem Match des Types "IfThenEndif" eine Gruppe mit dem Namen "if" und den Inhalt dieser Gruppe. Gleich darauf befindet sich darin die NOSHRED Gruppe.

(?<NOSHRED>.*?)
Dies jedoch speichert nichts und gibt sofort an, dass der Inhalt wieder dahin soll wo er her kam.

CodeShredder - Komplexe Verschachtelungen

Wärend ich dieses Beispiel erarbeitete stieß ich auf einen kleinen Bug, der behoben wurde.
Für dieses Beispiel ist v1.1.1 oder höher erforderlich.

Dieses Beispiel zeigt, wie es möglich ist sogar schwierige Sachen wie if-then-elseif-elseif-elseif-else-endif zerlegen zu lassen.

Das einzige benutze Muster
Hier der Test Code

Und hier die Ausgabe

Frage 1, die ich mir gerade stelle:

Die gefunden Sachen werden in ShredderResult.Matches gespeichert
und zwar immer (int)StartPos => (ShredderMatch)Match

Das hat die Vorteile, dass man zum Durchgehen eine "For"-Loop anstelle einer "For Each"-Loop benutzen kann und somit sofort Zugriff auf ShredderResult.Matches.Keys(i) (StartPos) und ShredderResult.Matches.Values(i) (Match) hat.
Ausserdem ist alles der Reihe nach geordnet.

Schwierig wird es nur wenn man mehrere Muster hat und zB nur die Matches von "IfThenElse" wissen will. Dann muss man trotzdem alles einmal durchlaufen und die gefundenen Matches zwischen speichern.

Wäre es also besser
ShredderResult.Matches
von
Sortedlist(Of Integer, ShredderMatch)
in
Sortedlist(Of String, List(Of ShredderMatch))
zu ändern?

Dann kann man sofort das was man sucht per ShredderResult.Matches("IfThenElse") finden. Allerdings ist dann nichts mehr nach der Reihe sortiert...

Es kommt auch darauf an, welcher Weg besser ist um die Bausteine weiter verarbeiten zu können. Und da komme ich auch schon zu meiner Frage 2, die mir im Kopf rumschwirrt...

Ursprünglich hatte ich geplant eine Klasse pro Aufgabe zu erstellen. "Shredder" sollte nur dafür gedacht sein, um den Originalcode in alle kleinsten Teile zu zerlegen um sie mit der nächsten geplanten Klasse "Sweeper" wieder vereinzelt aufzusammeln und in hierarchische Form zu bringen.

Ist es von der Projektgestalltung her akzeptabel oder wäre es sinnvoller eine Klasse für beide Schritte zu benutzen? Fakt ist, dass der Algorithmus von "Shredder" so wie er ist durchlaufen muss, damit die Sachen verarbeitet werden können. Es gbt also keine Möglichkeit Teile aus dem geplanten "Sweeper" mit in die Schleifen von "Shredder" einzubauen.

ist das nicht ziemlich inperformant RegEx zu verwenden? RegEx 1x im Code zu verwenden ist schon aufwändig, dann aber noch so oft? Da doch lieber den Parser komplett selbst schreiben...

Hmmm wegen irgend einem doofen Fehler darf ich alles nochmal schreiben -.- Okay... LetzeGo...

Regex ist nur so schnell wie man es benutzt, bzw arbeiten lässt. Habe sogar erlebt, dass man mit nur einem Pattern alles lahmlegen kann, aber auch Situationen in denen seeeeeeeehr lange Texte recht schnell und effizient durchsucht werden.

Hab beim Bearbeiten eines Posts den Text wohl gelöscht, aber... In dem Text stand, dass ich nicht sage, dass dies die beste Lösung wäre, nicht die schnellste, nicht die schlauste. Aber es gibt die Möglichkeit durch nur ein paar Pattern den Syntax anzupassen.

Klar kann man auch einen eigenen Parser für schnelle sachen basteln. Ich selbst hatte mal einen HTML-Parser der nen kompletten Stammbaum zurückgab, mit Fehlerüberprüfung (Da es sich um ein Bot-Projekt für ein Mmorpg handelte xD). Und ich kann dir sagen, dass die Variante Substring-Für-Substring-auswerten genauso aufwendig ist... Gibt aber noch die Möglichkeit nur Zeile für Zeile zu bearbeiten, was allerdings nicht überall anwendbar ist. Selbst wenn... Müsste ich dann mein eigenes Muster-Erkennungssystem basteln um Syntax-übergreifendes Parsing zu gewärleisten. Ich würde dann nichts anderes machen als... Regex neu erfinden. Und das ist meiner einung nach auch doof

sry mit "aufwändig" meinte ich "rechenaufwändig". weil regex ja schon ein parser ist. klar sind eigene parser "arbeitsaufwändiger"

Die Frage ist aber auch, was man möchte. Was man haben möchte und was man machen möchte und wie man es möchte.

Entstanden ist dieses Projekt eigentlich dadurch, dass ich aus Langeweile mal wieder ein Warcraft3 Map-Projekt starten wollte und dort mit der gegebenen Scriptsprache arbeiten muss. Dazu wollte ich mir ein Tool schreiben, dass das normale MapScript und geschriebene UserScripts vereint. Dazu bräuchte ich allerdings 2 Parser. einen für das Original, einen für die UserScripts. Dann viel mir ein, dass es bereits diverse Tools mit UserScriptSyntax gibt, die mir allerdings nicht gefallen, wesswegen ich mein eigenes schreiben wollte. Sollte ich diese Syntaxe Dritter ebenfalls supporten? Dann bräuchte ich dafür ja ebenfalls je einen eigenen Parser. Und da begann dieses Projekt. Ein einziger Parser, der immer gleich arbeitet, immer das selbe liefert und nur durch Pattern "eingestellt" werden muss.

Selbst wenn es von der Benutzung her ablehnend sein sollte, so stelle ich immer noch den SourceCode bereit um damit vielleicht jemandem helfen zu können. Dies ist auch nicht mehr die aktuellste Version. In meiner Momentanen befinden sich zahlreiche Bugfixes und ich versuche gerade vom Aufbau der Schleife(n) das ganze zu beschleunigen. Doof nur, dass meine Kenntnisse in solchen .NET Sachen noch nicht so groß sind, muss also erst diverse Sachen ausprobieren =)

Derzeitiger Status:
ShredderV2 ist in Arbeit und wird erst dann veröffentlicht, wenn auch der Sweeper fertig ist. Denn alleine mit dem jetzigen können viele bestimmt noch nicht viel anfangen =) Der Shredder hat alleine die Aufgabe den Code zu zerlegen, der Sweeper sammelt dann die Bausteine wieder systematisch(!) auf.

Es bleibt bei der Idee mit 2 Schritten und je einer Klasse, denn somit kann beides unabhängig von einander entwickelt und verbessert werden. Da der Code erst bis aufs letzte zerlegt werden MUSS ist es unmöglich alles in einem Schritt zu tun.

Desweiteren bleibe ich bei der Idee Regex zu benutzen. Derzeitiger Test mit 7000 Zeichen und knapp 400 Zeilen wird, fast problem los, schneller als erwartet zerlegt. Fast problemlos, denn einziges Problem ist derzeit folgendes:

Pattern die nach Verschachtelungen suchen, bei denen aber von vornherein oder am Ende nichts mehr gefunden wird, verursachen einen extremen Lag, je größer der Code, desto noch größerer der Lag.

Ein Pattern beispielsweise ist:
Klein, aber oho... Das Problem liegt in der ersten Zeile bei .* Dies wird benutzt, um auch wirklich Verschachtelungen von innen nach außen zu finden. Ansonsten könnte auch folgendes gefunden werden:


Das .* sucht gierig, womit die ersten beiden "globals" ausgelassen werden. Allerdings ist die Gier auch die Ursache die den Lag verursacht, denn es wird so lange hin und her gesucht bis Regex wirklich sicher ist dass nichts mehr zu finden ist.
Stellen wir uns vor, wir haben 3 Zeilen:Und nun suchen wir immer nach 2 Reihen mit "aaa", egal was davor, dazwischen und danach kommt. In diesem Falle bekommen wir diese 3 Treffer: Bei 4 Zeilen mit "aaa" wären es dann schon 6 Treffer. Und bei 700 Zeilen?

Idee zur Problem Behebung? Nein, ich bleibe bei Regex, sowie ich bei dem .* bleibe. Derzeitige Idee ist ein Wrapper für Regex der Timeout unterstützt. Allein 200ms würden als Teimout reichen, nein, ich würde sogar sagen, dass 200ms schon viel zu viel sind. Denn selbst meine derzeitig 7000 Zeichen werden so schnell geparst, dass ich die Debug-Nachrichten in der Console nicht mal lesen kann.

Edit: Gerade gelesen, dass NET4.5 bereits Timeout unterstützt