plausible is not the same as correct
parser --on-error
Zwei Optionen: abbrechen, oder raten und weitermachen. Fast jeder Parser in Produktion wählt raten, denn ein Editor, der bei jedem Tippfehler das Highlighting verliert, wäre unbenutzbar. Die Frage ist, was "raten" heißt.
cat recovery-heuristics.txt
Fehlendes Token: gedanklich einfügen, weiter. Unerwartetes Token: überspringen, weiter. Optimiert für den häufigen Fall: Tippfehler. Für den seltenen Fall, strukturelle Mehrdeutigkeit: ein Baum, der gültig aussieht und trotzdem falsch ist.
diff reconstructed.ast parsed.ast
kein Unterschied sichtbar: kein Flag markiert rekonstruierte Knoten. Compiler, Linter, Analyzer behandeln geraten und geparst identisch. Der Fehler pflanzt sich fort, nie wieder als Fehler erkennbar.
grep -r "worst case" notes/
Editor: falsches Highlighting, eine Zeile, eine Sekunde. Parser für Gesetzestext: eine falsch verstandene Pflicht, weitergereicht als korrekt. Einzige robuste Antwort: rekonstruierte Knoten bleiben markiert, bis ein Mensch bestätigt.
Ein Parser, der nie abbricht, hat nicht weniger Fehler. Er hat nur aufgehört, sie zu melden.
Notiz am Rand eines Grammatik-Reviews