head? Или какое-нибудь забытое |-условие?

"а у вашего Хаскеля тоже есть проблемы"

ну да, есть. предпочитаю его не трогать, когда могу

Дело не в Haskell, а в сложности пространства состояний системы и в объёме кода, который нужен для его полного описания (не генерации, а распознавания). Есть нижняя граница. От языка тут мало что зависит.

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

да, сразу все проблемы во вселенной отловить сложно, но АТД — простое и относительно эффективное средство

А если убрать из языка полноту по тьюрингу?

Можно даже не трогать язык, а рассматривать, например, вычислители с ограниченным объемом памяти.  Тот же f18 — отличный пример. Всего 64 слова ОЗУ и 64 слова ПЗУ. 10 слов стека данных и 9 слов стека возвратов. Но даже в таком радикальном случае перебор всех возможных конфигураций оказывается слишком велик.

Так что full employment theorem for static program analysis designers с разными подходами к "консервативности" и тут продолжает действовать :)

чем корректнее язык, тем труднее на нём решать задачи

Чорд. А я по транспиляторам фортрана в фортран специализируюсь...

Кстати а есть ли транспилятор фортрана в идиоматичный C, без оборачивания в свой рантайм и полифилы?

У gcc есть

Но это читать нереально. Глаза вытекают

We need to go deeper

Интернет, а можно ли автоформаттер хотя бы с привлечением совы и глобуса считать транспилятором?

да хоть интерпретатором)

Это скорее оптимизатор исходного языка.

или боевым вертолетом

С очень большой совой - да

Если в автоформаттере есть всякие квикфиксы, меняющие не только форматирование - сова несколько уменьшается

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