Files
TerminalBasic/tests/compat/README.md
Chili Palmer 333e794540 Phase 1: Sprach-Frontend (Lexer, AST, Parser, Semantik) + Entscheidungen
Frontend:
- Lexer komplett: Typ-Suffixe, Literal-Typisierung (Entscheidung: > 7
  signifikante Stellen -> DOUBLE), Hex/Oktal, Zeilenfortsetzung mit _,
  Strings mit ""-Escape, case-insensitive Keywords (Bibliotheksnamen
  bleiben Bezeichner)
- AST fuer Module/Prozeduren/Anweisungen/Ausdruecke
- Parser: fehlertolerant, zeilenorientiert; Kern-Anweisungssatz inkl.
  Bloecke, ON [LOCAL] ERROR, DEF FN (einzeilig); Datei-E/A als
  Phase-3-Platzhalter
- Semantik: Symboltabellen, implizite Deklaration, DEFtype, OPTION
  EXPLICIT, Arrays, Builtin-Signaturen, Labelpruefung; Hardware-Features
  (PEEK/POKE/...) werden zur Compile-Zeit abgewiesen
- Meilenstein: Testkorpus parst und wird typgeprueft (corpus.rs); 27 Tests

Entscheidungen eingearbeitet:
- Binaries heissen tb (IDE) und tbc (Compiler)
- Dynamische Terminalgroesse statt 80x25 (Minimum 80x25, btop-artiger
  Hinweis darunter); tb-ui::screen mit resize(), Spike angepasst
- Vollstaendigkeits-Leitplanke: 100% Sprache/Stdlib minus deklarierte
  Non-Features; Original-Doku als Guiding Principle; Inventar-Aufgabe
- CURRENCY als i64-Festkomma; ISAM wird implementiert; breite Zeichen
  belegen 2 Zellen; GET/PUT-Strings als UTF-32; Blink als hell simuliert
- LICENSE: MIT

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
2026-09-02 09:16:01 +02:00

21 lines
993 B
Markdown

# Kompatibilitäts-Testkorpus
Kleine Referenzprogramme mit dokumentierter erwarteter Ausgabe. Jede
`name.bas` hat eine `name.out` mit der exakten Konsolenausgabe (UTF-8,
LF-Zeilenenden). **Achtung:** PRINT gibt Zahlen mit führendem Leerzeichen
(bzw. `-`) und nachgestelltem Leerzeichen aus — auch am Zeilenende. Die
`.out`-Dateien enthalten daher signifikante Leerzeichen am Zeilenende;
Editoren dürfen sie nicht wegtrimmen; `.gitattributes` schützt die Dateien
vor Zeilenenden-Konvertierung.
Ab Phase 2 führt ein Test-Harness (`cargo test`) jede Datei per
`tbc run` aus und vergleicht die Ausgabe. Bis dahin dienen die
`.out`-Dateien als festgehaltene Verhaltensspezifikation — wo möglich am
Vorbild (Emulator) verifiziert, sonst nach Referenzlage rekonstruiert
und mit `TODO verify` im Programmkopf markiert.
Konventionen:
- Nur Konsolen-E/A (keine Forms) bis Phase 4
- Kein Zufall/Zeit, außer der Test fixiert die Saat (`RANDOMIZE` mit
Konstante) bzw. prüft nur Invarianten