CSC4, eine interpretierte .NET Scriptsprache

[Sunray]

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.

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.

 

[Norbert Eder]

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.

 

[Sunray]

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.

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.