Eine neue Sprache: NeoLinq (Vorläufiger Titel)

Das Ziel: Eine Lernsprache, die neue Möglichkeiten aufzeigen soll, zu Abstrahieren und einfachen Code zu entwickeln, aber dennoch performant ist - einen guten Compiler vorrausgesetzt. Es soll kein neuer Stern am Firmament der Programmierung werden.

Inspirationen

• Teile von Haskells Typsystem
• Funktionale Programmierung
• Lisps Syntax und Grundgedanke, sich auf das Wesentliche zu beschränken: Funktionen.
• Scalas Konzept, ein reichhaltiges Set an Features bereitzustellen und dem Programmierer die Wahl zu lassen.

Idee:
Der Sprachkern soll NUR die elementaren Bestandteile enthalten und so wenig Konstrukte wie Menschenmöglich beiinhalten OHNE die Ausdruckskraft zu behindern.

Features:

• Operatoren
• Unbekannt. Bis auf wenige Ausnahme können allerdings sämtliche US-ASCII-Zeichen als Bezeichner verwendet werden. + ist z.B. ein gültiger Name für eine Methode von Int. Kein Operator! Auch boolschen Operatoren wird es nur als normale Methoden geben. (Teilweise Scala)
• Keine Operator-Precedence: Folgt daraus. Aller Code wird von links nach rechts ausgewertet. Operatorenreihenfolgen bieten keinen Mehrwert bei der Programmierung. (LISP)
• Namespaces und Scopes
• Maximal gibt es zwei Namespaces: Wert und Typ.  Ob es wirklich einen separaten Namespace für Typen gibt, ist noch ungeklärt.
  
• Uniform Access Principle:  Methoden und Felder teilen sich den selben Namespace. Es gibt keinen syntaktischen Unterschied zwischen den beiden. (Scala, Eiffel)
• Method-Overloading / Multimethods: In einem Scope kann es immer nur eine Methode mit einem Namen geben, die gegen genau einen Typen dispatcht wird. Overloading ist nicht erlaubt  (Eiffel)
• Case-Sensitiv: Horst und horst sind unterschiedliche Bezeichner. In Sprachen mit wenigen Namespaces zwingende Vorraussetzung.
• Nicht technik-getrieben
• Es soll kein neues C entwickelt werden - keine Zugeständnisse an die Technik. Dennoch sollte die Sprache nur Konzepte erhalten, für die zumindest eine einfache und performante Umsetzung denkbar ist - wie sie erst mal dahingestellt. Gegenbeispiel: Go.
  
• Keine Kompatibilität zu JVM o. CLI: Folgt aus dem ersteren. Falls die Sprache jemals fertig würde, könnte man sich immer noch Gedanken darüber machen, mit welchen Modifikationen sie zu vorhandenen RTEs kompatibel werden kann. Gegenbeispiel: Scala.
• Keine Schlüsselwörter
• Die Sprache ist so minimalistisch und generisch wie möglich. Keine Schlüsselwörter, da diese den Compilern die Arbeit erschweren und den Sprachkern weniger generisch machen.
• Sprachkonstrukte durch Methoden: Soweit möglich sollen alle Sprachkonstrukte durch Methoden abgebildet werden (Lisp).
• Ideen für Datentypen
• Technische Basistypen: Int, Float, und wahrscheinlich auch Char und String sowie weitere numerische. To be discussed.
• Parameterlose Funktion (als kompatibles Gegenstück zum Wert. Nicht als Closure verwendbar).
• Funktion mit einem Parameter (echte Closure)
• Gruppierung von Werten durch Tupel und Sequenzen (array-ersatz). Ersetzen mehrere Parameter UND varargs vollständig.
• Typ. Typen sind selbst Datentypen, die Funktionen wie z.B. Subtypisierung u.ä. anbieten.
• Typ mit Parameter, a.k.a. Generics. Der Typ kann durch den "Typkonstruktor" in verschiedenen Ausprägungen manifestiert werden. Realisierung offen, könnte sich an Scala orientieren.
• Unit (=> void). Konstante für das leere Tupel. 
• Kein null!

Weitere Erklärungen und erste Syntaxideen to come...
Wenn ich mehr gesammelt habe werde ich das Ganze mal zur Diskussion stellen. Vllt entwicklen sich ja in größerer Gemeinschaft ein paar Tolle Ideen.