Hi...
An diesem Projekt arbeite ich jetzt seit ungefähr einem halben Jahr:
Eine interpretierte Scriptsprache, die direkt auf die .NET Schicht zugreifen kann.

Die ganze Sache nennt sich Command Script 4, befindet sich im Beta Stadium und kann von SourceForge.net/projects/csc4 unter den Bedingungen der LGPL bezogen werden (inkl. Dokumentation).

CSC4 ist als Anwendungs Kontroll- oder Erweiterungssprache zu verstehen. Indem man die Library in Programme einbindet, erlaubt man seinen Benutzern, Erweiterungen zu schreiben oder die Software ihren Wünschen anzupassen.

Code :

1 2 3 4 5 6 7 8 9 10 11 12 13 14

procedure main{     echo("Hi!")     var name = prompt("NAME:")     if(name = ""){         echo("I'm sure, you have a name...")     }else{         echo("Welcome " & name.ToLower)     } }   procedure prompt(msg){     $Console.Write(msg & "> ")     return = $Console.ReadLine() }

Mehr Beispielcode.

Die CSC4Library implementiert eine eigene Stack-basierte virtuelle Maschine mitsamt Bytecode. Neben Command Script 4 kann auch direkt in Bytecode Assembler oder in einer eigenen Sprache programmiert werden.

Nette Sache.

Dennoch drängt sich bei mir ein Gedanke auf: Wieso wieder etwas Neues? Prinzipiell hat man die Möglichkeit, on the fly, .NET Code zu kompilieren. Ergo kann man beispielsweise C# einbinden, kompilieren und ausführen. Aus diesem Grund spricht eine eigene Scriptsprache nicht sehr für sich.

Berechtigte Frage.

Es gibt sehr viele Argumente, die gegen die Kompilierung von C# oder VB während der Laufzeit sprechen. Z.B.:

• Zeit: Ein CSC4 Script zu kompilieren benötigt um die 30ms, .NET Compiler benötigen wesentlich länger.
• Inkrementelle Kompilierung: Es ist zu jedem Zeitpunkt möglich, eine CSC4 Prozedur zu ersetzen, hinzuzufügen, zu manipulieren oder zu entfernen. Die .NET Compiler müssen jedes mal ein neues Assembly generieren. (-->Speicherbedarf, Overhead bei Verwendung von AppDomains)
• Interaktive Nutzung: CSC4 eignet sich dank eval() Funktion für interaktive Systeme (z.B. Ingame oder Debugging Konsolen)
• Typen müssen beim Übersetzen nicht bekannt sein*. Nachträgliche Änderungen an APIs (z.B. ArrayList anstelle von Array) verlangen keine Änderung am Code.

*Ausnahme: ein Typ muss beim Übersetzen vorhanden sein, wenn er in TypeCasts, Konstruktor- oder Statischen Aufrufen verwendet wird.

Zudem lässt sich die Library recht einfach erweitern.

Code :

1 2 3 4 5 6 7 8

procedure main{     echo(system("global.welcome"))  }   config system{     [global]     welcome="Hello World!" }

In diesem Beispiel wird der "Code" der Prozedur "system" nicht von CSC4 sondern von irgend einem selbst geschriebenen Compiler analysiert/übersetzt.

Natürlich hat auch die C#/VB Methode ihre Vorteile: IL Code ist schneller und immer Typsicher.