# Blaise Pascal validator pilot

`blaise_pascal.atg` is a genuine Blaise Pascal grammar authored from
`Blaise/blaise-master/docs/grammar.ebnf` (Phases 1-9a) — **not** the
`Blaise-grammar/blaise_pascal.atg` installed next to the IDE sources,
which is byte-identical to the classic-Oberon grammar apart from its
tag line and describes Oberon, not Pascal.

The EBNF turned out to be an incomplete guide to the language, so the
grammar was developed against the `blaise` v0.14.0-SNAPSHOT oracle
binary instead (~80 oracle probes settling every uncertain point),
plus a 403-file project corpus. Findings (all encoded in the `.atg`
header comment):

- The EBNF expression section omits `or`, `in`, unary minus, `#nn`
  character literals and float literals — the oracle accepts all.
- The EBNF statement section omits `break`, `continue`,
  `case..of..(else)..end` and `repeat..until` — all oracle-proven.
- Interface and implementation sections routinely carry `type` and
  `var` sections (300+ corpus files) — the EBNF allows none.
- Declaration sections come in any order and repeat
  (`const` before `type`, ...); statement lists and routine bodies
  tolerate a missing `;` before the closing keyword.
- `set of (A, B, C)` (inline enum) is EBNF-documented but
  oracle-rejected; dotted names in const/array/set positions are
  oracle-rejected too (both accepted here — lenient superset).
- `TBox(T) = class` (paren form) is oracle-rejected; only `TBox<T>`
  declares a generic type. `class(TObject);` (forward, no `end`) is
  oracle-accepted although the EBNF requires `end`.
- Bare `Foo;` calls, `inherited;` without parens, `:=` in `var`
  sections and `=`-style defaults are all oracle-rejected with
  explicit messages; the grammar matches.
- Contextual keywords (`static`, `read`/`write`, `property`,
  `reference`, `on`, `Supports`, ...) were each probed against the
  oracle and either kept as identifiers with structural handling or
  reserved — see the header comment.

Known validator gaps (all zero-impact on the corpus unless noted):

- Explicit generic free-function calls `f<T>(x)` (zero corpus use).
- Typed-parameter arrow lambdas (zero corpus use).
- `asm` routine bodies (RTL files only, documented).
- Nested procedures inside methods (rare, documented).

`TEXT_BLOCK` literals (`''' ... '''`) cannot be expressed in Coco/R
tokens (the merged scanner DFA cannot tell `'''`-open apart from
string-escape), so a small length-preserving pre-scan filter
(`TextFilter.mod`) rewrites blocks to plain strings before parsing.
Positions are preserved exactly; the shipped `BlaiseV` is a front-end
script (`BlaiseParse` + `BlaiseTF` + temp-file handling).

## Build

```sh
./build.sh        # -> build/BlaiseV (+BlaiseParse, BlaiseTF; build/ ignored)
```

Needs `CR` (Coco/R), `gm2 -fiso`, the `parser.frm`/`scanner.frm`
frames and `FileIO.def/.mod` — all resolved from the environment with
sensible defaults (`CRFRAMES`, `M2LIB`, `CR`, `GM2`). Note: link via
the two-step module list (`-fgen-module-list` then `-fuse-list`); a
single-step link trips over pre-existing errors in this gm2 build's
own ISO library `.def` files (`RndFile`/`TermFile`/`ChanConsts`
set-constructor complaints).

Coco/R reports 0 errors and only benign LL(1) warnings (loop-exit and
documented first-alternative orderings, each triaged).

## Differential results (BlaiseV vs `blaise`)

- Accept battery (statements, expressions, types, classes, generics,
  lambdas, exceptions, char/textblock literals): **0 false positives**.
- Broken mutants: **0 missed**, positions close.
- `tests/deep.pas`: compiles clean with the oracle AND validates
  clean (const/type/var/threadvar sections, records, classes with
  static members/properties, interfaces, procedural/reference types,
  generics, all statements, lambdas, exceptions).
- Full project corpus (403 files): 387 clean-agree, 0 missed; the
  16 remaining validator-FPs all contain `asm` routine bodies
  (documented gap above), and the 5 oracle-rejected files are
  correctly rejected by the validator too.