ZFX + Developia

gwXscript ist eine objektorientierte, aspektorientierte Programmiersprache, die sowohl Executables (ELF, EXE) als auch dynamische Bibliotheken (DLL, SO, DYNLIB) erzeugen kann. Der Compiler ist in seiner eigenen Sprache implementiert und übersetzt den Scriptcode in LLVM-IR, welcher vom LLVM-Framework optimiert und anschließend in nativen Code übersetzt wird. Quellcodedateien in gwScript enthalten Definitionen, die den Namensraum erweitern. Somit kann man sein Projekt so aufbauen, dass man gewisse Features 'herausnehmen' kann, indem man einfach eine Datei herauslöscht. Das restliche Projekt hinterlässt keine Narben, da man die einzelnen Concerns dank 'templates' konkreten Dateien zuordnen kann. So ist es zum Beispiel auch möglich, neue Features hinzuzufügen, indem man dem Projekt Dateien hinzufügt. Das eigentliche Projekt muss man dabei nicht anfassen. Benutzt wird diese Sprache zum Beispiel, um Spiele mit Erweiterungsmöglichkeit zu erstellen.

gwXscript ist streng getypt und bietet Komfort mit seinen nativen Datentypen string, hash und array.
Man kann die Scripte um in nativem Code geschriebene Funktionen erweitern. gwXscript ist typsicher und der Nutzer sollte nicht in der Lage sein,
das Programm zum Absturz zu bringen oder bösartigen Code auszuführen.

Weitere Features sind:

- Objektorientiert, Vererbung, Polymorphie
- Private und Readonly-Attribute
- Operatorüberladung
- Datentypsensitive Überladung
- Speicherbereinigung
- Native Klassen
- Zuweisen mehrerer Index[]-Funktionen für Objekte (und Index[]:=-Setter)
- Hook-Pools (template)
- Closures

http://botwars.tk/gwscript/

In gwXscript implementierte Projekte:
- Komplette Spiellogik von GoldenWipf Extreme (http://goldenwipf.de)
- Der Compiler selbst

Der Compiler bootstrappt sich selbst in 700ms. Bis die fertige Executable bereitsteht, muss aber das LLVM-Backend allerdings noch 16 Sekunden lang den Code optimieren und daraus nativen Code erzeugen.

Weitere FAQ:
Q: Warum noch eine Programmiersprache?
A: Weil ichs kann.

Nabend,

klingt echt interessant.
Kann man mal etwas mehr Script-Code sehen als dieses Hello-World Programm?
Mich würde nämlich mal interessieren wie man da aspektorientiert programmiert.

Gruß

joggel hat geschrieben:Nabend,

klingt echt interessant.
Kann man mal etwas mehr Script-Code sehen als dieses Hello-World Programm?
Mich würde nämlich mal interessieren wie man da aspektorientiert programmiert.

Gruß

Aspektorientierung fängt leider (oder zum Glück) erst bei ziemlich großen Projekten an.
Ein Paradebeispiel, das ich immer nenne, ist der Editor von gwX: Der Editor besteht aus verschiedenen Tools und jedes Erweiterungspack von gwX kann neue Editor-Werkzeuge in die Palette eintragen.
Hier ist das Sourcecode-Verzeichnis des Editors:
https://bitbucket.org/carli/toastengine ... ers/editor

Um mal konkret zu werden: Der ObjectRemover ist ein Stift, mit dem man Objekte aus der Map entfernen kann.
https://bitbucket.org/carli/toastengine ... ectremover
In Zeile 1 deklariert man eine Klasse und in Zeile 3 registriert man diese Klasse in die Palette. Keine extern verwalteten Tool-Listen, an denen man an mehreren Stellen Code ändern müsste.

Gesteuert wird die Aspektorientierung von wenigen wichtigen Framework-Dateien, wie z.B. dem Szenario:
https://bitbucket.org/carli/toastengine ... c/scenario
In den ersten 3 Zeilen sieht man eine sog. Hook-Straße, in der Erweiterungen Code mit einer gewissen Priorität hineinladen können (allerdings nur auf festgelegte Anzahl), das geht deshalb, weil es in gwScript unwichtig ist, in welcher Datei eine Definition steht.
In Zeile 21 und 24 sieht man dann die Templates, die hier zur Initialisierung genutzt werden. Templates sind technisch gesehen funktionale Pattern über der Sprache zur Compilezeit. Softwaretechnisch gesehen bekommt man damit die "Separation of Concerns" hin, da man den gesamten Code, der zu einem Concern gehört in eine einzelne/n Datei/Ordner zusammenstecken kann. (Meistens eine Klasse und ein Hook oder 2 Attribute für jeweils zwei Klassen und entsprechenden Komfortfunktionen)

Durch die aspektorientierte Programmierweise wird auch gewährleistet, dass zwei unabhängig voneinander entwickelte Erweiterungen gemeinsam kombinierbar sind. (zum Beispiel ein Szenario "Ritter gegen Cowboys")

Interessant finde ich, dass ich keine Semikolons sehe. Wolltest du damit Cs Sequenzierungsproblematik loswerden oder waren die für die Syntax einfach überflüssig?

Ist LLVMs Optimierung und Texterzeugung von Werk aus zufriedenstellend, oder musstest du erst noch dran rumschrauben?

… und Respekt für eine einsatzfähige Sprache von jemandem, der immernoch beim AST festhängt.

Krishty hat geschrieben:Interessant finde ich, dass ich keine Semikolons sehe. Wolltest du damit Cs Sequenzierungsproblematik loswerden oder waren die für die Syntax einfach überflüssig?

Sie waren überflüssig. Wer reflexartig Semikolons schreibt, auch nicht Schlimm. Semikolons gelten mit als Whitespace.

Krishty hat geschrieben:Ist LLVMs Optimierung und Texterzeugung von Werk aus zufriedenstellend, oder musstest du erst noch dran rumschrauben?

[/quote]
Ich habe noch nicht daran herumgeschraubt, sehe aber jede Menge Verbesserungspotenzial (falls ich mich dann nach der Library-Fertigstellung in die Benchmark-Battles stürzen will)

Noch eine Projektankündigung: Wir haben jetzt MySQL-Bindings und man kann gwscript jetzt auch als (eine etwas schnelle) CGI-Sprache benutzen. Iteratoren für MySql-Ergebnisse... der MySql-Wrapper ist möglichst an die nativen Datentypen von gwscript angepasst.

Herunterladbar auf http://bitbucket.org/carli/gwscript

What's new:
- JSON lesen und ausgeben
- JavaDoc-ähnliche Dokumentationstags, die als JSON ausgespuckt werden
- Massive String-Optimierungen (sind ins LLVM-Projekt eingeflossen, machen also clang auch schneller)
- Framework für Web-APIs (sowohl JSON-Basiert als auch HTML-Basiert)
- Stdlib mit random und Float-Funktionen (parse und toString) fertiggestellt
- Komfortfunktionen Operator| für Strings (entspricht dem format() in C)

*thumbs up*

Neu ist jetzt auch eine Bibliothek, mit der man gwscript als JIT-Code in seine Applikation einbinden kann. Header sind erhältlich für C und Pascal.
Dabei wird wieder das mächtige LLVM-Framework genutzt mit seiner lazy compilation.

Schon LLVM 3.0?

Genauer gesagt LLVM 3.1svn, aber ist so weit mit 3.0 kompatibel.
Das 3.0-er Release kommt ja bald, dann kann ich so langsam anfangen, das ganze nach Windows zu portieren.

[Edit:]Falls du die Release Notes von LLVM 3.0 meinst, ja das ist diese Sprache ;)

So,

gwscript hat jetzt auch ein vim-Syntaxfile.