Есть такие. Я встречал, кажется, для Coco. Но на практике так никто не делает.

А может быть, лучше нацелиться на то, чтобы новые языки сразу проектировать под рекурсивный спуск? В Go так и сделали и, кажется, ни в чём не проиграли по сравнению с C. Что удобно читать транслятору, то удобно читать и человеку.

Я вообще спрашивал про написание кода на си без препроцессора, но давайте и это тоже обсудим :) если писать парсер руками, в лоб, не модифицируя грамматику - так и будет, вы правы. Но вроде бы замена левой рекурсии - тривиальная операция, и парсерогененаторы умеют делать это автоматически

Так никто не отказывается от рекурсивного спуска. Просто там есть еще и секретный ингредиент :)

В Coco грамматика C ущербная. Это даже прямо говорится в комментариях в коде

Вероятно. Но в TCC и 8cc это явно делали вручную. К тому же это шаг, усложняющий процесс, но не приносящий никаких преимуществ, а следовательно, антипедагогический.

Мне кажется, Вы невнимательно смотрели исходный код парсера Go. Вот, собственно, тот самый "секретный ингредиент":

https://github.com/golang/go/blob/master/src/go/parser/parser.go#L1606

Любителям LLVM: тут ещё один оптимизирующий pass завезли
https://reviews.llvm.org/rGa17f03bd939

какой tldr? :)

one more AggressiveInstCombine :)

скорее инсткомбайн для векторов :)

полезная вещь, приминяет все эти существующи пипхол оптимизации но уже для векторных типов

сколько, сколько проходов?

161 (если я правильно посчитал в LinkAllPasses.h)??

кол-во не имеет значение, многие из них состоят из пары сотен строк кода, а другие - из десятков тысяч :)

А в чём секрет? В ручном прописывании приоритетов? В допущении необъявленных идентификаторов в левой части?

Combinatris: Tetris with SKI combinators
https://dirk.rave.org/combinatris/

Ну это обычное дело в естественных науках. Если вы физику вспомните, то на каждом новом уровне "вам всё врали". Сложность ПО уже, видимо подошла к тому, что можно использовать подходы биологии. 😊

Ocaml - это практически компилируемый Python. Только синтаксис отличается, да понятнее местами.

Сильное заявление, почти радикальное. С какой это стороны Окамле есть почти Питон? :-)

С утрированно практической стороны (пользователя, естественно):

1. Объекты, замыкания есть, функции - значения.
2. Типы указывать не нужно.
3. Сборщик мусора.
4. Более-менее однопоточные.
5. Скорость выполнения байт-кода более-менее одинаковая.
6. Не требуют внешней виртуальной машины JVM/.NET.
7. Есть языковые менеджеры пакетов.
8. Энергичные вычисления, есть побочные эффекты.
9. Изменяемые значения. Семантика - всё boxed (у Питона нет выделенного типа ref, потому там известный ахтунг, конечно).

Отличия - у OCaml'а нет классов типов, поэтому выч. мат код требует некоторых мелких хаков, а вывод структур на консоль - ppx_deriving или т.п.

И я, честно говоря, ничего более близкого к Питону, но компилируемого и достаточно популярного, не вижу.