Lyx – Bedingungen (if / else / match)

Bedingungen steuern den Kontrollfluss in Lyx. Sie erlauben es, Codeblöcke nur dann auszuführen, wenn eine bestimmte logische Voraussetzung erfüllt ist.

→ Schleifen · Pattern Matching · Sprachsyntax

Eine if-Bedingung erwartet einen Ausdruck, der zu bool oder qbool evaluiert.

if (altitude < 1000) {
    ActivateLandingGear();
} else if (altitude > 40000) {
    ReduceThrust();
} else {
    MaintainFlight();
}

• Klammern: Die Bedingung muss in runden Klammern stehen.
• Blöcke: Geschweifte Klammern { } sind auch bei einzeiligen Anweisungen Pflicht.
• Vergleich: Lyx verwendet = für Gleichheit (nicht ==) und := für Zuweisung. So ist eine versehentliche Zuweisung in einer Bedingung strukturell unmöglich.

var speed: int64 := 250;

if (speed = 250) {
    PrintStr("Reisegeschwindigkeit\n");
}

// Ungleich
if (speed != 0) {
    PrintStr("Flugzeug bewegt sich\n");
}

// Kleiner/größer
if (speed > 300 | speed < 50) {
    PrintStr("Außerhalb Normalbereich\n");
}

Lyx verwendet & und | — nicht && und ||. Beide Seiten werden immer ausgewertet (keine Short-Circuit-Evaluation per Default). Für Short-Circuit-Auswertung: Bedingungen in separate if-Blöcke verschachteln.

import std.io;

fn Check(x: int64, y: int64): void {
    // Beide Operanden werden immer ausgewertet
    if (x > 0 & y > 0) {
        PrintStr("beide positiv\n");
    }

    if (x < 0 | y < 0) {
        PrintStr("mindestens eines negativ\n");
    }

    if (!(x = y)) {
        PrintStr("ungleich\n");
    }
}

fn main(): int64 {
    Check(3, 5);
    Check(-1, 2);
    Check(4, 4);
    return 0;
}

Lyx verwendet nil (nicht null) für den Abwesenheitswert optionaler Typen:

// Optionaler Sensor — kann nil sein
var sensor: ^SensorData := nil;

// Erst auf nil prüfen, dann zugreifen
if (sensor != nil) {
    ProcessData(sensor^.value);
}

// Alternativ: Nil-Koaleszenz-Operator
var safe_sensor: ^SensorData := sensor ?? ^DefaultSensor;

In DAL-A/B-Code sollten optionale Pointer durch typsichere result-Rückgaben ersetzt werden — nil-Checks sind fehleranfällig und schwer zu analysieren.

if kann als Ausdruck verwendet werden, wenn beide Zweige denselben Typ zurückgeben:

fn Abs(x: int64): int64 {
    return if (x < 0) { -x } else { x };
}

fn ClampLabel(v: int64): pchar {
    return if (v < 0) { "negativ" } else if (v = 0) { "null" } else { "positiv" };
}

Lyx unterstützt den Typ qbool für probabilistische Logik — z.B. für Energie-Aware-Entscheidungen oder Wahrscheinlichkeits-Simulationen.

// 1% Ausfallwahrscheinlichkeit
var failure_prob: qbool := 0.01q;

if (failure_prob) {
    // Dieser Block wird mit ~1% Wahrscheinlichkeit ausgeführt
    TriggerEmergencyRoutine();
}

qbool ist kein Ersatz für normale Bedingungen in Safety-kritischem Code — es ist ein Werkzeug für probabilistische Modellierung im Energy-Aware-Programmiermodell.

→ Ausführlich: Energy-Aware-Programmiermodell

Für Enum-Fallunterscheidungen und strukturierte Typen bietet Lyx match als typsichere Alternative zu langen if/else if-Ketten.

match (flight_state) {
    case State.Idle    => { PowerOn(); }
    case State.Taxiing => { SetFlaps(10); }
    case State.InAir   => { RetractGear(); }
    default            => { LogError(); }
}

• Exhaustiveness: Der Compiler prüft (v0.9.0+), ob alle Enum-Werte abgedeckt sind. Fehlt ein Wert, ist es ein Compile-Fehler.
• Kein Fallthrough: Im Unterschied zu C/Java gibt es kein implizites Durchfallen zwischen Fällen.
• _ ist der Wildcard-Fall (entspricht default).

→ Vollständige Dokumentation: Pattern Matching

Für Luftfahrt-Zertifizierung (DAL A/B) reicht Branch-Coverage nicht aus — gefordert ist Modified Condition/Decision Coverage (MC/DC).

// Drei Bedingungen — für MC/DC braucht man 4 Testfälle (nicht 8)
fn IsLandingAllowed(gear_down: bool, speed_ok: bool, runway_clear: bool): bool {
    return gear_down & speed_ok & runway_clear;
}

Der Compiler instrumentiert alle Bedingungen für MC/DC-Analyse:

// Build mit MC/DC-Instrumentierung:
// lyxc --mcdc-instrument --coverage-report=cov.json src/flight.lyx
//
// Nach dem Testlauf Coverage-Report erzeugen:
// lyxc --coverage-report-html=report/ cov.json

Jede Teilbedingung in einem zusammengesetzten Ausdruck muss unabhängig das Gesamtergebnis beeinflussen können. Der Report zeigt welche Test-Vektoren dies nachweisen.

→ Vollständige Dokumentation: DO-178C Compliance

Letzte Aktualisierung: 2026-05-22