Typ-Ausdruckssyntax

Kurzfassung

Pipelang ist die Typsprache, mit der Pipelogic Daten auf jeder Leitung beschreibt — klein, strukturell, rekursiv.
Ein Typ wird aus atomic-Keywords (Int32, Double, String, Bool, …) aufgebaut, zusammengesetzt über composite-Formen — [t] (list), (a, b) (tuple), {x: A, y: B} (record), A | B (union), Name<T> (named-type-Anwendung).
Bezeichner in Kleinbuchstaben (t, a, frame) sind type variables; Bezeichner in Großbuchstaben sind konkrete Namen aus dem catalog.
Die gleiche Grammatik läuft im Plattform-Compiler, in der C++-Laufzeit und im Python-catalog — in component.yml geschriebene Typausdrücke werden identisch geprüft, wo immer sie erscheinen.
Die Seite, die du gerade liest, ist das mentale Modell. Für die vollständige Grammatik, jede Produktion, jede Disambiguierungsregel, jeden ausgearbeiteten Randfall hole die Referenz über die CLI: ppl docs get type-api/type-syntax.

Was dir ein Pipelang-Typ tatsächlich bringt

Pipelang ist der einzige Ort, an dem Pipelogic einen Vertrag vor der Laufzeit durchsetzt. Eine component deklariert input_type: "Image"; eine andere component deklariert output_type: "Image"; die Plattform verbindet sie nur, wenn die Typen vereinheitlicht werden. Es gibt kein „fast kompatibel“, kein JSON-Dict, das an der Aufrufstelle zufällig richtig aussieht, keinen Laufzeit-KeyError bei einem fehlenden Feld — die Leitung wird entweder typgeprüft oder verweigert ihre Existenz.

Die Grammatik ist absichtlich klein, damit diese Prüfung schnell, verständlich und über Sprachgrenzen hinweg konsistent ist. Gleicher Ausdruck, gleiche Bedeutung, egal ob der Produzent Python und der Konsument C++ ist oder umgekehrt.

Die Formen, die du am häufigsten verwenden wirst

Form	Beispiel	Wann du danach greifst
Atomic	`Int32`, `Double`, `String`	Die Leitung trägt einen Skalar.
Named	`Image`, `AudioFrame`, `Tensor`	Die Leitung trägt ein Domänenobjekt aus dem catalog.
List	`[BoundingBox]`	Homogene Sequenz des Elementtyps.
Tuple	`(Image, String)`	Heterogene Sequenz fester Stelligkeit; die Reihenfolge ist wichtig.
Record	`{x: Double, y: Double}`	Benannte Felder; ein Ad-hoc-struct auf der Leitung.
Union	`Image \| DepthImage`	Jede der Alternativen ist für den Konsumenten akzeptabel.
Generic-Anwendung	`Polygon<Double>`, `Maybe<a>`	Ein catalog-Typ, parametrisiert mit einem oder mehreren Typargumenten.
Type variable	`a`, `t`, `elem`	Ein Platzhalter, den die Plattform zur Kompositionszeit bindet (Bezeichner in Kleinbuchstaben).
Refinement	`Int32<0..=255>`, `String<email>`	Ein Basistyp, eingeschränkt durch ein Prädikat — einen Bereich, ein Enum, ein Muster oder einen Format-Alias.

Die Grammatik kombiniert diese rekursiv: [Maybe<{x: Double, y: Double}>] ist eine list optionaler Punkte, jede Form aus der obigen Tabelle zusammengesetzt.

Generic vs konkret: eine Ein-Zeilen-Regel

Wenn der Bezeichner mit einem Kleinbuchstaben beginnt, ist er ein generischer Platzhalter, den die Plattform bindet, wenn die component in ein backend verdrahtet wird. Wenn er mit einem Großbuchstaben beginnt (oder eines der zehn atomic-Keywords ist), ist er konkret. Diese eine Regel deckt das meiste ab, was du im Tagesgeschäft schreiben wirst; alles darüber hinaus — pack variables $ts, pattern expansions T..., field-pack-Expansionen $ns: T..., refinements, die eine Basis durch ein Prädikat einschränken (Int32<0..=255>), und die bounded-Menge oneof[…] — ist für fortgeschrittene Fälle, in denen der Typ variadisch oder eingeschränkt ist.

Wo das hineinpasst

Die Typ-Ausdruckssprache ist der Vertrag zwischen components. Sie ist der Input für den Typprüfer, die Quelle des Konnektivitätsgraphen im visuellen Builder, die Grundlage für die Autovervollständigung im Agent-catalog. Alles, was über components hinweg sichtbar ist — was wohin passt, was nicht — kommt aus dieser Grammatik. Behandle die Typsignatur als die Spezifikation; die Plattform behandelt sie genau so.

Für die vollständige Grammatik

Die Website deckt das Modell und die gängigen Formen ab. Für die vollständige Grammatik mit jeder Produktion, jeder Disambiguierungsregel ((T) vs (T,), T | U vs T |), pack variables, pattern expansions, refinements, dem bounded-Typ oneof[…], Default-Wert-Literalen, Gleichheits- und Kanonisierungsregeln sowie ausgearbeiteten Beispielen für jeden catalog-Randfall hole die Referenz über die CLI:

ppl docs get type-api/type-syntax

Verwandt

/type-api/types — das Typsystem als Plattformkonzept.
/component-api/component-contract — die Datei, die diese Ausdrücke umhüllt.
/type-api/catalog — catalog der eingebauten named types.
/concepts/components — wie eine typisierte component in ein backend passt.