"Programs must be written for people to read, and only incidentally for machines to execute."
- Abelson & Sussman, SICP, preface to the first edition
(нет, не слышали)

Хотел бы я посмотреть на компилятор, написанный в соответствии с этой философией...

Любой учебный компилятор, написанный ответственным разработчиком?

Получается, что абстрактное "люди" нуждается в уточнении. Речь идет о новичках в компиляторостроении? И ответственный разработчик никакой помощи от языка реализации не получает?

Нет, речь не о новичках, но у авторов не учебных компиляторов недостаточно времени, чтобы писать код в первую очередь для чтения людьми, а не исполнения компьютером. То есть, это такое благое пожелание, которое в будничной практике сложно выполнить. Сам уже несколько дней занимаюсь рефакторингом для улучшения читаемости кода. Я уже умаялся, а результат всё равно будет неидеальным

Так оно же во всех языках так работает - нет, что ли?

Рефакторинг (в ранних источниках "факторизация"), обильное комментирование, использование нарочито упрощенных конструкций, literate programming — это, по большому счету, к идеалу Абельсона и Сассмана мало приближает.

По-настоящему приближает к идеалу предметно-ориентированная нотация. В случае компилятора этих нотаций, понятных компиляторщику-профессионалу, достаточно много: регулярные выражения, синтаксические правила БНФ, нотация для правил логического вывода (вывод типов, преобразования кода), нотация для уравнений анализа потока данных...

Ну вот в С# сделали для людей, однако. А там где фантазии не хватает, то тащат из Хаскеля. Вот не знаю, кстати, Хаскель сам изобрел смешать выражения и формальные ~выражения~ параметры в шаблонах в одну кучу или откуда утащил?

так это и есть механизм с интерфейсом try_extract

Не знаю, как по мне атрибутные грамматики в коде транслятора куда хуже читаются, чем код рекурсивного спуска, документированный грамматикой

Атрибутные грамматики (почему Вы вспомнили именно их?) сейчас считаются, скорее, проблемой, чем решением (см. учебник того же Купера). Лучшим вариантом, чем код рекурсивного спуска мог бы, например, быть код в PEG-нотации. Зачем документировать то, что можно запрограммировать сразу в выразительной нотации?

А формальное выражение это что? Выражение, где фигурируют метапеременные?

Хотя чего тут далеко ходить... во всех классических функциональных языках так. Это очень грустно, однако.

Затем,что не получается нормально закодировать в выразительной нотации. PEG не пробовал

Я имел в виду формальное параметры. Шаблон "x" и "x+0" имеют разный смысл — первый это формальный парметр, второй это выражение.

Честно признаться, я на этом проведении сам пару раз накалывался, но объективно, обратное поведение нарушает локальность (человеческих) рассуждений - нужно смотреть где-то выше по коду, связана уже переменная с таким именем или нет. Плюс при рефакторинге может быть неочевидный сюрприз.

Вот x в "x + 0" и является метапеременной, которая "захватывает" соответствующее конкретное сопоставляемое значение. Это основа, что в Haskell, что в Prolog, что Mathematica... Без этой возможности PM теряет, по большому счету, всю свою выразительность!

Очевидно, что обратно нельзя. В языках, где принято явно вводить формальные параметры каким либо ключевым словом (var/var/let/auto/etc) или указанием типа читатель ожидает что оно будет указано там, где вводится новый формальный параметр.

При этом понятно, что в том же Hashell или Prolog как раз совершенно нормально ничего специального не писать, ибо там в принципе определение нового имени не требует никакой особой церемонии.

У меня в raddsl метапеременные еще и являются сущностями первого класса, но явно видно, где они создаются.
То есть можно написать так:

rule(BinOp("+", let(X=number), let(Y=number)), ...

а можно:

X = let(X=number)
Y = let(Y=number)
rule(BinOp("+", X, Y), ...