NeoLinq: Tupeldeklarationen

Eine der großen offenen Fragen ist, ob Tupelschnittstellen () zur Deklaration verwenden. Ich experimentiere damit, Typen stehts in [ ] einzuschließen, so möglich. Dann hätte jedes Konzept eine eigene Klammersprache:

(): Auswertungsreihenfolge
{}: Blockdefinition. Codeblöcke für spätere Ausführung.
[]: Typendefinition. Codeblöcke für spätere Ausführung UND public interfaces.


NUR durch Typen ist es möglich, zwischen Scopes zu wechseln! Das normale Scoping sieht vor, dass Namen nach unten durchlässig sind, d.h. in jedem Block sind die Werte der darüberliegenden Scopes bekannt, so sie nicht durch Name Shadowing, d.h. überlagen mit gleichen Namen, unsichtbar sind. Typen hingegen haben die Aufgabe, Schnittstellen nach oben sichtbar zu machen.

Zurück zu den Tupeln:
Es ist immer noch nicht definiert, was Tupel eigentlich sind. Was für eine Art von Typ stellen sie dar? Wenn man Tupel mit der []-Syntax für Typen deklariert, dann müssen Tupel vollwertig ins Typsystem passen bzw. DAS TYPSYSTEM ALS SOLCHES ERWEITERN. Verwendet man die ()-Syntax bei der Deklaration, dann werden Tupel nur als ein Typ unter vielen gesehen.
Anders formuliert:

[a: String, b: Int] oder (a: String, b: String)?


Wenn man das ganze so sieht scheint die zweite Variante besser zu sein. Tupel sollen Werte gruppieren und stellen eine Klasse von Typen dar. Aber die Mengen-Eigenschaft eines Tupels generisch auf einen Typen zu übertragen fühlt sich einfach falsch an.


Aber es gibt ja noch ein Konstrukt:
Ebenso wie das Typsystem ist auch das PatternMatching noch nicht ausformuliert, auch wenn es meiner Meinung nach ein ebenso fester Bestandteil sein muss.
PatternMatching kann große Auswirkungen auf Tupel haben: Genaugenommen ist (a: String, b:String) zum einen eine Deklaration, zum anderen aber ein Muster zum Zerlegen eines Typs in Variablen, inkl. (optionaler) Typannotationen.


Wenn aber Tupel-Deklarationen ein Sonderfall des Matching sind, dann sollte man versuchen, die Deklarationsyntax  daran zu orientieren. Vllt. bietet das Int* Konstrukt neue Ideen für das Matching von Mengen! Für Tupel wäre es auf jeden Fall erforderlich..