NeoLinq: Basics

1. Definitionen:


// kommentar => kommentar.
name = Wert     // definiert einen unveränderlichen wert. Der Bezeichner steht also ab jetzt für Wert.
name := Wert     // definiert auch einen wert, aber einen veränderlichen. Es handelt sich also nicht um eine Gleichsetzung,  sondern eine Zuweisung.
fun = {}     // definiert eine parameterlose funktion mit dem rückgabewert ()
argfun = { i :Int -> i + 2 }     // definiert eine funktion mit dem parameter i vom Typ Int und dem Rückgabewert i + 2 vom Ty
val = argfun 3 // val erhält den rückgabe wert von argfun, aufgerufen mit dem parameter 3. das ergebnis: 5.


Beispiele:


wert = 2
inkrement = { i: Int -> i + 1 }
ergebnis := inkrement wert    // 3


Und jetzt mal was krankes mit nem Haufen neuer Syntax:
doppelEffektPlusEins = { (wert: Int, f: {Int -> Int}) ->
   f (f wert) + 1
}


// ergebnis (variable) überschreiben
ergebnis := doppelEffektPlusEins (ergebnis, inkrement)




Das Ganze hat viel mit Smalltalk zu tun:
1. Auswertungsreihenfolge: Starr von links nach rechts. Durch Klammern beeinflussbar
2. Reine Infix Notation. Keine Punkte als Trennzeichen, stattdessen whitespace
3. Operatoren sind einfach Mehodennamen
4. Blöcke, d.h. Funktionen werden als Werte definiert und sind ausführbar. Sie können als echte Closures auf alle Werte der äußeren Scopes zugreifen und diese beeinflusse.
5. Keine Schlüsselwörter. Diese können über Funktionen abgebildet werden.

Funktionale Gedanken:
1. Daten sind immutable. ABER: Imperative Zuweisungen und Definition sind mit der := Syntax, die explizit Varablen deklariert, möglich.
2. Typsystem: Tupel sind echte Datentypen. Typen werde a la Scala annotiert. Typen stehen im Vordergrund, keine Klassen. Vllt sind diese aber nachher dasselbe...

"Mein Zeuch"
1. Es gibt Blöcke mit einem Parameter und ohne. Mehrere Parameter sind nur ein Sonderfall: Hier wird ein Tupel mit festen Typen definiert. Varargs werden ähnlich behandelt werden.
2. Durch Klammern lässt sich die Verarbeitungsreihenfolge beeinflussen. Die Aufgabe ist hier und bei Tupeln aber dieselbe: Klammern vereinigen Werte. Die Kommas bei Tupeln stellen davon nur lediglich einenSsonderfall dar, da hier nicht mehrere Dinge in einen Wert verwandelt werden, sondern mehrere Werte parallel existieren.


Ich weiß noch nicht genau wo meine Ideen hingehen. Es sieht aber doch sehr stark nach OO aus, aber auch mit einer strukturellen Komponente. Wahrscheinlich Scala sehr ähnlich: Strukturelles Typsystem, dass Nominelle Typen (Klassen) ermöglicht und OO-Subtypisierung erlaubt. Und am Ende steht dann irgendwann ein "vereinfachtes" Scala (weil nicht JVM-Kompatibel und es nicht implementiert wird). Wenns gut läuft..