Files
Chili Palmer d0461bea34 OpenSpec: phase-3-runtime-bildschirm archiviert, Delta-Specs gesynct
Zwei neue Capabilities in den Hauptspecs:
- datei-eio: Dateiverwaltung, drei Zugriffsarten, UTF-32-Festtextfelder,
  Recordkonvertierung, Sperren, Dateisystem-Anweisungen
- sprachinventar: das Vollstaendigkeits-Inventar als pruefbares Artefakt

Fortgeschrieben: textbildschirm (Doppelzellen, Groessenunabhaengigkeit,
Bildschirmanweisungen), konsolen-basisbibliothek (Host-Neuschnitt, volle
String-/Format-/Datums-/Finanzbibliothek), kompat-testkorpus
(Snapshot-Vergleich, Nachweis der Groessenunabhaengigkeit),
sprach-frontend (Signaturpflicht, ON-ERROR-Scoping, DATA-Rohtext).

Bilanz: +32 Anforderungen, 6 geaendert, 1 ersetzt.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-09-04 06:55:02 +02:00

2.9 KiB

ADDED Requirements

Requirement: Jedes dokumentierte Element besitzt eine Signatur

Die Semantik SHALL für jedes im Sprachinventar geführte Element eine Signatur besitzen (Argumentanzahl und -typen) — auch für Elemente, deren Laufzeitverhalten noch aussteht. Ein im Inventar geführtes Element MUST NOT als unbekannter Bezeichner oder mit einem generischen Syntaxfehler abgewiesen werden; die Diagnose bzw. der Laufzeitfehler MUST es namentlich nennen (Guiding Principle). Das gilt insbesondere für die Gruppen, die bisher gar keine Signatur haben: die finanzmathematischen Funktionen, die Record-Konvertierungsfunktionen (MK…$/CV…), die Dateisystem-Funktionen CURDIR$, DIR$, CHDRIVE, sowie LPOS, STACK, SYSTEM, ERDEV/ERDEV$ und SetFormatCC.

Scenario: Element ohne Laufzeitverhalten wird namentlich abgewiesen

  • WHEN ein Modul eine im Inventar als offen geführte Funktion verwendet
  • THEN nennt die Ablehnung deren Namen und nicht „unbekannter Bezeichner"

Scenario: Argumentprüfung ohne Laufzeitverhalten

  • WHEN ein Modul MKL$() ohne Argument enthält
  • THEN meldet die Semantik eine Argumentanzahl-Diagnose, die MKL$ nennt

Requirement: Modulweites ON ERROR ist aus Prozeduren ansprechbar

ON ERROR GOTO label ohne LOCAL SHALL einen modulweiten Fehlerhandler setzen, dessen Sprungziel auch dann aufgelöst wird, wenn die Anweisung in einer Prozedur steht und das Label auf Modulebene liegt. Nur ON LOCAL ERROR GOTO label SHALL prozedurlokale Handler-Auflösung verlangen. Ein modulweites ON ERROR in einer Prozedur MUST NOT wie ON LOCAL ERROR behandelt werden, und ein auf Modulebene vorhandenes Label MUST NOT als „Label not defined" gemeldet werden.

Scenario: Handler auf Modulebene aus einer Prozedur

  • WHEN ein Modul das Label Fehler: auf Modulebene führt und eine SUB die Anweisung ON ERROR GOTO Fehler enthält
  • THEN wird das Label aufgelöst und es entsteht keine Diagnose

Scenario: ON LOCAL ERROR bleibt prozedurlokal

  • WHEN eine SUB die Anweisung ON LOCAL ERROR GOTO Fehler enthält und Fehler: nur auf Modulebene existiert
  • THEN wird „Label not defined" gemeldet

Requirement: DATA-Elemente behalten ihren Rohtext

Unquotierte Elemente einer DATA-Anweisung SHALL exakt so erhalten bleiben, wie sie im Quelltext stehen — insbesondere in ihrer Groß- und Kleinschreibung. Die Normalisierung von Bezeichnern MUST NOT auf DATA-Elemente wirken. Führender und nachgestellter Leerraum eines unquotierten Elements SHALL entfernt werden, innenliegender erhalten bleiben.

Scenario: Gemischte Schreibweise bleibt erhalten

  • WHEN ein Modul DATA Hallo Welt enthält und READ s$ ausgeführt wird
  • THEN enthält s$ den Text Hallo Welt mit unveränderter Groß- und Kleinschreibung

Scenario: Leerraum an den Rändern

  • WHEN ein Modul DATA ab cd enthält und gelesen wird
  • THEN lautet der Wert ab cd