Эта схема получилась раза с третьего-четвёртого... Одна из целей - минимально менять сканер/парсер...

Определённые терминалы в грамматике размечаются исходя из соображений расстановки отступов и соотв-е проверки вносятся в парсер...
## Код:
```
@   проверка: соответствует ли число табов в начале строки текущему ур. отступа
>   увеличить ур. отступа
<   уменьшить ур. отступа
```
Итого:
1) Отступы проверяются только для помеченных терминалов, а не для всех строк. С последним были какие-то проблемы (простоты реализации)... Т.е. для некоторых частей проверки нет вовсе и их можно лепить как угодно.
2) Если уровень отступа изменился, то проверяемый терминалдолжен быть на новой строке. Т.е. требования к новым строкам и отступам становятся более жёсткими.

Для учебных целей - научить ставить отступы, думаю, это приемлемо. Т.к. самые вычурные варианты, которые в текущей "разметке" не проверяются, будут в глаза бросаться, и чтобы их получить, надо специально извратиться.

Пример:
## Код:
```
DeclSeq    = ... {TYPE @ {TypeDecl >@ ";" < }...
Type    = ... | [ABSTRACT | EXTENSIBLE | LIMITED] RECORD > ["("Qualident")"] FieldList @ {";" FieldList @} END <@
```

1) атрибуты, RECORD, ["("Qualident")"] не проверяются, могут быть где угодно.
2) FieldList должно находиться на отступ дальше чем TypeDecl. END на том же что и TypeDecl

A1..A3 - ошибки "неправльный отступ"
A4..A5 - нормально
A6 - извращение
Вложение:
1.png [ 4.74 КБ | Просмотров: 15548 ]
